Yes, please. I have the same situation as @matoeil . Thanks!
@jayemel, this latest update is working on one of my sites, still regression testing the update. Cautiously optimistic, though!
In case anyone else comes along this path*, the :raw suffix replaces the :key suffix from Drupal 7 Webform.
Drupal 7: [submission:values:select_element:key]
"Modern" Drupal: [webform_submission:values:select_element:raw]
* Probably me, some time next year...
@shelane just updated a site to Symfony 6.4.9 on Pantheon, and it's working fine. Note that SimpleSAMLphp is caching the error page: if that happens, try logging in again.
Thank you @berdir and @gravelpot. We will pursue inserting the conflict block, and work from there.
Thank you @mark_fullmer for the workaround!
Can confirm this issue when I updated a site to D10.2.7 this afternoon.
SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
1 src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML\Error\ExceptionHandler::customExceptionHandler)
0 [builtin] (N/A)
Caused by: Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "serializer.normalizer.object".
Backtrace:
11 /code/vendor/symfony/dependency-injection/ContainerBuilder.php:992 (Symfony\Component\DependencyInjection\ContainerBuilder::getDefinition)
10 /code/vendor/symfony/framework-bundle/DependencyInjection/FrameworkExtension.php:1999 (Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension::registerSerializerConfiguration)
9 /code/vendor/symfony/framework-bundle/DependencyInjection/FrameworkExtension.php:389 (Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension::load)
8 /code/vendor/symfony/dependency-injection/Compiler/MergeExtensionConfigurationPass.php:76 (Symfony\Component\DependencyInjection\Compiler\MergeExtensionConfigurationPass::process)
7 /code/vendor/symfony/http-kernel/DependencyInjection/MergeExtensionConfigurationPass.php:42 (Symfony\Component\HttpKernel\DependencyInjection\MergeExtensionConfigurationPass::process)
6 /code/vendor/symfony/dependency-injection/Compiler/Compiler.php:80 (Symfony\Component\DependencyInjection\Compiler\Compiler::compile)
5 /code/vendor/symfony/dependency-injection/ContainerBuilder.php:767 (Symfony\Component\DependencyInjection\ContainerBuilder::compile)
4 /code/vendor/symfony/http-kernel/Kernel.php:506 (Symfony\Component\HttpKernel\Kernel::initializeContainer)
3 /code/vendor/symfony/http-kernel/Kernel.php:763 (Symfony\Component\HttpKernel\Kernel::preBoot)
2 /code/vendor/symfony/http-kernel/Kernel.php:185 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
0 public/module.php:17 (N/A)Ivan Tibezh has already added a merge request:
https://git.drupalcode.org/project/views_sort_expression/-/merge_request...
Thank you.
Added patch #5 to version 2.0.6 due to crawlers recursing into links used for the autocomplete widget.
We do want the page to be indexed ONCE, but bots are not smart, and they will just keep going.
Part of the problem is how the autocomplete builds on itself. With zero terms, the links look like this:
"urls": {
"history": "/majors?f[0]=search:history",
"culture": "/majors?f[0]=search:culture",
...
}If I look for 'philosophy' then the autocomplete URLs look like this:
"urls": {
"history": "/majors?f[0]=search:history&f[1]=search:philosophy",
"culture": "/majors?f[0]=search:culture&f[1]=search:philosophy",
...
}And the crawler will just keep going.