At the moment we persist the url_generator service. This service depends on many services that are not persisted and also has in bound and out bound path processor injected through a compiler pass. Basically it just does not make sense to persist this service.
The place where this is tricky is update.php because it futzes with it to present the correct url to home and admin pages.
The current approach is to use the UpdateServiceProvider
to alter the url_generator
service by adding the necessary method calls to create the correct URLs. There is no risk of compiling this container since the DrupalKernel
is instantiated with dumping disabled in update_prepare_d8_bootstrap()
.
Persistence of the url_generator was added in https://drupal.org/comment/7212822#comment-7212822
Comment | File | Size | Author |
---|---|---|---|
#9 | 2176669.9.patch | 5.45 KB | alexpott |
#9 | 7-9-interdiff.txt | 2.63 KB | alexpott |
#7 | 2176669.7.patch | 5.5 KB | alexpott |
#7 | 2-7-interdiff.txt | 811 bytes | alexpott |
#2 | 2176669.2.patch | 5.29 KB | alexpott |
Comments
Comment #2
alexpottMaybe this is a better way of ensuring that the url generator behaves as we want it to.
Comment #3
alexpottFYI futzing the url generator for update.php was done in #2017769: Links from update_helpful_links() should point to site root and not to update.php
Comment #4
alexpottComment #5
alexpottComment #6
dawehnerPersisting the url generator is certainly a bad workaround, so neither does symfony fullstack: https://github.com/symfony/FrameworkBundle/blob/master/Resources/config/...
We could also replace that global variable by a kernel parameter.
I wonder whether we should explain how setScriptPath('') will work.
Comment #7
alexpott@dawehner not sure how we could actually implement your suggestion in to use kernel (or container) parameters.
Patch documents why we are using setScriptPath().
Comment #8
damiankloip CreditAttribution: damiankloip commentedIs this empty method important?
two \\ (sorry!)
Maybe wrap in ''.
I know this is c&p but this is the only one using double quotes! Again, sorry.
I feel that this variable should just use underscores, and not camel casing.
Comment #9
alexpott1. Fixed. Not at all - it was part of another approach I was exploring :)
2. Fixed
3. Fixed
4. Sure
5. Sure
Comment #10
dawehnerThis is ready now, after the review of damian.
Comment #11
catchLooks fine.
Committed/pushed to 8.x, thanks!