Problem/Motivation
Similar to #3436295: ParamConverterManager lazy services are broken and should use a service locator, PathProcessorManager injects a bunch of services when it is constructed. By adding logging to Container::get():
file_put_contents('/tmp/container.log', str_repeat('>', count($this->loading)) . " $id\n", FILE_APPEND);
we can see the chains of services on an Umami install:
>> path_processor_manager
>>> path_processor_decode
>>> path_processor.image_styles
>>> path_processor_language
>>>> config.factory
>>>>> config.storage
>>>>>> cache.config
>>>>> config.typed
>>>>>> config.storage.schema
>>>>>> cache.discovery
>>>>>> validation.constraint
>>>>>>> container.namespaces
>>>>> language.config_factory_override
>>>>>> language.default
>>>> language_manager
>>>> language_negotiator
>>>>> plugin.manager.language_negotiation_method
>>>> current_user
>>>> language.config_subscriber
>>> path_processor_front
>>> path_processor.files
>>> path_alias.path_processor
>>>> path_alias.manager
>>>>> path_alias.repository
>>>>> path_alias.prefix_list
Steps to reproduce
Proposed resolution
Convert PathProcessorManager to use tagged iterators for the inbound and outbound processors. Sorting by priority will be handled by the iterator. Individual path processors will not be instantiated until path processing takes place.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screenshot 2026-03-11 at 11.35.44 AM.png | 214.02 KB | smustgrave |
Issue fork drupal-3571046
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
longwaveRouteProcessorManager is very similar, let's just do the same there.
Comment #4
smustgrave commentedThere a good way to test this one?
Comment #5
longwaveFrom a drush shell on 11.3.3:
After applying this MR and clearing cache:
This means that the individual path processor service is not instantiated - it will be done on demand when we actually need to process a path. This should be the same result for any service tagged as a path processor or route processor. This makes every single Drupal request a tiny bit more efficient.
Comment #6
smustgrave commentedRan the command and got what was described. I did have to clear cache.
Moving to NW though as there's a merge conflict in the baseline.
Comment #7
longwaveRebased.
Comment #8
longwaveAlso converted to autowiring and removed the constructor docblocks.
Comment #9
smustgrave commentedAppears have unit test failures now.
Comment #10
longwaveComment #11
smustgrave commentedBelieves JavaScript to be random but can’t rerun
Comment #13
godotislateOne small question on the MR.
Comment #16
godotislateSince the applied suggestion was mine, and trivial and in test code, I merged this. Committed 5a0a3bb and pushed to main. Thanks!
This doesn't apply to 11.x because of phpstan baseline. I don't know if it needs to go to 11.x, but it'll need a backport if so.
Comment #18
smustgrave commentedClean backport, actually applied pretty cleanly but all them had some fuzziness.
Comment #21
godotislateCommitted 21292df and pushed to 11.x Thanks!