Account created on 12 September 2018, over 5 years ago
#

Merge Requests

More

Recent comments

Once you have saved the form once with the patch applied, if you remove the patch does it still work? That was my experience, so I don't need the patch anymore.

@maskedjellybean You wrongly removed the for loop.

Compare your changes with the prior MR.

The MR fixes the coding standard where \Drupal was used instead of injecting the service. It looks like the proper fix to me.

Note that this fix requires dropping support for Drupal 9 and 10.0. If we want to support them, then either wait to merge, or we would need to add in a check to make sure the Error::logException function exists. I checked, and the class itself exists in 9.0.x

This change required Drupal 10.1, so the info.yml file should be updated with the version requirement.

The changes can only be merged when support for Drupal 9 and 10.0 should be dropped.

The MR doesn't use the recommended solution, either. Use Error::logException if possible.

Ah, that's right. Well, I just added the changes as-is to an MR, and updated info.yml

The patch doesn't inject the logger service.

You should also learn how to use a Merge Request . Drupal doesn't recommend using .patch files anymore.

The patch doesn't inject the logger service or follow Drupal coding standards .

You should set up your development environment so that you can use PHPCS to check your coding standards. I use https://github.com/ddev/ddev-drupal-contrib

I created a merge request. It maintains backwards compatibility for the constructor in the same way that Core does, so that it won't break other modules.

For an example in Core, see MenuRouterRebuildSubscriber.

The patch doesn't inject the logger service or use the correct parameters to Error::logException.

Should the LoggerChannelTrait be deprecated, then, to encourage service injection and discourage new uses of the trait?

I still think it should provide that link in the command line when trying to uninstall with Drush.

we can't test the xdebug mode issue because we don't have xdebug running on gitlabci

Ah, that's right. I didn't think of that.

If you look at the module's code in the dev version, there's nothing there on line 108. Is your module up to date?

https://git.drupalcode.org/project/webform/-/blob/6.2.x/src/WebformToken...

Comments like * @var Drupal\Core\Queue\QueueWorkerManager should have a \ before the namespace.

  /**
   * Queue worker plugin manager
   *
   * @var \Drupal\Core\Queue\QueueWorkerManager
   */
  protected $pluginManagerQueueWorker;

  /**
   * Queue Factory.
   *
   * @var \Drupal\Core\Queue\QueueFactory
   */
  protected $queue;

  /**
   * Config Factory.
   *
   * @var \Drupal\Core\Config\ConfigFactory
   */
  protected $configFactory;

  /**
   * The queue worker logger channel.
   *
   * @var \Psr\Log\LoggerInterface
   */
  protected $logger;

!empty($string) isn't a correct way to check for a string's emptiness.

empty('0') === TRUE

I confirmed that the patch #148 fixes the issue.

Would it be possible to write a test following the steps in #146? Or is that not necessary?

@alexpott The issue is caused by having a menu link that, in the "Link" field, has a path that is a node's redirect.

To reproduce my issue:

  1. Enable xdebug with develop in the mode. ddev xdebug on
  2. Create a node and give it a path alias /test1. Save.
  3. Edit the node, and change the alias to /test2. Save.
  4. Create a new menu link, with the link going to the string "/test1", not to the node ID, and save it.
  5. drush cache:rebuild

I looked through the referencing issue and I didn't see any proposed solution or alternative to silently ignoring the plugins.

I am going to update this comment with further debugging steps taken.

  • Commenting out the line $this->menuLinksRebuild(); in MenuRouterRebuildSubscriber::onRouterRebuild fixes the issue.

Okay, after uninstalling a lot of modules a few at a time and deleting content in bulk, I discovered the source of the issue.

The error stops occurring if I delete all custom menu links by navigating to /admin/modules/uninstall/entity/menu_link_content (route system.prepare_modules_entity_uninstall).

It also had

@@ -249,6 +249,7 @@ as the mapping between Azure AD accounts and Drupal users.<br/>
       '#type' => 'item',
       '#markup' => Url::fromRoute('openid_connect_windows_aad.sso', [], [
         'absolute' => TRUE,
+        'https' => TRUE,
         'language' => $this->languageManager->getLanguage(LanguageInterface::LANGCODE_NOT_APPLICABLE),
       ])->toString(),
     ];

The issue only happens when using Drush. I don't see it when clearing the cache via the UI. I am using Drush 12.

When using #141, I still get the error with the same frequency. Same trace as #132

I am not on slack. I am going to try one more thing. I uninstalled all custom code. That didn't fix it, so it's in core or contrib. I will continue uninstalling modules and clearing the cache afterwards until I see it fixed or run out of modules to uninstall. That will hopefully narrow it down.

Also, is it possible for the logging of DB credentials during serialization of the connection object to be prevented?

I have no idea. I removed all other patches I'm using from both contrib and core, and I still get the issue.

I tried on another site using #130, and it works fine. I'm going to try to narrow down if there's a certain patch or something I'm using that is causing an issue.

Even so, the cache clear does succeed sometimes, with all my connections enabled. So it seems to be something unreliable that causes the error.

Does it perhaps matter which order things are destructed?

Also, even after commenting out my other DB connections, I still have the error... but now the error only happens roughly every other time I clear the cache..., alternating a success and a failure.

Using #130, I do still get an error, only when xdebug is enabled with develop. The error is very similar to #93, but I will include it:

$ ddev drush cr
 [success] Cache rebuild complete.
PHP Fatal error:  Uncaught TypeError: Drupal\Core\Database\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 580 and defined in /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php:54
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php(580): Drupal\Core\Database\StatementWrapperIterator->__construct()
#1 /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php(846): Drupal\Core\Database\Connection->prepareStatement()
#2 /var/www/html/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php(118): Drupal\Core\Database\Connection->query()
#3 /var/www/html/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php(167): Drupal\Core\Cache\DatabaseBackend->getMultiple()
#4 /var/www/html/web/core/lib/Drupal/Core/Config/CachedStorage.php(87): Drupal\Core\Cache\ChainedFastBackend->getMultiple()
#5 /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php(165): Drupal\Core\Config\CachedStorage->readMultiple()
#6 /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php(104): Drupal\Core\Config\ConfigFactory->doLoadMultiple()
#7 /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php(89): Drupal\Core\Config\ConfigFactory->doGet()
#8 /var/www/html/web/core/lib/Drupal.php(411): Drupal\Core\Config\ConfigFactory->get()
#9 /var/www/html/web/core/includes/errors.inc(323): Drupal::config()
#10 /var/www/html/web/core/includes/errors.inc(123): _drupal_get_error_level()
#11 /var/www/html/web/core/includes/bootstrap.inc(202): error_displayable()
#12 /var/www/html/web/core/includes/bootstrap.inc(186): _drupal_exception_handler_additional()
#13 [internal function]: _drupal_exception_handler()
#14 {main}
  thrown in /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php on line 54

Fatal error: Uncaught TypeError: Drupal\Core\Database\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 580 and defined in /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php on line 54

TypeError: Drupal\Core\Database\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 580 in /var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php on line 54

Call Stack:
    7.0476   71920152   1. _drupal_exception_handler($exception = class AssertionError { protected $message = 'Transaction $stack was not empty. Active stack: 65cf9bfc172788.99424958\\drupal_transaction'; private string ${Error}string = ''; protected $code = 1; protected string $file = '/var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php'; protected int $line = 99; private array ${Error}trace = [0 => [...], 1 => [...]]; private ?Throwable ${Error}previous = NULL }) /var/www/html/web/core/includes/bootstrap.inc:0
    8.3110   71904080   2. _drupal_exception_handler_additional($exception = class AssertionError { protected $message = 'Transaction $stack was not empty. Active stack: 65cf9bfc172788.99424958\\drupal_transaction'; private string ${Error}string = ''; protected $code = 1; protected string $file = '/var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php'; protected int $line = 99; private array ${Error}trace = [0 => [...], 1 => [...]]; private ?Throwable ${Error}previous = NULL }, $exception2 = class TypeError { protected $message = 'Drupal\\Core\\Database\\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 580'; private string ${Error}string = ''; protected $code = 0; protected string $file = '/var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php'; protected int $line = 54; private array ${Error}trace = [0 => [...], 1 => [...], 2 => [...], 3 => [...], 4 => [...], 5 => [...], 6 => [...], 7 => [...], 8 => [...]]; private ?Throwable ${Error}previous = NULL }) /var/www/html/web/core/includes/bootstrap.inc:186
    8.3110   71904080   3. error_displayable($error = ???) /var/www/html/web/core/includes/bootstrap.inc:202
    8.3110   71904080   4. _drupal_get_error_level() /var/www/html/web/core/includes/errors.inc:123
    8.3110   71904080   5. Drupal::config($name = 'system.logging') /var/www/html/web/core/includes/errors.inc:323
    8.3110   71904080   6. Drupal\Core\Config\ConfigFactory->get($name = 'system.logging') /var/www/html/web/core/lib/Drupal.php:411
    8.3110   71904080   7. Drupal\Core\Config\ConfigFactory->doGet($name = 'system.logging', $immutable = ???) /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:89
    8.3110   71904296   8. Drupal\Core\Config\ConfigFactory->doLoadMultiple($names = [0 => 'system.logging'], $immutable = TRUE) /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:104
    8.3110   71904408   9. Drupal\Core\Config\CachedStorage->readMultiple($names = [0 => 'system.logging']) /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:165
    8.3110   71905032  10. Drupal\Core\Cache\ChainedFastBackend->getMultiple($cids = [0 => 'system.logging'], $allow_invalid = ???) /var/www/html/web/core/lib/Drupal/Core/Config/CachedStorage.php:87
    8.3110   71905032  11. Drupal\Core\Cache\DatabaseBackend->getMultiple($cids = [0 => 'system.logging'], $allow_invalid = FALSE) /var/www/html/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php:167
    8.3110   71906192  12. Drupal\Core\Database\Connection->query($query = 'SELECT [cid], [data], [created], [expire], [serialized], [tags], [checksum] FROM {cache_config} WHERE [cid] IN ( :cids[] ) ORDER BY [cid]', $args = [':cids[]' => [0 => 'system.logging']], $options = ???) /var/www/html/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php:118
    8.3111   71907240  13. Drupal\Core\Database\Connection->prepareStatement($query = 'SELECT [cid], [data], [created], [expire], [serialized], [tags], [checksum] FROM {cache_config} WHERE [cid] IN ( :cids__0 ) ORDER BY [cid]', $options = ['fetch' => 5, 'allow_delimiter_in_query' => FALSE, 'allow_square_brackets' => FALSE, 'pdo' => []], $allow_row_count = ???) /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php:846
    8.9296   71907624  14. Drupal\Core\Database\StatementWrapperIterator->__construct($connection = class Drupal\mysql\Driver\Database\mysql\Connection { protected $target = 'default'; protected $key = 'default'; protected $logger = NULL; protected $transactionLayers = []; protected $driverClasses = []; protected $statementWrapperClass = 'Drupal\\Core\\Database\\StatementWrapperIterator'; protected $transactionalDDLSupport = FALSE; protected $connection = NULL; protected $connectionOptions = REDACTED; REDACTED...}, $clientConnection = NULL, $query = 'SELECT "cid", "data", "created", "expire", "serialized", "tags", "checksum" FROM "cache_config" WHERE "cid" IN ( :cids__0 ) ORDER BY "cid"', $options = [], $rowCountEnabled = FALSE) /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php:580

I was trying to change the mode with ini_set('xdebug.mode', 'debug'); in settings.php, but apparently that doesn't work, as ddev drush eval "echo ini_get('xdebug.mode');" still shows debug,develop.

I looked up how to change the mode with DDEV and now I don't get the error after properly setting the mode to debug.

Trying with the updated patch and with xdebug.mode=debug, I still get the error. The cache rebuild says is completed, but the error happens after that:

$ ddev drush cr
 [success] Cache rebuild complete.
<h1>Additional uncaught exception thrown while handling exception.</h1><h2>Original</h2><p><em class="placeholder">AssertionError</em>: Transaction $stack was not empty. Active stack: 65cf912f0554b3.60082165\drupal_transaction in <em class="placeholder">assert()</em> (line <em class="placeholder">99</em> of <em class="placeholder">/var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php</em>). <pre class="backtrace">assert() (Line: 99)
Drupal\Core\Database\Transaction\TransactionManagerBase-&gt;__destruct()
</pre></p><h2>Additional</h2><p><em class="placeholder">TypeError</em>: Drupal\Core\Database\StatementWrapperIterator::__construct(): Argument #2 ($clientConnection) must be of type object, null given, called in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 577 in <em class="placeholder">Drupal\Core\Database\StatementWrapperIterator-&gt;__construct()</em> (line <em class="placeholder">54</em> of <em class="placeholder">/var/www/html/web/core/lib/Drupal/Core/Database/StatementWrapperIterator.php</em>). <pre class="backtrace">Drupal\Core\Database\StatementWrapperIterator-&gt;__construct() (Line: 577)
Drupal\Core\Database\Connection-&gt;prepareStatement() (Line: 42)
Drupal\mysql\Driver\Database\mysql\Insert-&gt;execute() (Line: 78)
Drupal\dblog\Logger\DbLog-&gt;log() (Line: 101)
Drupal\Core\Logger\LoggerChannel-&gt;log() (Line: 175)
_drupal_log_error() (Line: 182)
_drupal_exception_handler()
</pre></p><hr />PHP Fatal error:  Uncaught TypeError: Drupal\Core\Database\Connection::getClientConnection(): Return value must be of type object, null returned in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php:326
Stack trace:
#0 /var/www/html/web/core/modules/mysql/src/Driver/Database/mysql/TransactionManager.php(31): Drupal\Core\Database\Connection->getClientConnection()
#1 /var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php(290): Drupal\mysql\Driver\Database\mysql\TransactionManager->processRootCommit()
#2 /var/www/html/web/core/lib/Drupal/Core/Database/Transaction.php(88): Drupal\Core\Database\Transaction\TransactionManagerBase->unpile()
#3 [internal function]: Drupal\Core\Database\Transaction->__destruct()
#4 {main}
  thrown in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 326

Fatal error: Uncaught TypeError: Drupal\Core\Database\Connection::getClientConnection(): Return value must be of type object, null returned in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 326

TypeError: Drupal\Core\Database\Connection::getClientConnection(): Return value must be of type object, null returned in /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php on line 326

Call Stack:
   10.2068   71972432   1. _drupal_exception_handler() /var/www/html/web/core/includes/bootstrap.inc:0
   10.9371   71954480   2. _drupal_exception_handler_additional() /var/www/html/web/core/includes/bootstrap.inc:186
   10.9371   71954480   3. error_displayable() /var/www/html/web/core/includes/bootstrap.inc:202
   10.9371   71954480   4. _drupal_get_error_level() /var/www/html/web/core/includes/errors.inc:123
   10.9371   71954480   5. Drupal::config() /var/www/html/web/core/includes/errors.inc:323
   10.9371   71954480   6. Drupal\Core\Config\ConfigFactory->get() /var/www/html/web/core/lib/Drupal.php:411
   10.9371   71954480   7. Drupal\Core\Config\ConfigFactory->doGet() /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:89
   10.9371   71954696   8. Drupal\Core\Config\ConfigFactory->doLoadMultiple() /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:104
   10.9371   71954808   9. Drupal\Core\Config\CachedStorage->readMultiple() /var/www/html/web/core/lib/Drupal/Core/Config/ConfigFactory.php:165
   10.9371   71955432  10. Drupal\Core\Cache\ChainedFastBackend->getMultiple() /var/www/html/web/core/lib/Drupal/Core/Config/CachedStorage.php:87
   10.9371   71955432  11. Drupal\Core\Cache\DatabaseBackend->getMultiple() /var/www/html/web/core/lib/Drupal/Core/Cache/ChainedFastBackend.php:167
   10.9371   71956592  12. Drupal\mysql\Driver\Database\mysql\Connection->query() /var/www/html/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php:118
   10.9372   71957640  13. Drupal\mysql\Driver\Database\mysql\Connection->prepareStatement() /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php:843
   11.4784   71958024  14. Drupal\Core\Database\StatementWrapperIterator->__construct() /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php:577

Here is some additional debugging. The error in #93 occurs for an INSERT INTO "watchdog" query. $this->connection is NULL, and the query is being used to log an error.

Since the actual exception logging fails, here's the call stack prior to the error:

Drupal\Core\Database\Connection->prepareStatement (...\web\core\lib\Drupal\Core\Database\Connection.php: 577)
Drupal\mysql\Driver\Database\mysql\Insert->execute (...\web\core\modules\mysql\src\Driver\Database\mysql\Insert.php: 42)
Drupal\dblog\Logger\DbLog->log (...\web\core\modules\dblog\src\Logger\DbLog.php: 78)
Drupal\Core\Logger\LoggerChannel->log (...\web\core\lib\Drupal\Core\Logger\LoggerChannel.php: 127)
_drupal_log_error (...\web\core\includes\errors.inc: 175)
_drupal_exception_handler (...\web\core\includes\bootstrap.inc: 182)

And the exception it was trying to log:

%type: "AssertionError"
@message: "Transaction $stack was not empty. Active stack: 65cf8c6fcd9c88.03805306\drupal_transaction"
%function: "assert()"
%file: "/var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php"
%line: 99
@backtrace_string:
"#0 /var/www/html/web/core/lib/Drupal/Core/Database/Transaction/TransactionManagerBase.php(99): assert()
#1 [internal function]: Drupal\Core\Database\Transaction\TransactionManagerBase->__destruct()
#2 {main}"
exception: AssertionError
severity_level: 3
channel: "php"

The MR diff applies to 10.2.3 for me. Note that the .diff can sometimes apply differently than the .patch; maybe that's why.

Full stack trace from using 6614.diff

$ ddev drush cr
PHP Fatal error:  Uncaught Error: Call to a member function get() on null in /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php:1360
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(1244): Drupal\Core\DrupalKernel->initializeServiceProviders()
#1 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(937): Drupal\Core\DrupalKernel->compileContainer()
#2 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(494): Drupal\Core\DrupalKernel->initializeContainer()
#3 /var/www/html/web/core/includes/utility.inc(34): Drupal\Core\DrupalKernel->boot()
#4 /var/www/html/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(66): drupal_rebuild()
#5 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
#6 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#7 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#8 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#9 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#10 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#11 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#12 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#13 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#14 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#15 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#16 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#17 /var/www/html/vendor/drush/drush/drush(4): require('...')
#18 /var/www/html/vendor/bin/drush(119): include('...')
#19 {main}
  thrown in /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php on line 1360

 [warning] Drush command terminated abnormally.

While the number of lines changed for this issue are small (at the moment) UID's are so widely used across the ecosystem we would likely always want this to be a 'single method' only change.

Hopefully, once impacted users change one method, they will see the upcoming pipeline of changes and change in bulk what they need to ahead of time, if possible.

I don't know if it's relevant, but I do have additional external DB connections defined. Let me know if you need any additional info for debugging in addition to what I've given.

The latest commit broke something.

PHP Fatal error:  Uncaught Error: Call to a member function get() on null in /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php:1360
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(1244): Drupal\Core\DrupalKernel->initializeServiceProviders()
#1 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(937): Drupal\Core\DrupalKernel->compileContainer()
#2 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(494): Drupal\Core\DrupalKernel->initializeContainer()
#3 /var/www/html/web/core/includes/utility.inc(34): Drupal\Core\DrupalKernel->boot()
#4 /var/www/html/vendor/drush/drush/src/Commands/core/CacheRebuildCommands.php(66): drupal_rebuild()
#5 [internal function]: Drush\Commands\core\CacheRebuildCommands->rebuild()
      // Special-case the database service so that transactions started by other
      // destructable services are closed.
      $this->container->get('database')->destruct();

I still have the error in #93 when applying the latest MR diff to 10.2.3.

Can someone review if this is related or if the error should be a different issue or something?

What about changing the return type/hint of EntityInterface::id() and all other ID parameters//returns to ?string and dropping int altogether as possible return type.

I don't think that makes sense. We need to work towards strict typing with a straightforward and common-sense standard. It's not a good idea to standardize returning all integers stored in the database as strings.

+1 RTBC. I've been using patch #17 on a site successfully since March 2021.

I agree with @larowlan. I don't know of any site that uses HTMX, as it's really new. Would this require a complete rewrite of large amounts of custom/contrib code?

If HTMX sweeps the web and it becomes well-used across the web or as popular as jQuery, then go for it. Otherwise, it could become another sizeable barrier to getting started with Drupal or to upgrading to the next version.

I applied the changes from #103, but with it actually working ($type needed to be added to the for loop).

I have now applied all the requested changes from #94 and after. Please review the changes.

The patch from the MR can be downloaded here. Put it in your project folder and put a reference to ./patches/openid_connect-3011413-mr98.patch or whatever in your composer.patches.json file.

  • I started with patch #94
  • I fixed all the coding standards issues that are in the changes (without duplicating the work at 📌 Fix PHPCS errors Needs review ).
  • I fixed comment wording

I'm going to look into whether any of the changes after #94 should be included.

MR 98 should be used going forward, as it targets 3.x.

The MR as-is doesn't fix SlevomatCodingStandard.TypeHints.DeclareStrictTypes.IncorrectStrictTypesFormat

Also, this issue is closed. If someone has a bug, it should probably be opened as a new issue in the queue.

Form elements can already be disabled, using the disabled or readonly attributes. We don't need to add a config option for this.

If an AI component is integrated, then we need to include a way to disable it. Private sites with proprietary data might not want to have that data sent to/through an AI, and it might even be required by law that it isn't.

Curious, is there a way to set a specific paragraph type as not revisioned? I have some that are revisioned and some that shouldn't be.

Production build https://api.contrib.social 0.61.6-2-g546bc20