$whitelist was changed to $pathPrefixes in Drupal 11.1.0
https://git.drupalcode.org/project/drupal/-/commit/27948b069b1be0be6062b...
Here is an updated patch for Drupal 11.1+.
When updating to Drupal 11.1.3 while this patch is installed, clearing cache for the first time (the first of our post-deployment steps), the following error happens. Removing the patch allows cache to be cleared, and it can be added back. I think a check for an empty or unset whitelist will fix this. If so, I'll update the patch.
Error: Call to a member function get() on null in /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php on line 149 #0 /var/www/html/docroot/core/modules/path_alias/src/PathProcessor/AliasPathProcessor.php(47): Drupal\path_alias\AliasManager->getAliasByPath()
#1 /var/www/html/docroot/core/lib/Drupal/Core/PathProcessor/PathProcessorManager.php(108): Drupal\path_alias\PathProcessor\AliasPathProcessor->processOutbound()
#2 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(392): Drupal\Core\PathProcessor\PathProcessorManager->processOutbound()
#3 /var/www/html/docroot/core/lib/Drupal/Core/Routing/UrlGenerator.php(294): Drupal\Core\Routing\UrlGenerator->processPath()
#4 /var/www/html/docroot/core/lib/Drupal/Core/Render/MetadataBubblingUrlGenerator.php(105): Drupal\Core\Routing\UrlGenerator->generateFromRoute()
#5 /var/www/html/docroot/core/lib/Drupal/Core/Url.php(769): Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute()
#6 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(1613): Drupal\Core\Url->toString()
#7 /var/www/html/docroot/modules/contrib/webform/src/WebformHelpManager.php(146): Drupal\webform\WebformHelpManager->initHelp()
#8 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\webform\WebformHelpManager->__construct()
#9 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#10 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(289): Drupal\Component\DependencyInjection\Container->get()
#11 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(253): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#12 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#13 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(223): array_map()
#14 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(193): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#15 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(167): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#16 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#17 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#18 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#19 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#20 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#21 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#22 /var/www/html/vendor/drush/drush/src/Application.php(219): Drush\Boot\BootstrapManager->bootstrapMax()
#23 /var/www/html/vendor/drush/drush/src/Application.php(185): Drush\Application->bootstrapAndFind()
#24 /var/www/html/vendor/symfony/console/Application.php(284): Drush\Application->find()
#25 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#26 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#27 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#28 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#29 /var/www/html/vendor/bin/drush.php(119): include('...')
#30 {main}
Error: Call to a member function get() on null in Drupal\path_alias\AliasManager->getAliasByPath() (line 149 of /var/www/html/docroot/core/modules/path_alias/src/AliasManager.php).
[warning] Drush command terminated abnormally.
Failed to run drush cr: exit status 1
I agree this is strange, and I don't see an issue in this queue related to that commit. The good news is, it's not yet in a release, and if it ever does make it into a release, no site will be able to update to it since supported versions of Drupal core require 7.8.1 or higher.
Even if this is not rolled back, the constraint should be at a minimum: "guzzlehttp/guzzle": "^6.5.7 || ^7.8"
Could this be due to 🐛 Drupal 11.1 Crash Active . That change made it so "office_hours.theme.inc" will likely never load on Drupal 11.1. We noticed on a custom module that, starting with 11.1, the container is not initialized when the ".module" files are loaded.
We were getting the following error just trying to enable this module on a Drupal 11 site:
Unable to decode output into JSON: Syntax error
AssertionError: assert(is_string($field)) in assert() (line 330 of /var/www
/html/web/core/lib/Drupal/Core/Database/Query/Merge.php). Installing the patch here fixes that issue.
The test failure during the pipeline for this MR is also present when running tests against 8.x-1.x.
I believe the change in the MR attached to this issue will fix the errors during the Printable module tests. The YAML formatting in the schema file was different than the example in the documentation. I ran Printable tests on my local environment and observed the schema error first without the change, and the error went away after the change.
Unfortunately, the "composer" job on both repositories are now failing with the following error:
ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large id=4045914 responseStatus=413 Request Entity Too Large status=413 token=glcbt-64
FATAL: too large
Once this is merged, a new release will need to be made, so it can be used in the Printable module's tests.
Ok, I'm not sure what I was seeing, but the config schema is correct and has been since ✨ DomPDF settings Needs review . I'm not sure why this module is causing test failures for Printable, then.
I tracked the test failure down to 🐛 Config schema for chroot does not match usage Active and am working on an MR for that now.
This is related to and blocking 🐛 Dependency version constraint block Drupal 11 upgrade Active .
It looks like the original updates for Drupal 11 were only tested with Drupal 10:
https://git.drupalcode.org/project/printable/-/jobs/2053860
I confirmed this MR also passes on Drupal 10:
https://git.drupalcode.org/issue/printable-3485496/-/jobs/4021489
Version 3.1.3 will not install on Drupal 11, and as a result, never passed tests. I'm not sure what the path forward is for this, since I don't think the changes in this MR caused the failing tests. Before this MR, Composer would not even install the module to be tested.
See https://git.drupalcode.org/issue/printable-3485496/-/jobs/3266867
If tests are required to pass before merging this, I would recommend pulling the 3.1.3 release or at least not marking it as compatible with D11.
The problem with not merging this is that Drupal 11 sites using this module cannot simply patch it, since Composer will not allow it to install due to the dependency issue. We had to fork the module and point Composer to our version, and other sites will need to do the same.
I ran into an issue with a custom module and another contrib module while both tried to decorate the page cache service. Our code was similar to this update, so I'm curious if this has been tested in a similar environment before being marked RTBC. I'm also curious about the status of this issue while tests are failing.
You could consider testing with Tome to confirm there are no issues with the service decoration:
https://www.drupal.org/project/tome/issues/3499452
🐛
ResettablePageCache overrides other service decorators
Active
Tome Static has a "ResettablePageCache" that provides a "reset()" method. The code in the PR suggests this additional method could be lost if Big Pipe is the outer service (which seems to be the intent with a decoration priority of -1000). Any other inner service decorators that define new methods would also be affected.
It's possible this was caused by 🐛 ResettablePageCache overrides other service decorators Active .
This could also resolve 💬 big_pipe_sessionless error Closed: won't fix .
Looks like that is a schema issue with PDF API, which was probably present before this MR, since the module wouldn't even install to run tests for Drupal 11 prior to this change. I can look into it, but if someone who is more familiar with this module knows how to fix this, that would be helpful.
The only change included in this issue is to allow wa72/htmlpagedom to install a later version of 3.0, which is compatible with Drupal 11.
I created an MR to add the property to the form, but it looks like it is never used outside of the buildForm() method. Could a local variable be used there instead, or does something else read this property elsewhere? It seems unlikely, because this property will only hold the last entity of the ones passed to the form.
Setting autoconfigure: true fixed the service discovery issue for us.
The settings.php method to set the queue backend was deprecated in 10.1:
https://www.drupal.org/node/3338022 →
The documentation should be updated to demonstrate adding the queue_service to the QueueWorker annotation.
I'm still curious about my question from #19 of whether update 8104 is actually required before updating to 2.2. If not, couldn't the last removed be set to 8103, and most sites would avoid this issue. 8104 is just a cache clear if the Tour module was installed, and I'm not sure why you would need to ensure that had happened before updating to 2.2.
Drupal 11's core QueueFactory now uses a service locator instead of passing the entire container, so when a queue is overridden in $settings to use "queue_unique.database", the following error is produced:
Service "queue_unique.database" not found: the container inside "Drupal\Core\Queue\QueueFactory" is a smaller service locator that only knows about the "queue.database" service.
See https://www.drupal.org/project/drupal/issues/3416357 📌 Convert QueueFactory to use a service locator Fixed
How can this module provide its queue_unique.database service so it is available to the QueueFactory? Does the "queue" service need to be decorated or overridden?
It looks like "UniqueQueueDatabaseFactory" needs to implement "Drupal\Core\Queue\QueueFactoryInterface", but that alone did not solve this issue.
See
https://www.drupal.org/node/3417034 →
While testing with Drupal 11, we encountered the following fatal error:
Fatal error: Declaration of Drupal\content_moderation_bypass\Plugin\Validation\Constraint\BypassModerationStateConstraintValidator::validate($value, Symfony\Component\Validator\Constraint $constraint) must be compatible with Drupal\content_moderation\Plugin\Validation\Constraint\ModerationStateConstraintValidator::validate($value, Symfony\Component\Validator\Constraint $constraint): void
I merged in changes from the bot and created a new MR that includes the update to this method definition to be compatible with the base class. I haven't tested with Drupal 10 to see how that might be impacted.
byrond → made their first commit to this issue’s fork.
Bumping this to Major, because the supported release claims it is compatible with Drupal 11, but it will not install without this dependency constraint change, and PHPUnit tests fail with Drupal 11. It's likely this was never tested with D11 prior to that release.
This mainly affects sites that are installed from config after updating to a version of workbench that includes 🐛 Do not use basic_html text format Needs review . The initial site installation attempts to install the optional views config, which is later overwritten by the site config import. So, this is most likely to show up on local dev environments and CI.
byrond → created an issue.
I tested the MR for this issue and can confirm the update hook is gone, so the views are not overwritten.
Here's a patch without the duplicated property in the functional test.
I don't think this sufficiently tests that additional files were not created:
// Assert the files, since a file already existed at that location, one has
// been overwritten.
$files = \Drupal::entityTypeManager()->getStorage('file')->loadByProperties(['filename' => 'test-file.txt']);
$this->assertCount(1, $files);
The file is created during the test with file_put_contents(), so an entity for it won't exist in the database. To confirm this, I removed all but the test from the patch, and it didn't fail.
If type hints are not sufficient, and you need to add the #[Autowire] attribute, you must also include the following use statement in your file:
use Symfony\Component\DependencyInjection\Attribute\Autowire;
Should the hook_update_last_removed() implementation be removed from 2.2.x? My understanding is that the hook is to ensure that updates are not skipped if they are removed and required. Since these database updates are not required for 2.2.x, the last removed update probably does not need to be reported. I assume the updates can remain in 2.1.x, and if they are removed, the last removed would need to be set there (unless they are not required for the latest 2.1.x version either).
I installed this on a Drupal 11 example site and experienced no issues or errors.
Our solution for this was to use Field Formatter Filter → and create a text format with only the Glossify filter. Then, we were able to add that as an additional filter for the fields where we want Glossify to work. Editors do not need access to the text format with this solution, and you don't need to change the text format of your content.
Here is an example Views query:
SELECT DISTINCT "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid", "eh_for_node_field_data"."nid" AS "eh_for_node_field_data_nid"
FROM
{node_field_data} "node_field_data"
INNER JOIN (SELECT "eh_child"."id" AS "eh_child_id", "eh_child"."revision_id" AS "eh_child_revision_id", "eh_parent"."id" AS "nid"
FROM
{nested_set_field_book_page_parent_node_node} "eh_child"
INNER JOIN {nested_set_field_book_page_parent_node_node} "eh_parent" ON (eh_child.left_pos BETWEEN eh_parent.left_pos AND eh_parent.right_pos) AND eh_parent.depth = 0) "eh_for_node_field_data" ON node_field_data.nid = eh_for_node_field_data.eh_child_id AND eh_for_node_field_data.eh_child_revision_id = node_field_data.vid
WHERE ("node_field_data"."status" = '1') AND ("node_field_data"."langcode" IN ('***LANGUAGE_language_interface***')) AND ("eh_for_node_field_data"."title" LIKE 'Some title' ESCAPE '\\')
ORDER BY "node_field_data_created" DESCAnd the error when trying to use the relationship to filter by a field on the related node:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'eh_for_node_field_data.title' in 'where clause'
We experienced the same thing. When using the relationship to get the root entity of the hierarchy, we are unable to filter by anything related to the root (title, content type, etc.). We only have access to the nid of the root node. We tried also adding a relationship to "get the actual content of the node revision" based on the root (Top) relationship, but there is no vid to join by.
This option has been shown in the past to prevent Chrome from crashing during JavaScript tests. Are you sure there won't be any negative side-effects for removing it?
It did not fix our issue. I'm not sure the cache clear will help in this case, because it is trying to create the field, which can't succeed until a field exists to be picked up by getDerivativeDefinitions().
Here is our stack trace:
[error] TypeError: uasort(): Argument #1 ($array) must be of type array, null given in uasort() (line 65 of /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php) #0 /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php(65): uasort(NULL, Array)
#1 /var/www/html/docroot/core/modules/field/field.module(414): Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getPluginId('node', 'entity_hierarch...')
#2 [internal function]: field_field_config_create(Object(Drupal\field\Entity\FieldConfig))
#3 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(409): call_user_func_array(Object(Closure), Array)
#4 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(388): Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object(Closure), 'field')
#5 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(408): Drupal\Core\Extension\ModuleHandler->invokeAllWith('field_config_cr...', Object(Closure))
#6 /var/www/html/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(341): Drupal\Core\Extension\ModuleHandler->invokeAll('field_config_cr...', Array)
#7 /var/www/html/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(434): Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook('create', Object(Drupal\field\Entity\FieldConfig))
#8 /var/www/html/docroot/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(357): Drupal\Core\Config\Entity\ConfigEntityStorage->_doCreateFromStorageRecord(Array, true)
#9 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(1059): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate('field.field.nod...', Object(Drupal\Core\Config\Config), Object(Drupal\Core\Config\Config))
#10 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(842): Drupal\Core\Config\ConfigImporter->importInvokeOwner('', 'create', 'field.field.nod...')
#11 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(663): Drupal\Core\Config\ConfigImporter->processConfiguration('', 'create', 'field.field.nod...')
#12 /var/www/html/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(561): Drupal\Core\Config\ConfigImporter->processConfigurations(Array)
#13 /var/www/html/docroot/core/lib/Drupal/Core/Config/Importer/ConfigImporterBatch.php(31): Drupal\Core\Config\ConfigImporter->doSyncStep('processConfigur...', Array)
#14 /var/www/html/docroot/core/includes/batch.inc(296): Drupal\Core\Config\Importer\ConfigImporterBatch::process(Object(Drupal\Core\Config\ConfigImporter), 'processConfigur...', Array)
#15 /var/www/html/docroot/core/includes/form.inc(974): _batch_process()
#16 /var/www/html/docroot/core/includes/install.core.inc(660): batch_process(Object(Drupal\Core\Url), Object(Drupal\Core\Url))
#17 /var/www/html/docroot/core/includes/install.core.inc(578): install_run_task(Array, Array)
#18 /var/www/html/docroot/core/includes/install.core.inc(121): install_run_tasks(Array, Array)
#19 /var/www/html/vendor/drush/drush/includes/drush.inc(69): install_drupal(Object(Composer\Autoload\ClassLoader), Array, Array)
#20 /var/www/html/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array('install_drupal', Array)
#21 /var/www/html/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php(169): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array, Array)
#22 [internal function]: Drush\Commands\core\SiteInstallCommands->install('minimal', Array)
#23 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array(Array, Array)
#24 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#25 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#26 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#27 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#28 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#29 /var/www/html/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))
#30 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#31 /var/www/html/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))
#32 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#33 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run(Array)
#34 /var/www/html/vendor/drush/drush/drush(4): require('/var/www/html/v...')
#35 /var/www/html/vendor/bin/drush(119): include('/var/www/html/v...')
#36 {main}.
My proposal was to make sure plugin derivatives get created for every entity type, whether or not a field exists already, but I don't know enough about this module to understand why that will break things.
Created an issue fork and rerolled patch from #12 so it will apply to the latest 3.x and 3.3.10.
Still needs tests.
Marking this as "needs work" based on my concern above. An more secure approach is to add trusted proxy addresses to settings.php using $settings['reverse_proxy_addresses']. When these are set, Drupal will strip those addresses from X-Forwarded-For, leaving the client's real IP as the only one in the header. Drupal will trust that IP as long as the request was received from a trusted proxy. This does mean that list must be maintained as the CDN changes those addresses.
The Restrict by IP module allows you to configure the header that contains the client's real IP. This is often configured on the CDN (sometimes called "True-Client-IP") and can be trusted by Drupal when that is the case. We are working on a patch for this module to add the same functionality and will post it in a separate issue.
This should likely not be merged without making this behavior optional (and adding a warning about enabling it). From the getClientIps() method documentation:
* In the returned array the most trusted IP address is first, and the
* least trusted one last. The "real" client IP address is the last one,
* but this is also the least trusted one. Trusted proxies are stripped.
*
* Use this method carefully; you should use getClientIp() instead.
https://github.com/symfony/symfony/blob/6.2/src/Symfony/Component/HttpFo...
We considered using this patch for a client using Akamai but aren't comfortable with the security risk associated with trusting all addresses in X-Forwarded-For.
#430 works for us on 8.8.2 and also passes tests for 8.9, whereas #434 is currently failing.