Updated: Comment #N
Problem/Motivation
#1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system introduced a performance regression by unconditionally loading the user even if it's the anonymous users, which makes no sense as those can't have a user theme.
I also think the implementation is broken as $user->theme is a FieldItemList object, it should use the getDefaultTheme() method defined in UserInterface which translates to $user->theme->value. It also seems to be using a deprecated function instead of using the service to check access directly. Setting to major for now, might be critical if we can confirm that it's broken and therefore a regression.
The original issue "fixed" that by adding the field module and the necessary tables to the affected DUBT tests.
I noticed this because #2149107: "View" area handler in Views gives fatal error resulted in a broken HEAD today, re-exposing that problem.
There's also a smaller performance problem that a lot of services with injected dependencies have, that they possibly instantiate a lot of dependant services but will never use them. Yes there's the issue to add lazy service objects but that won't help here, because it's not a service. In this specific cause, it causes DUBT tests to break because they now suddenly need field.module for the field.info service as the user storage controller is instantiated (without being used)
Proposed resolution
Remove it all. It has been a zombie since 2009: #292253: Remove the per-user themes selection from core.
Remaining tasks
RTBC if green.
User interface changes
API changes
$user->theme no longer exists, but it never really did in 8.x....
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | remove-user-theme-2163035-12-interdiff.txt | 1.25 KB | berdir |
| #12 | remove-user-theme-2163035-12.patch | 9.98 KB | berdir |
| #9 | remove-user-theme-2163035.patch | 8.72 KB | berdir |
| #1 | user-negotiator-regression-2163035-1.patch | 3.63 KB | berdir |
Comments
Comment #1
berdirComment #2
dawehner+2
The D7 code looks like the following:
so I guess global $user->theme was just not set for the anonymous user before? This makes 100% sense to be honest.
Regarding the bug: I guess this never worked ... given that I just copied the old code from drupal_theme_initialize...
The amount of broken HEADs is just too damn high.
Comment #3
berdirIn the old code, it works directly on global $user, which is a UserAccount, which contains SELECT * from users as raw values, so it probably worked better than now :)
Yeah, I bit confused why you call a deprecated function that has a service replacement in a new class, because calling that directly should have expose this, as the function has that weird is_object() check.
Comment #4
Crell commentedIt makes sense to me why we're not getting the storage controller (presumably performance, so if the user is anon we may not even initialize the storage controller?), but that's non-obvious. It could use a comment, either here or further down.
Otherwise this patch looks sane to me.
Comment #5
berdirYes, that's exactly what it's about.
I think it's mostly the *change* that needs a comment/explanation (which is in the issue description somewhere), not the final code, but sure, I can add a comment.
Comment #6
dawehnerOH I see. Do we want another issue to replace drupal_theme_access()?
Comment #7
Crell commenteddawehner: Probably, yes.
Berdir: Mostly I want to make sure someone doesn't try to clean it up later, not realizing that there's a reason we're using the nominally longer code. It's a minor point either way; the code itself looks fine.
Comment #8
berdirOh wow, this is too awesome.
Per-user themes were removed in *2009*. It doesn't even existin in D7. Apparently we forgot to remote that check and the storage for it, we just removed the form alter. See #292253: Remove the per-user themes selection from core.
Going to re-purpose this issue to remove the remaining instead. Saves me from writing test coverage for it :p
Comment #9
berdirBye bye.
Updated proposed solution in issue summary ;)
Comment #10
dawehnerI always assumed that the feature was still supported on the API level, though you could always rebuild it using hook_custom_theme in D7.
Some other DUTB tests we could adapt:
Have you tried to remove them?
Comment #11
berdirAs you said, the part in core is easy to reproduce with the hook/service, reserving storage for something that core doesn't offer makes no sense to me.
I only removed it from test classes that had it added in the original patch, those two need it for different reasons, the first actually stores and saves entities and obviously needs it and the second needs the field.info service due to a entity query in the menu link storage controller (which will need it anyway as soon menu links are converted to Entity Field API.
Comment #12
berdirAh sorry, you did touch those tests but only added the users table, I didn't check for that.
Removing those calls again.
Comment #13
dawehnerThank you!
Comment #14
star-szrThis is great. Nice find @Berdir!
Comment #15
catchNot sure if it was intentional leaving the API support for this in when it was originally removed, but it's definitely redundant now - contrib can add the negotiatior and storage back just as much as the form alter.
Committed/pushed to 8.x, thanks!
Comment #16
andypostSeems we need change notice for that, and maybe update function?
Comment #17
catchNo need for an update, we'll just not migrate that from 7.x. However yes this does need a change notice.
Comment #18
berdirCreated https://drupal.org/node/2164115.
Comment #20
sun