- 🇨🇷Costa Rica robert-arias
I think it’s a mix of both: it was a documentation error during D8, but now it’s an unintended consequence of #3006086: update.php should not process path aliases → .
Proposal:
Remove the
UpdateServiceProvider
alter function that it’s removing the tags from the service in charge of retrieving the path alias. Let me explain why:It did make sense to remove the service during D8 because, at that time, sites might have not run the updates that were in charge of migrating the path aliases into full featured entities. However, in D10, it doesn’t make sense to keep the
UpdateServiceProvider
alter (and honestly, not even in D9, but I think it’s wise to keep the removal in D10), because sites upgrading to D10 should already have the path alias entity schema and related config.
The recommended flow for upgrading to D10 is going from version to version (i.e. if my site it’s on D8, I should update it to D9, and finally to D10). When upgrading, if the site it’s on D8, we have to run the latest D8 updates to then move to D9, so, when running those updates, the updates in charge of creating the path alias entity should have run - making the alter function meaningless in other D8> versions.So, why are path aliases not available during updates?
This is just to give more context into the issue - you can skip it.
When running updates (either through update.php or Drush), the
UpdateKernel
is used, instead ofDrupalKernel
(UpdateKernel
extends fromDrupalKernel
, but overrides some functions to add update-specific logic and minimal handling of the request). One of the functions it overrides it’sdiscoverServiceProviders()
, which, as the name implies, it discovers custom service providers (that allows to register or alter the DI container, depending on the interface implemented). However, theUpdateServiceProvider
is undiscoverable (according to how the discovery happens, which it’s another topic), so, what theUpdateKernel
does is add it itself.
When handling the custom service providers, the first action that will run is theregister
, then, upon container compilation, the compiler passes are going to be triggered, and among then, the compiler pass in charge of running the alter function of the discovered service providers (the compiler pass in charge isModifyServiceDefinitionsPass
).
It’s right at this point where the service tags are removed from thepath_alias.path_processor
service, making it “undiscoverable” when thepath_processor_manager
service collector is run to retrieve tagged services (in this case, services tagged withpath_processor_inbound
andpath_processor_outbound
tags) during the execution of theTaggedHandlersPass
compiler pass.When updates are run, they’re run through the Batch API - they’re gonna be run in order: first updates, then post updates. Each function will trigger a request into the
UpdateKernel
, making the path alias service unavailable. The reason the post update documentation says:[...] At this stage Drupal is already fully repaired so you can use any API as you wish
is because, when running the
UpdateKernel
, if there are unresolved dependencies, they’ll be removed when running updates, because, after running the updates, theoretically, they should be resolved (seeUpdateCompilerPass
if you wanna know more), and the container is rebuilt (after running updater hooks, a cache flush is run). At this point, post updates hooks can make use of any API; however, that’s not gonna be the case for the path alias service, because it’ll always be removed whenever theUpdateKernel
is being used (the same happens in Drush, though it handles it a bit differently, but it maintains the same principle).Beware
Although this patch makes the
path_alias.path_processor
available, there's still an issue related to it when making use of it in certain routes. See: #2548095: Add option to Url() to force the site base_url to be used →