Needs review
Project:
Content Browser
Version:
8.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
21 Aug 2017 at 09:43 UTC
Updated:
28 Dec 2022 at 17:07 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
k@p commentedActually, I found this is a routing issue, the module is altering route in ContentBrowserRouteSubscriber class for it not to use an admin route. I don't know why it was designed this way, but here is a patch for people who need to use an admin route to get the admin styles
Comment #3
samuel.mortenson@k@p Thanks for the issue! I think this should definitely be configurable - the reason that frontend styles are used is that users usually have control over the look/feel (templates/CSS) of their frontend theme, and style view modes for their content types in there, not in the backend theme. That said, there are benefits to using the backend theme, especially in regards to form consistency.
Comment #4
samuel.mortenson@k@p Hello again, I've created a patch which makes rendering in the frontend theme configurable. I understand how this could feel odd to users so I've disabled it by default as well, for new installs only.
Would you be willing to test the patch out and see if it works for you? You'll need to apply it to your Content Browser install, rebuild caches, then visit
/admin/config/content-browser/settingsand save the form with the "Use frontend theme" checkbox unchecked. After that, Content Browser should be rendered with the appropriate theme.Thanks!
Comment #5
oriol_e9gReroll
Comment #6
oriol_e9gComment #7
oriol_e9gIMO Content browser settings routing should be:
admin/config/content/content_browserInstead of
admin/config/content-browser/settingsto be consistent with Entity browser settings
admin/config/content/entity_browserComment #8
oriol_e9gComment #9
oriol_e9gSorry inverse patch.
Comment #10
oriol_e9gAdded missing content_browser.links.menu.yml for better module settings discoverability.
Comment #11
oriol_e9gComment #12
evanmwillhite commentedIt seems to me the standard for admin modules is that they use the admin theme. If someone wants control over the look/feel of that, then they create a custom version of the admin theme (or a subtheme of it if possible) in their project and override templates and styles there. In essence, this is controllable without making your frontend theme handle it. If you want to make it configurable for the developers, I guess that would be a plus. But I would recommend defaulting to the administrative theme based on this standard.
Comment #13
techninja commentedRerolling patch from #10 on latest 8.x-1.x-dev
FWIW This definitely needs a cache clear between adjustments on the admin page, but I've verified this works.
Comment #14
samuel.mortensonAnyone have time to review the most recent patch?
@evanmwillhite I think #3 explains why the default is the way it is. In theory defaulting to the admin theme is correct, but in practice very few sites I've worked on have any custom CSS in /admin. Maybe in a new major version we can change this.
Comment #15
kevinfunk#13 applies to dev and I am able to switch between the front and admin theme.
Comment #16
kevinfunkComment #17
alphex commentedCan we get this patch rerolled against 1.1? And then, declared fixed for a later release?
Comment #18
kevinfunkReroll