Problem/Motivation
The content translation module now adds routes without designating them as admin paths. This results in this confusing setup with the default Standard profile:
So although Edit/Delete would lead to Seven, Translate leads to Bartik. Then for any existing translation, Edit leads again to Seven but for adding translations or removing them, you keep being in Bartik. Its a confusing mess of theme application.
Proposed resolution
Inherit admin page state from the edit screen. Nodes have a setting which means they may or may not be admin. Comments don't have such setting and are always frontend edited. Custom blocks are always backend edited, even though they don't have an admin/ path either. The admin status needs to be inherited from the parent route.
Remaining tasks
Commit.
User interface changes
Translate path will follow the same setup for admin theme that the edit path has. Instead of always being frontend themed.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#13 | interdiff.txt | 1.93 KB | Gábor Hojtsy |
#13 | 2276387-tranlate-path-theme-13.patch | 4.43 KB | Gábor Hojtsy |
#11 | interdiff.txt | 1.6 KB | Gábor Hojtsy |
#11 | 2276387-tranlate-path-theme-11.patch | 4.65 KB | Gábor Hojtsy |
#9 | interdiff.txt | 1.05 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyBetter title.
Comment #2
Gábor HojtsyAdding test.
Comment #3
Gábor HojtsyComment #6
vijaycs85Fixed 3/4 fails. For some reason, the 'use_admin_theme' doesn't effect translation tab.
Comment #8
Gábor HojtsyWell, I manually tested the fix while working on it and it manually worked :) So I'm wondering how this is not good :/ I'll see to add some more asserts for the edit page too to make sure alignment is happening.
Comment #9
Gábor HojtsyI thought that routes need to be rebuilt when the theme settings are set, but that seems to be already happening:
So it is a possibility that the JS snippet I use to test for the applied theme does not appear in the test system for some reason. Hum. Anyway, adding a condition for the edit page as well to see if that at least follows the setting or not in the test.
Comment #11
Gábor HojtsySo this proves my rebuilding theory. While the submit function I quoted above does have rebuild, our test uses the config API directly and therefore does not test how Drupal would normally react when this change is flipped. We should test through the UI and set the mode there so the route rebuild is going to happen.
Comment #13
Gábor HojtsySo the final problem was the test did not allow admins to see the admin theme. Doh. That took a bit too much time... Removed testing the edit page because that is already tested in ThemeTest.php in system module. I looked into extending that to test for translate, but there are several things that need to be set up, translatability, etc. for the tab to show up, so better not merged this into system's ThemeTest.php.
I think this is ready now :)
Comment #14
vijaycs85Fine by me.
Comment #15
tstoecklerI think it would have been slightly cleaner to use
AdminContext::isAdminRoute()
here, but since this is very route bound I think it's also fine to use the route option directly.RTBC++
Comment #16
Gábor HojtsyYeah the assumption that that option makes it an admin route is already encoded in the other parts of this route provider, so while we can make it look a tiny bit nicer here, we are directly fiddling with routes here.
Comment #17
tstoecklerReally? Can't find anything like that. Still not against RTBC, just wanted to check for clarity.
Comment #18
Gábor HojtsyThis. In multiple copies.
Comment #19
Gábor Hojtsy13: 2276387-tranlate-path-theme-13.patch queued for re-testing.
Comment #20
Gábor Hojtsy#1987882: Convert content_translation routes to a new style controller just attempted to hardcode translate routes as admin routes. Would be good to let this land sooner than later. :)
Comment #21
Gábor HojtsyUpdated remaining tasks.
Comment #22
alexpottCommitted 5a06f7b and pushed to 8.x. Thanks!
Comment #24
Gábor HojtsyWoot, superb, thanks.