Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment 0
Problem/Motivation
The theme negotiator issue allowed us to determine the active theme on a request, though it did not replaced all the global theme calls.
Proposed resolution
This patch tries to replace most of the global $theme/$theme_key places, though it is tough as it is also used in order to figure out whether the theme system is already initialized.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | interdiff.txt | 638 bytes | dawehner |
| #15 | theme_global-2167619-15.patch | 29.59 KB | dawehner |
| #13 | interdiff.txt | 6.16 KB | dawehner |
| #13 | global_theme-2167619-12.patch | 29.37 KB | dawehner |
| #10 | interdiff.txt | 2.4 KB | dawehner |
Comments
Comment #1
dawehnerJust started with a patch here.
Comment #3
dawehnerups.
Comment #5
larowlanComment #6
dawehnerLet's see what a reroll tells us.
Comment #8
dawehnerThis allows me to install drupal via the UI.
Comment #10
dawehnerThis currently logs out the user immediately after running the tests.
Comment #12
www.cherritvandermerwe.com CreditAttribution: www.cherritvandermerwe.com commentedis there any new patches?
Comment #13
dawehnerThe installer did not worked due to a circular dependency.
Comment #15
dawehnerAnother madness:
"date -> entity.manager -> module_handler -> theme.negotiator -> access_check.theme -> theme_handler -> config.installer -> config.manager".'Comment #17
sunWhy do we need to change all those service definitions here?
I actually wonder whether
ThemeNegotiatoris the right service to consult.And/or, in general, I've the impression we have at least one or two too many theme services right now. Yes, all of them have a discrete purpose, but because they are decoupled, the theme is no longer synchronized between them.
Synchronization is the exact purpose of a global variable: It is guaranteed to have the same value, regardless from where or how you access it.
The lack of synchronization means that the following scenario is completely possible right now:
Service A negotiates theme foo, but service B checks access to theme bar, service C renders content with theme baz, and service D doesn't even have themes foo, bar, and baz in the list of enabled themes. WTF? :)
Thus far, we've been treating the theme system similar to the module system architecture, which makes some level of sense, but when it gets to the actual runtime behavior, then the theme system diverges in significant ways from the module system:
There is only one theme at a time. In order to switch to a different theme, a whole bunch of related and dependent services need to be re-initialized for a different theme.
[whereas that almost reminds of a Container scope...]
IMHO, the next best step is to merge and consolidate various classes and services into a single:
whatDoWeWantToUseToday()+canIUse()+use().Theme\Registry::init()must die → it manually initializes a theme out of nowhere (not even checking for access nor validating anything else).ThemeHandleris a base dependency for the consolidated service in 1) → it supplies and controls which options are available in the first place.ThemeHandlerand 1) can get out of sync way too easily → upon every single change toThemeHandler::$list, 1) MUST be re-instantiated.→ Consequently, we should honestly ask ourselves if 99% of the functionality shouldn't be moved directly into
ThemeHandler.Comment #18
dawehnerI can understand that theme negotiation, access and init is kinda dependent on each other, Registry::init() is horrible but I don't get why this united service can't just always ask the theme handler for the list of themes.
Comment #19
sunComment #20
dawehnerThe other issue takes care of this.