🇳🇱Netherlands @Johan den Hollander

After going through the settings again today I still get this warning:

Deprecated: Creation of dynamic property Drupal\fastly\VclHandler::$snippetData is deprecated in /var/www/html/web/modules/contrib/fastly/src/VclHandler.php on line 1259

Tested MR #22 which surely is the cleanest solution to make the deprecation warnings go away.

Ah I made that duplicate conclusion to soon then, my bad, sorry for that.
The patch, and MR works fine.

Marking this as Needs review.
Tested the latest MR which works well to fix the problem with the latest 2.13 release.

Marking this as a duplicate of the older issue that more people follow and has a patch / MR that fixes this as well.
https://www.drupal.org/project/entity_browser/issues/2913952 🐛 modal dialog close button doesn't reset buttons that trigger modal Needs work

Tested this behaviour to see if we still need this patch. Can still reproduce without the patch. Not many people will experience this behaviour but the patch works in preventing this.

The #10 patch by @cedric works well.

Spend a few ours investigating the latest module updates in a project and found out it was caused by this module.
The issue was visible when installing a new module via the UI or drush (deploying) in the bit where new translations would get installed.
With the patch the problem is gone.

Im seeing this (during drush deploy) after adding a new module and deploying that.
Maybe related?
After the error showed up I did a drush cr, and the next drush cim went without problems.
Now that I think of this I get this error also when enabling a module via the UI.

TypeError: Drupal\locale\LocaleConfigManager::filterOverride(): Argument #2 ($translatable) must be of type array, Drupal\Core\StringTranslation\TranslatableMarkup given, called in /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php on line 637 in Drupal\locale\LocaleConfigManager->filterOverride() (regel 630 van /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php)
#0 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Object(Drupal\Core\StringTranslation\TranslatableMarkup))
#1 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#2 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#3 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#4 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#5 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(637): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#6 /var/www/builds/mysitename.nl-765/web/core/modules/locale/src/LocaleConfigManager.php(587): Drupal\locale\LocaleConfigManager->filterOverride(Array, Array)
#7 /var/www/builds/mysitename.nl-765/web/core/modules/locale/locale.bulk.inc(639): Drupal\locale\LocaleConfigManager->updateConfigTranslations(Array, Array)
#8 /var/www/builds/mysitename.nl-765/vendor/drush/drush/includes/batch.inc(257): locale_config_batch_refresh_name(Array, Array, Array)
#9 /var/www/builds/mysitename.nl-765/vendor/drush/drush/includes/batch.inc(204): _drush_batch_worker()
#10 /var/www/builds/mysitename.nl-765/vendor/drush/drush/includes/batch.inc(75): _drush_batch_command('253')
#11 /var/www/builds/mysitename.nl-765/vendor/drush/drush/src/Commands/core/BatchCommands.php(25): drush_batch_command('253')
#12 [internal function]: Drush\Commands\core\BatchCommands->process('253', Array)
#13 /var/www/builds/mysitename.nl-765/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#14 /var/www/builds/mysitename.nl-765/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#15 /var/www/builds/mysitename.nl-765/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#16 /var/www/builds/mysitename.nl-765/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#17 /var/www/builds/mysitename.nl-765/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/builds/mysitename.nl-765/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/builds/mysitename.nl-765/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/builds/mysitename.nl-765/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /var/www/builds/mysitename.nl-765/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 /var/www/builds/mysitename.nl-765/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#23 /var/www/builds/mysitename.nl-765/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run(Array)
#24 /var/www/builds/mysitename.nl-765/bin/drush.php(119): include('/var/www/builds...')
#25 {main}

Confirming the patch resolves the issue where the settingspage cannot be used.

johan den hollander → created an issue.

Just posting to mention we experience issues with the /tmp files too. This is since a couple of weeks.
Also this issue seems to come alive again, maybe some bigger problem? PHP extension?

https://github.com/ImageMagick/ImageMagick/issues/395

Thanks for the quick fix patch in #5.

Hate to be reopening this issue, but the issue is still there using the latest 7.x release.

We worked around the issue for now by modifying the code to be as follows:

use Symfony\Component\Routing\Exception\ResourceNotFoundException;

protected function getExposedFormActionUrl(FormStateInterface $form_state): Url {
    $request = \Drupal::request();
    try {
      $url = Url::createFromRequest(clone $request);
      $url->setAbsolute();
      return $url;
    }
    catch (ResourceNotFoundException $e) {
      return Url::fromRoute('<front>')->setAbsolute();
    }
  }

A patch will follow, I expect this code needs some better attention.

#13 is junk. I Agree 100% because the patch is malformed. Using the patch will give you errors. Updated the code which should work now.

Applied the patch against the latest 2.x version.

We're having the #10 patch in use for a while now. Works fine. Small change.

Using the diff from the #13 MR with DDEV I got it to work. Applied the same settings to Lagoon settingsfile and this allows me to setup a new and empty environment.
I also tried it by changing the redis port and that worked as well.

use Drupal\Core\Installer\InstallerKernel;

if (!InstallerKernel::installationAttempted() && extension_loaded('redis') && class_exists('Drupal\redis\ClientFactory')) {
  // Set Redis as the default backend for any cache bin not otherwise specified.
  $settings['cache']['default'] = 'cache.backend.redis';
  $settings['redis.connection']['host'] = 'redis';
  $settings['redis.connection']['port'] = 6379;
  $settings['redis.connection']['interface'] = 'PhpRedis';

  // Apply changes to the container configuration to better leverage Redis.
  // This includes using Redis for the lock and flood control systems, as well
  // as the cache tag checksum. Alternatively, copy the contents of that file
  // to your project-specific services.yml file, modify as appropriate, and
  // remove this line.
//  $settings['container_yamls'][] = 'modules/contrib/redis/example.services.yml';
  $settings['container_yamls'][] = 'modules/redis/example.failover.services.yml';
  // Allow the services to work before the Redis module itself is enabled.
  $settings['container_yamls'][] = 'modules/contrib/redis/redis.services.yml';

  // Manually add the classloader path, this is required for the container cache bin definition below
  // and allows to use it without the redis module being enabled.
  $class_loader->addPsr4('Drupal\\redis\\', 'modules/contrib/redis/src');

  // Use redis for container cache.
  // The container cache is used to load the container definition itself, and
  // thus any configuration stored in the container itself is not available
  // yet. These lines force the container cache to use Redis rather than the
  // default SQL cache.
  $settings['bootstrap_container_definition'] = [
    'parameters' => [],
    'services' => [
      'redis.factory' => [
        'class' => 'Drupal\redis\ClientFactory',
      ],
      'cache.backend.redis' => [
        'class' => 'Drupal\redis\Cache\CacheBackendFactory',
        'arguments' => ['@redis.factory', '@cache_tags_provider.container', '@serialization.phpserialize'],
      ],
      'cache.container' => [
        'class' => '\Drupal\redis\Cache\PhpRedis',
        'factory' => ['@cache.backend.redis', 'get'],
        'arguments' => ['container'],
      ],
      'cache_tags_provider.container' => [
        'class' => 'Drupal\redis\Cache\RedisCacheTagsChecksum',
        'arguments' => ['@redis.factory'],
      ],
      'serialization.phpserialize' => [
        'class' => 'Drupal\Component\Serialization\PhpSerialize',
      ],
    ],
  ];
}
# Use failover services when Redis is not available.
$settings['redis.failover'] = TRUE;

Thanks @roderickgadellaabsl this seems like a easy way to solve it.
Will try this with the next release cycle of the website we were having the problem with.

Although there is nothing that needs fixing in this module, we can leave this here for other people to find it!

I'm also seeing the error. Using the 4.6.10 version is working well.
Let's try to fix this in: https://www.drupal.org/project/simplesamlphp_auth/issues/3427576 🐛 Cannot access property starting with "\0" in SAML2\XML\saml\NameIDType->__unserialize() Needs work

Johan den Hollander → created an issue.

Using the diff from the MR as a patch and the deprecation warning is gone. Functionality seems not different from before.

Using the lastest MR 339 we cannot set the row weights anymore.
Also the drag and drop options seem hard to click for users.
The drag and drop option that shows the drag and drop view, not the usuals drag handles, those work fine.

I took a shot at creating a patch that seems to do the job!

I looked at some lines from the paragraphs_asymmetric_translation_widgets module and added an extra check to make sure that module exists and applied these lines in the paragraphs_previewer module.

Thanks!

@alexis_mc did you try the solution from the #26 Merge request for the tables.
What are the changes (interdiff) between your patch and the #18 patch?

The #9 MR is leaving a lot of code in place that has no further use.

Have you tried the solution for tables in the #26 MR?

Thanks. Will give this a try.
We use the clearing of the Redis on drush cr on two identical sites.
However one of the sites is giving zend_memory_heap error when we do so.
When we first do a redis-flush and then a drush cr without the patch from this issue we have no errors.

The other site has no problem clearing Redis via a drush cr.

I'm not sure if this error is only because of using this patch or that maybe we have some other issues like hosting configuration.
Althoug both of these sites are configured in the same way...

This code should not have been in the 1.5 release.

With this hook active you cannot have an exposed search form in a block on the homepage that brings you to the search results page.

Unfortunately I see that a table inside the editor is now collapsed.
Unfortunately I see that a table inside the editor is now collapsed.
Before applying the patch:

With the #18 patch applied.

Tested the #18 on a Drupal 10.1.6 / Gin 8.x-3.0-rc7 site and it works well for me. It looks good on all screen sizes used by editors.

The changes in the MR work well for me.

A queue will only process stuff if something has explicitly added items to the queue. For node_delete_revisions, that happens when nodes are updated, then they will be checked on the next cron run.

So how would this then delete revisions older then x months form a node that has not been touched recently?

The #45 patch is a small step forward but some odd things:

When creating a new Media entity with this patch enabled:

First add file, then select private storage.
-Upload a file
-Select Private storage
-Save entity
-Edit media entity again.
-Notice it has been stored as a public file.

First select storage, then upload a file.
-Set storage to private.
-Upload a file
-Notice that private has been reset to public, set to private again
-Save entity
-Edit media entity again.
-Notice is has the correct setting, private storage.

Now when you want to change the file from private to public it is not possible anymore. It will always be private.

Did another run, now with the platch applied. No more errors.

#5 patch applies to 2.0.x-dev and gives the output as stated in the comment.
@adriancid is right that this needs to be configurable on the settingspage.

I'm seeing this error once in my logs after cleaning up a lot of revisions for the first time ever for this website:

Error: Call to a member function getTranslationLanguages() on null in Drupal\node_revision_delete\Plugin\QueueWorker\NodeRevisionDelete->processItem() (line 83 of mywebsite/modules/contrib/node_revision_delete/src/Plugin/QueueWorker/NodeRevisionDelete.php)

Johan den Hollander → created an issue.

Just tested with #16 patch and MR #21.
With 16 the Redis cache is not flushed. While with the MR it works correctly.

The patch brings back the desired behaviour. I have not seen any negative effect at this point.

Still need #3 patch to clear the filters via the facet summary.
It works on facets 2.x and also on 3.x.
facets_pretty_paths: 2.0.0-rc1

We are using this patch for a while in production now. I just tested if we still need it.

When using the module without the patch the modal windows sometimes opens partly outside the viewport.
With the patch all is working fine!

In a more daring proposal, I am thinking of moving the code from the separate dependency pfrenssen/matomo-reporting-api into the Drupal module, mainly to reduce maintenance and complexity. I can't see that the lib is used in any other project.

I have no objection to this at all! And if anyone depends on the github repo they are free to fork it as well.

We are using the MR from here in a custom module for now.
https://github.com/pfrenssen/matomo-reporting-api/pull/12

If any of those MR's is accepted we can move forward here too!

@esch you have the simplesamlphp tables in the same database as Drupal. That is not necessary, so if you would put those in a separate database you can get rid of this warning / error.

The patch applies without any issue. However when I'm done editting I am presented with an error. Not sure if this is a problem with the patch of with my site in general though....

Log says:

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("node") to generate a URL for route "entity.node.canonical". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 187 of /var/www/html/web/core/lib/Drupal/Core/Routing/UrlGenerator.php).

This was when I had the redirect url after editting set to: /node/3 (this was the default when enabling this functionality. This is the frontpage as set in the Basic Site settings.

After changing it to: /admin/content/media-grid the there was no issue.

A quick workaround is to download and enable the Aggregator module: https://www.drupal.org/project/aggregator → .

Johan den Hollander → created an issue.

We just tested the 4.x-dev version without any patches and it works without any issues with Drupal 10.

Confirming that the added checks remove the warning while emails are still being send out.

Changing back because the warning is on line 81 and 171.
The MR is not fixing both problems.

Johan den Hollander → created an issue.

I think you are right about that Ressa. Just created a 2.x-dev release now.

Tadas.rimkus,

Your custom patches, did you create issues for those at simplesamlphp github?

Anything in the Drupal logs? Or maybe you have access to the PHP / Apache logs on the server to see what is logged with this 500 error.

@Rishi could you try with all of the patches:

"drupal/simplesamlphp_auth": {
"Custom patch for D10 compatibility - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19....",
"Custom patch for D10 compatibility - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility...",
"RedirectResponse fix for D10 compatibility": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_re..."
},
"simplesamlphp/saml2": {
"Custom patch for d10 Container fix": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_c..."
}

@tadas.rimkus I just found out that simplesamlphp/saml2 has to be version simplesamlphp/saml2:v5.0.0-alpha.6 for it to work.
I'm using your patch suggestions here.

@tadas.rimkus I tried to applied your patches as follows:

"drupal/simplesamlphp_auth": {
"Custom patch for D10 compatibility - 3349278_documentation_19": " https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.... → ",
"Custom patch for D10 compatibility - 3349278-d10-compatibility_14": " https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility... → ",
"RedirectResponse fix for D10 compatibility": " https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_re... → "
},
"simplesamlphp/saml2": {
"Custom patch for d10 Container fix": " https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_c... → "
}

The result is a different error:
TypeError: SimpleSAML\SAML2\AuthnRequest::setNameIdPolicy(): Argument #1 ($nameIdPolicy) must be of type ?SimpleSAML\SAML2\XML\samlp\NameIDPolicy, array given, called in /var/www/builds/lab/lab-169/vendor/simplesamlphp/simplesamlphp/modules/saml/src/Message.php on line 490 in SimpleSAML\SAML2\AuthnRequest->setNameIdPolicy() (line 321 of /var/www/builds/lab/lab-169/vendor/simplesamlphp/saml2/src/SAML2/AuthnRequest.php).

I'm also seeing the same error as #31 in the Drupal logs

Besides that visiting the simplesamlphp address also gives the following:

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
2 public/_include.php:28 (SimpleSAML_exception_handler)
1 /var/www/builds/sitename/sitename-263/vendor/symfony/error-handler/ErrorHandler.php:537 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
0 [builtin] (N/A)
Caused by: Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "debug.error_handler_configurator".
Backtrace:
6 /var/www/builds/sitename/sitename-263/vendor/symfony/dependency-injection/Container.php:264 (Symfony\Component\DependencyInjection\Container::make)
5 /var/www/builds/sitename/sitename-263/vendor/symfony/dependency-injection/Container.php:212 (Symfony\Component\DependencyInjection\Container::get)
4 /var/www/builds/sitename/sitename-263/vendor/symfony/framework-bundle/FrameworkBundle.php:101 (Symfony\Bundle\FrameworkBundle\FrameworkBundle::boot)
3 /var/www/builds/sitename/sitename-263/vendor/symfony/http-kernel/Kernel.php:131 (Symfony\Component\HttpKernel\Kernel::boot)
2 /var/www/builds/sitename/sitename-263/vendor/symfony/http-kernel/Kernel.php:192 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
0 public/module.php:14 (N/A)

Confirming that with the latest patch I can login as a new user and get the right roles assigned to the user with Drupal 10.

@axl_m the line of code helps the modal to open in the right position.
However putting a patch for Entity Browser in a Gin issue is not the right position.
Although it may help to determine what the cause of this problem is.

I just tested with Claro theme and this issue is not happening then. So it seems the solution should be applied somewhere in Gin?

Some additional info:
There is a throbber spinning in the top left corner of the modal window.
After some time some errors show up in the browser console.

Hi. This loose targeting is not only affecting the backend theme. It also affects the frontend theme for logged in users (with permission to use admin toolbar).

Notice the blue background color on the menu item in the attached screenshot.

Johan den Hollander → created an issue.

The patch applied correctly. And I still have the option to select the Pickup shipping method.

Lots of activity on this issue today since Atom is not autosaving ;-)

Should be good now...

Updated patch. Copy paste error fixed.

I created a patch for this that seems to work well.

Please review.

Patch #2 has a filemode change. That is not correct indeed. Patch #3 has the same logical changes applied.

The patch applies correctly and the error is gone.

I have the same issue. It is as @beerendlauwers says. When the button is near the bottom of the viewport the problem is there. Having the button more to the center of the screen does not give any problem.
Also it is like said in the original description, with the vertical toolbar the problem is not there.

We recently switched to Gin for this projects and editors quickly hit this problem.

Patch applies, makes the module compatible with Drupal 10.

Thanks. That makes sure the last warning is gone.
Now let's hope this will make it into a new release!

Great work @davisben.
I just applied the plain diff and the Upgrade scanner says it's compatible with Drupal 10!

However 1 warning is still given in: web/modules/contrib/commerce_webform_order/commerce_webform_order.install - line 46

Call to deprecated method prepare() of class Drupal\Core\Database\Connection. Deprecated in drupal:9.1.0 and is removed from drupal:10.0.0. Database drivers should instantiate \PDOStatement objects by calling \PDO::prepare in their Connection::prepareStatement method instead. \PDO::prepare should not be called outside of driver code.

Same for me, in DDEV the problem did not show up. It was only on the Testing environment that the problems started.

Confirming that the #2 patch solves the problem.

Using this patch broke the UI when editing pages. The patch in the related issue works fine.

The #87 patch applies cleanly and does what it has to do. The inactive tab gets opened and shows the required field that was left empty.