Allow a theme to prevent itself from being used as an admin theme

Conversely, what about a theme that is only intended to be an admin theme?

While having themes that are available as both is a good thing, I think it's time that we allow themes to restrict themselves if they want, to not be set as an administration theme. Contributing and supporting a theme that supports hundreds of modules is prohibitive enough, but supporting their backends as well is even more of a barrier, especially since some contrib modules can have, um, 'special' UIs.

Especially with Seven in core, the pressure for themes to be fully admin-supportive seems to be somewhat alleviated.

What about an optional line in the theme's .info file which could specify this? With "both" being the default if not included.

Related issue, since the UI is changing in #491214: implement the top level Appearance / Choose Theme admin page, and would need to have the links reflect what can be enabled for what.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bojhan’s picture

So I spoke to JohnAlbin about this as well. It is indeed somewhat wierd to require modules, which live solely in the administration space to work for interfaces such as Garland, and whatever new core theme.

However and this is sturdy said, the use case for both is going to be awkward. I'd rather have something that favors, administration theme - to be able to say, this is only an administration theme. Then themes to say, I am both or not.

stephthegeek’s picture

Hey Bojhan, thanks for your comment. I'm afraid I'm not 100% clear on what your conclusion is stating. Are you saying you support it as a general concept but not that themes should be allowed to restrict this?

Bojhan’s picture

I support :) I think, this is a good change - however we should definitely look at all the technicalities of this.

Gábor Hojtsy’s picture

Well, as far as #491214: implement the top level Appearance / Choose Theme admin page evolves, it might not have links directly in the main theme setup screen. Also, it could easily be a WTF for users if they cannot turn certain themes to be an admin theme or front end theme without further explanation.

seutje’s picture

can't help but get the feeling this is a step in the wrong direction, because this would take away the pressure to use generic css techniques and it makes it very tempting to limit support significantly

also it would require quite some work, since an admin theme basically overrides the default theme whenever the context is considered administrative, so what if there's no admin theme active and the current default theme is one that's "not to be used as admin theme", should it then fall back on the bare defaults (these: http://api.drupal.org/api/file/modules/system/page.tpl.php/7/source http://api.drupal.org/api/file/modules/node/node.tpl.php/7/source http://api.drupal.org/api/file/modules/block/block.tpl.php/7/source) or should it attempt to use the default theme anyway?

imo, the opposite makes a whole lot more sense, half the true admin themes out there weren't made to function as a default theme anyway

stephthegeek’s picture

"because this would take away the pressure to use generic css techniques and it makes it very tempting to limit support significantly"

That's what goes in the "plus" category for me ;)

Unless by "generic" you meant "standard", but I don't think that is the case. It *does* mean that designers and themers can get away from the Drupally look more when creating themes. There are themes/designs out there that couldn't really be admin themes in practice anyway, but if you give them the ability (and the default is to use it everywhere), the end users *will* try, even if you tell them not to. This is simply making that social/documentation convention a technical restriction so users don't think their site/theme is broken.

I don't think "you must support the administrative interfaces of X thousand contrib modules" was ever in the intended spirit of creating a contrib theme.

Gábor Hojtsy’s picture

@stephthegeek: "you must support the administrative interfaces of X thousand contrib modules" I think was part of the original goal, but the administrative interfaces grown so complex that it is not too feasible, I'd agree.

stephthegeek’s picture

Just to provide some specific context, a perfect example is Acquia Slate (or any dark theme). Since it has a dark background with light foreground text/links, any module which specifically sets a light background anywhere (say.. Views/Panels. or anything with a light table, coloured divs, tabs, different gallery modules, etc) and doesn't also set a dark text/link colour on these will render its text nearly invisible, which then understandably get reported as theme bugs.

Now, the proper thing to do would be for those modules to make sure they also specify a foreground colour, but they rarely do since the vast majority of themes are light. In order to "fix" this in the theme, we'd have to jump in on each of these modules' class/ID declarations that set backgrounds and also set foregrounds.

That to me is a perfect example of why it's not really feasible.

I'm all about leaving it as an option, and even the default for themes to be available as administrative themes too. But I think it inhibits creativity and means that themes can be incorrectly thought to be broken if they don't support the admin section.

seutje’s picture

I see your point, and I'm not going to pretend I know more about what making a generic theme that works for everything is about, I usually make a theme based on a design and a spec, so they pretty much only fully support the modules running on that site, and pushing this change wouldn't affect me at all, personally
in your particular example, I'd say it's the module's default theming that doesn't make a lot of sense and I'm sure that there's cases where it's lot more murky

but then why do we have admin themes at all?

Jarek Foksa’s picture

can't help but get the feeling this is a step in the wrong direction, because this would take away the pressure to use generic css techniques and it makes it very tempting to limit support significantly

The problem with admin pages is that you can't rely on generic stylings. In order to make admin pages look consistent with other parts of the website you have to write a lot of very specific styles. This is especially true with Drupal 7 and modules such as overlay or dashboard. Needless to say that the markup and core stylesheets on admin pages are awful.

Assuming that all themers will be adding support for admin pages is at least overenthusiastic.

reglogge’s picture

FileSize
1.79 KB

Here's a very simple patch that would allow a theme to declare itself an admin-theme by adding

type = admin-theme

to it's .info file.

All the patch does is then not display the link "Set default" for the theme on /admin/appearance. Inexperienced users are then not able to enable an explicit admin theme as their default theme.

In effect this patch adresses seutjes comment from #5

imo, the opposite makes a whole lot more sense, half the true admin themes out there weren't made to function as a default theme anyway

The patch writes this line to Seven theme's .info file to illustrate the effect - and yes, the condition in system.admin.inc could probably be written much better.

reglogge’s picture

Status: Active » Needs review

bot.

Jeff Burnz’s picture

Cant we have it both ways - so we can declare either or both?

reglogge’s picture

This patch also checks if type = admin-theme is set for determining the content of the select box where users can select their admin-theme.

- The default theme is always there to be selected
- Themes which don't declare type = admin-theme in their .info file are not added to the select list.

This would mean that theme authors would explicitly have to declare in their .info file whether they wish their theme to be usable as an admin theme out of the box. Developers would still be able to add this declaration to whatever theme they want.

Also, this would of course have to be documented and probably a test written for.

Status: Needs review » Needs work

The last submitted patch, settings-admin-theme-1.patch, failed testing.

reglogge’s picture

Status: Needs work » Needs review
FileSize
3.63 KB

Hm... this was stupid.

This patch is better:

We now have two possible values for themes
- type = admin-theme puts a theme into the admin theme select box and disables setting it as default.
- type = frontend-theme removes a theme from the admin theme select box and enables setting it as default.
- Themes with no declaration can be a default or an admin theme

So now whenever a theme developer wants to either define his theme as exclusively an admin theme or a frontend-theme, he can do so.

EDIT: The changes in garland.info and seven.info serve merely to illustrate the functionality and have to go out of course. Also, they might trigger some interesting testbot-failures :-)

bleen’s picture

Status: Needs review » Needs work

A) I think this is a hugely awesome idea and should definitely be part of core
2) Sadly, I have a feeling this will be relegated to D8 - I cant think of any way to spin this as anything other than a (super-cool) new feature
III) Patch review:

Shouldn't this:

+    if (empty($theme->info['type']) || !($theme->info['type'] === 'frontend-theme')) {

be

+    if (empty($theme->info['type']) || ($theme->info['type'] !== 'frontend-theme')) {

(and the same later on with ($theme->info['type'] !== 'admin-theme'))

reglogge’s picture

Title: Allow a theme to prevent itself from being used as an admin theme » Allow a theme to set itself as an admin or frontend theme exclusively
Status: Needs work » Needs review
FileSize
353.57 KB
2.65 KB

@bleen: I share your premonitions :-(

However, it's not an API change, easily understood, easily documented and might just slip in. It doesn't change anything for existing themes but might prevent lots of WTFs, when new users enable Seven as the default theme and are disappointed. Also: More power to the themers!

New patch attached for completeness' sake. This time without the changes in garland.info and seven.info so it could be committed as is. Also renaming.

Plus a screenshot of the *new* /admin/appearance when garland is defined as a front-end theme (can't be selected as admin theme) and Seven is defined as an admin theme (can't be set as default).

Crossing fingers and whistling in the dark...

Bojhan’s picture

Whoa, this does not look right. There are no indicators why Seven can not be set as default. To me its pretty clear that we need to think about designing that page to hold "normal" themes and "admin" themes. I am fine with not even displaying Seven, and just having it in the drop down.

reglogge’s picture

This patch is clearer by taking out all the negations with !== and thusly making the code easier to understand.

Documentation would have to go here, I guess: http://drupal.org/node/171205

EDIT: Sorry Bojhan, didn't read your last comment before posting this.

Jeff Burnz’s picture

Category: feature » bug
Status: Needs review » Needs work

If we scale this back to just preventing a theme from being set as an admin theme perhaps we don't need a UI change, which is certainly going to get this bumped to D8.

Therefor:
- Any theme can be enabled and set to default.
- Not all themes will appear in the Administration themes list.

To do this we would need to:

1 - Add the "type = frontend-theme" option for themes that do not want to be admin theme.
2 - Remove the "Default theme" option.
3 - Add some documentation.
4 - ?

I am changing this to a bug because at the moment any theme can be set to the admin theme, which can cause the site to become unusable, or at the very least important admin pages can become unusable. We should remember that in D7 themes have access to things like hook_page_alter, or even the new proposed hook_system_region_list_alter. Allowing any theme to be set as an admin theme is a major WTF and UX fail.

xmacinfo’s picture

Version: 7.x-dev » 8.x-dev

Moving to 8.x (which could be backported to 7.x).

I prefer adding the “type=admin” line in the info files only for admin themes.

We don't need to add the type line to every single theme since that by their majority they are all front-end theme anyway. We just need to highlight the few exceptions that are indeed of type admin. That way we could hide the few admin themes behind a tab.

bleen’s picture

FileSize
3.63 KB

re #22: I disagree ... this issue is as much about preventing admin themes from being chosen as the front-end theme as it is about front-end themes being chosen as the admin theme. The former is just plain common sense. A theme like Rubik is simply meant for admin tasks only, so why offer that to users when choosing their front-end theme. The later (as Jeff pointed out in #21) is skating very close to the line of "bug" because a user who chooses most of the contrib themes as their admin theme risk loosing some admin abilities.

That all said, the patch in #20 is careful not to require that a theme add "type" to its info file so we will not be forced to change all of those themes out there; in that case the theme will simply be treated as "both."

Attached is a reroll of #20 with a couple minor changes:
- made "seven" an admin theme
- added an "administrative only"|"front-end only" note to the theme name.

Appearance | d8

As a side note ... man that theme admin page needs some work!

The last submitted patch, adminonlytheme-550102.patch, failed testing.

bleen’s picture

Status: Needs work » Needs review
FileSize
4.28 KB

This patch fixes the tests...

xmacinfo’s picture

Status: Needs review » Needs work

this issue is as much about preventing admin themes from being chosen as the front-end theme as it is about front-end themes being chosen as the admin theme.

I do agree. But why special-case all themes (frontend vs admin)?

+++ b/modules/system/system.admin.inc
@@ -222,6 +228,15 @@ function system_themes_page() {
+    if (isset($theme->info['type'])) {
+      if ($theme->info['type'] == 'admin-theme') {
+        $theme->notes[] = t('administration only');
+      }
+      if ($theme->info['type'] == 'frontend-theme') {
+        $theme->notes[] = t('front-end only');
+      }
+    }
+

We need to identify and mark only the admin themes so that:

  • Themes cannot be selected as Admin theme, unless the theme is marked type="admin".
  • “Admin” themes cannot be selected as Default theme or enabled.
  • The Admin theme drop down lets select (and enable) only themes marked as type="admin".

In other words, all “admin” themes should be invisible on the main Appearance page, or visible only on the Administation theme fieldset (or behind a localtask tab).

Powered by Dreditor.

xmacinfo’s picture

I see. We have 3 types of themes.

  • Regular themes.
  • Admin-compliant themes.
  • Admin-only themes.

We should special-case only the later two.

type=admin-compliant
type=admin

For the remaining (front-end) themes and new theme, we should not require the “front-end” type.

Admin-compliant themes would show on the Appearance page and be available in the Administrative theme section.

danillonunes’s picture

#27 The trouble with this approach is that any possible-admin theme needs to be explicitly marked as that. Or, if I made an frontend contrib theme, I can say: "I do not support this theme being used in admin, but if you want to use you are allowed to", but I cannot do that with your theme-types, because if I a flag my theme as an admin-compliant, then users will expect me to support it, and if I don't, users will have no way to selectt it as admin at their own risk.

In other words, the theme type attribute might set exclusive-use cases only, like this theme is indeed to be used as admin-only or frontend-only, but if the themer don't set this attribute, the theme will work as a regular theme works today.

bleen’s picture

Status: Needs work » Needs review

I agree with #28 ... setting back to needs review

Jeff Burnz’s picture

#1167444: Not clear which themes are enabled and disabled proposes a redesign of the Appearance page, it will need to take into account changes made by this issue. I tend to like the idea of additional labels but I'm not sure that its enough or that they're being implemented in an optimal way - we need more visual separation between admin and front end themes. We should work on the UI in the other issue.

As for this patch - personally I'm not a big fan of the hyphenation, and would prefer something like:

type = admin theme
type = frontend theme
joachim’s picture

type = admin theme
type = frontend theme

... why do we even need to say 'theme'? We're in a theme .info file; the context is clear :)

jvsouto’s picture

FileSize
121.52 KB
144.18 KB
146.25 KB

an idea...

All contexts, no parameters in the .info file
All contexts

Only frontend, type = frontend
All contexts

Only backend, type = backend
All contexts

xmacinfo’s picture

Status: Needs review » Needs work

Yes! That makes sense.

marcingy’s picture

Category: bug » task

See also #542828: Do not special case disabled admin theme and this is not a bug it is a task

Bojhan’s picture

sigh @ always categorizing usability issues, to tasks. There is no reason, a usability problem could not be a bug - its how one defines an "error", somewhere someone decided that should only be limited to a code error message.

Jeff Burnz’s picture

Category: task » bug

@ joachim #31, I was just thinking to use the theme suffix to be consistent with "base theme" in info files, I am not wedded to any such things, front and admin seem fine to me.

Wooo marcingy, this is bug!

"..at the moment any theme can be set to the admin theme, which can cause the site to become unusable", that is a UX bug my friend, through and trough.

xmacinfo’s picture

Whichever names we give to “admin” and “site” theme, whether “admin/frontend”, “backend/frontend”, etc., the point raised in #32 still stands.

We should make both theme type optional in the .info file.

type = frontend : Cannot be used as an admin theme
type = admin : Cannot be used as the site or frontend theme

Type undefined : Can be applied as site or admin theme (for example Garland)

There are still a lot of themes that can work in both admin and frontend. That was the case before Drupal 7 and is still the case. It’s just that most users will stick with Seven for administration.

jvsouto’s picture

Issue tags: +d8ux, +D8UX usability

I think this is an issue of usability
For new users, the themes together cause considerable confusion

JohnAlbin’s picture

Status: Needs work » Needs review
Issue tags: -d8ux, -D8UX usability

#25: adminonlytheme-550102.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +d8ux, +D8UX usability

The last submitted patch, adminonlytheme-550102.patch, failed testing.

JohnAlbin’s picture

Issue tags: +d8mux

type = front-end : Cannot be used as an admin theme
type = admin : Cannot be used as the front-end theme
Type undefined : Can be used as front-end or admin theme

I agree with this approach. There definitely needs to be a larger improvement to this page, but we should do iterative changes. This being the first.

jvsouto’s picture

type = front-end : Cannot be used as an admin theme
type = admin : Cannot be used as the front-end theme
Type undefined : Can be used as front-end or admin theme

Sounds good to me.

jvsouto’s picture

Issue summary: View changes

Add original title back to issue summary so that first sentence of summary makes sense

LewisNyman’s picture

Version: 8.0.x-dev » 8.1.x-dev
Category: Bug report » Feature request
Issue summary: View changes
Status: Needs work » Postponed
Issue tags: -D8UX usability, -d8mux +Usability, +frontend, +TX (Themer Experience)

I would love for this to happen, but this kind of change is frozen now.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

emma.maria’s picture

Status: Postponed » Needs work

Re-opening this!

As long as themes have an undefined default set which implies that the theme is of both types. And then the options of frontend or admin can be set we can still do this now.

Personal note : I would love Bartik to not be listed as an admin theme option in the select dropdown. The amount of "bugs" for it acting as an admin theme are now getting out of hand. Therefore I'm very happy to help push this issue forward in anyway I can.

rachel_norfolk’s picture

I really like this and have only two questions:

  1. Can we make this just as a UI change? i.e. make the listings at admin/appearance as above but still allow determined devs to set it “wrongly” via code/yml?
  2. would someone mentor me making the change as described? Not worked in this area at all before :)
xmacinfo’s picture

Please take a look at #42 and #43.

Defining a theme type should be optional, hence “undefined” for contrib modules. For core, we can make Seven as an #admin type and Bartik as a #front-end type as emme.maria points out.

We can split the work in two:

1. modify all core theme to be either #admin, #front-end or undefined (no change required for the last ones).
2. work on the theme listing page and allow only #admin theme in the drop down.

We could them merge the two patch together.

We can also look at patch in #25 and evaluate how much work is involved to make it work in Drupal 8.1.x branch.

The key in the info file must be something like “theme-type” now, as the main “type” key is used.

Suggestions:

+    if (isset($theme->info['theme-type'])) {
+      if ($theme->info['theme-type'] == 'admin') {
+        $theme->notes[] = t('administration only');
+      }
+      if ($theme->info['theme-type'] == 'front-end') {
+        $theme->notes[] = t('front-end only');
+      }
+    }

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andypost’s picture

dww’s picture

Coming from #3103375, just reading all this now.

Since some sites want an admin theme as the front end (e.g. some decoupled projects), I think the main thing we need is a bool flag for themes to say they can work as admin themes or not, and to restrict the choices for the admin theme selector accordingly. This 3-way flag seems overly complicated. Any theme could be set as the default theme. Only some themes can be set as admin themes. Contrib themes can mostly opt out of trying to be admin themes, unless that's what they want to be.

Don't want to hijack prior discussion here, but if we're going to close #3103375 as a dup, can we re-scope this to be a simple bool and only impact the 'Administration theme' selector?

Thanks,
-Derek

xmacinfo’s picture

Yes, but what do we do for themes that would act only as admin theme? Currently, any theme, including Seven can be set as the front end theme.

Adding a simple admin bool would only help filter the list in 'Administration theme' selector. Of course, that would already be a very nice addition to Drupal.

The question is, though, do we want to block an admin theme from being set as front end?

dww’s picture

Re: "do we want to block an admin theme from being set as front end?"

I tried to say 'no':

Since some sites want an admin theme as the front end (e.g. some decoupled projects)
...
Any theme could be set as the default theme.

The theme author can't know if an "admin" theme makes sense for a "front end" theme on any given site - that's up to each site to decide.
But a theme author can know if a theme supports the core admin UI or not.
Hence a single bool, not a 3-way flag.

Thanks,
-Derek

xmacinfo’s picture

OK. That makes sense.

Now, what would be the changes required in the info file?

type: theme // no change here
admin theme: true // new bool flag

andrewmacpherson’s picture

The flip-side of #60 is that theme authors also can't know that their theme won't be used for the admin pages.

Community membership sites (forums, etc) are the classic use-case for this. Users join a forum as community member, then later they might graduate to various moderator roles. Sites like this have a good reason to use a single theme, without distinguishing the "admin" areas. Indeed, it's worth remembering that the Drupal originated as software for such community membership sites, and Drupal core didn't make the distinction between a front-end and admin themes prior to Drupal 7.

shaal’s picture

I thought we can make it with BC, picking from #61

type: theme // no change here
theme: frontend / admin / both / null // optional, new setting

Making this optional, means that old(er) themes can keep being used as they always were.
Otherwise, it can prevent users from choosing a theme that wasn't meant to do certain tasks.

In special cases, advanced users can create a "new" parent-theme, when they want to override Claro to become frontend-able, by changing that setting in the info.yml of their new theme.

dww’s picture

+1 to #61
-1 to #63 -- I really don't think we want a 3 or 4 way flag, we need an optional bool. But I'll hopefully be able to stop repeating myself about that. ;)

Re: #62: The theme author can know that their theme shouldn't be used for the admin theme. ;) That's the point of this issue. If I haven't done anything to style the admin UI, I want to warn the world: "My thing doesn't work as an admin theme, unless you want to do a lot of custom CSS yourself, in which case, you should make a subtheme and set the admin theme: true flag in the subtheme." More or less. ;)

Also, thanks to the miracle of hook_system_info_alter(), it'd be easy to have a trivial contrib module that will ignore this and let site admins use anything they want as an admin theme again. Opt-in to "yeah, I understand it's using something not as designed, I'm prepared to accept the consequences"...

andrewmacpherson’s picture

The theme author can know that their theme shouldn't be used for the admin theme. ;)

Shouldn't isn't the same as can't. Maybe the theme author doesn't intend it to be used for admin pages, but that's not a good reason to prevent someone using it as an admin theme if they want to. Freedom zero of free software is the freedom to run the software for any purpose; preventing a theme from being used on admin pages because the themer didn't intend it runs contrary to that spirit.

If I haven't done anything to style the admin UI

... then that's fine. A lot of the admin UI theming comes from modules, which separate base and admin stylesheets out. Plenty of entity listings just need basic table styling, which any front-end theme might provide. A local action link (e.g. add user) is just a link, and it'll still work fine even if it doesn't have fancy button styling. If any particular admin pages don't look perfectly polished, that's OK because maybe forum moderators won't see that page.

Today I installed the Umami demo, then set the admin theme to Umami. It's perfectly functional! Granted it looks half-baked, not polished or beautiful, but it works. The most noticeable thing which it lacks is nice table styling, probably because the Umami demo doesn't have any tables on show in the front end. Most of the special admin UI pages are have the right layout: appearance, status report, available updates, module installation, block admin, and views UI. The worst thing I noticed was that the arrow icon is missing from drop buttons until you hover on it. Yet none of that would be a good reason to prevent someone from enabling it as an admin theme. (Conversely, the main thing I learned is that Umami lacks a key feature of a general-purpose front-end theme, namely some table styles.)

Just the other day on Slack, in the d9-theme channel, someone remarked that Olivero looked really nice as an admin theme, even though they knew it wasn't intended for that.

Also, thanks to the miracle of hook_system_info_alter(), it'd be easy to have a trivial contrib module that will ignore this and let site admins use anything they want as an admin theme again.

This isn't a miracle, or trivial. It's a hurdle which not everybody can get past. Maybe it's trivial for a developer to write, if they know about that hook. A site builder isn't necessarily a developer, but enabling a theme is a site builder task. It's excluding some site builders, on the mere basis that they aren't developers.

markhalliwell’s picture

Maybe the theme author doesn't intend it to be used for admin pages, but that's not a good reason to prevent someone using it as an admin theme if they want to.

I see where you're coming from and can sympathize that some may consider this as just another restriction/limitation.

However, I see this in another light. More of a control/constraint to guide people in the correct direction; a diversion dam if you will.

By placing a constraint on which themes are allowed to be set as an administrative theme to only those themes which have explicitly flagged their theme as such ensures that other people don't start using a theme that doesn't support administrative markup/areas.

On d.o and even custom clients sites, I have only run into a handful of true "administrative" themes over the years; while the majority just use whatever is provided by core.

I cannot tell you how many times I've gotten issues in https://www.drupal.org/project/issues/bootstrap for "This doesn't work in /admin/.../..." and I close them stating "Correct. This isn't an admin theme; it's a base theme."

We actually need more strongly typed verbiage/constraints like this in place when it comes to themes. It's bad enough that people still call themes "modules", the worst thing we can do is continue letting arbitrary front-end themes to continue being used as in an administrative capacity.

---

Regarding the actual property, I personally would prefer just admin: true as I'm not partial to delimiters in property keys, however, I can see that since this is in the context of a generic info file, semantically admin theme does make more sense (just like base theme). Regardless of the chosen property name, it should definitely just be a simple boolean that defaults to false when not explicitly set to true.

We don't need a tri-state property.

The easiest solution for everyone is to create an "admin theme" from an existing "front-end theme". All anyone would have to do is create a new [sub-]theme and literally just specify the "front-end theme" as its base theme add set admin theme: true to its info file, that's it.

It would automatically inherit all the same functionality as the front-end theme, so no need to c&p files. It would also explicit that it intends to be an admin theme as well. It's this kind of specificity that is key.

dww’s picture

+10 to @markcarver in #66.

Re: #65: I didn't expect site builders would know how to use the hook. I was expecting that I could publish a 10 line contrib module called something like "Admin theme override" that lets a site use any theme as an admin theme. If folks couldn't figure out how to subtheme along the lines of #66, they could install this module and directly use umami as their admin theme if they wanted.

Please see #3103375: Let themes indicate whether they work as front-end and/or admin themes where the core front-end framework maintainer, @lauriii, suggested this change.

Thanks,
-Derek

andrewmacpherson’s picture

Can we clarify what "indicate" means? Is this about describing author's intended use, willingness to support it, or actually preventing it's use?

markhalliwell’s picture

All the above.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

AaronMcHale’s picture

I'm just going to quote my comment on #3103375-20: Let themes indicate whether they work as front-end and/or admin themes:

I think there is some value in guiding people towards making smart choices, in this case that is using the appropriate theme for the job.

However, I fully agree with @andrewmacpherson in comment 18 (#3103375-18: Let themes indicate whether they work as front-end and/or admin themes), there are very valid use-cases for using the admin theme as the front-end theme, headless Drupal or using Drupal as a business-process type of system are two very valid ones. I have more than one of those "business-process focused sites" that uses Gin as both the admin and front-end theme. Similarly, there are valid use-cases where you would want at least some of the administrative UI to use the front-end theme, maybe you have a community site with some users who have moderator level permissions, and you don't want them to have a jarring experience where they have to jump in and out of differently styled pages, I have a Drupal 7 site with that exact use case.

I think there are several completing concerns at play here:

  1. For new users to Drupal, we want them to have a good experience learning and getting to know Drupal, so we should help them by guiding them to make smart choices about how they configure Drupal.
  2. There are very valid use-cases for using the same theme as the admin and front-end theme (a headless installation, a business-process system, a community site, etc).
  3. Theme developers may only want to support their theme being used in one particular context (front-end or admin), as to support the other context would require additional work and potentially additional user/community support which they are not able to provide.

I think we can find a way to reconcile those concerns; I can see the argument from all sides here, but above all else, I feel strongly that it is not the role of the theme developer to dictate in what way the theme should be used (again for all the valid reasons already mentioned), I think to do so would be incompatible with how we architect Drupal (Drupal is a framework that is not opinionated about how a site should function).

One of the ways we might be able to reconcile this is to provide the option for a theme to recommend how it should be used. For example, Olivero could indicate that it is meant to be used as a front-end theme (a key in the info.yml file probably). That recommendation would be communicated on the Appearance page, but if someone really wanted to, they would still have the option to set Olivero as the admin theme; They might be given a warning when doing so, something like "Olivero was not designed to be an admin theme, Olivero may not function well and support may be limited, proceed at your own risk.". Further to this, on the theme project page, we could provide an option for theme developers to recommend how their theme is meant to be used: as an admin theme, front-end theme, or both.

I think that would be a nice compromise: we effectively guide new users, we don't take the choice away, and we mitigate the likelihood of theme developers need to deal with issues/support that they didn't intend on (we give them something that they can easily point to).

rkoller’s picture

I've added #2860419 as the parent issue. We agreed in that issue in comment #26 to add #3249371, one of the closed duplicates to this issue, as one of its child issues to break down the initial idea into smaller actionable steps.

AaronMcHale’s picture

From the relevant Slack discussion:

I'd suggest we close #550102: Allow a theme to set itself as an admin or frontend theme exclusively: Allow a theme to set itself as an admin or frontend theme exclusively because a lot of the discussion and screenshots are relevant to older Drupal versions, and I believe the reasoning/discussion has moved on, e.g. headless Drupal is now a big consideration here, which wasn't part of the considerations in earlier major versions.

Let's keep this issue as a record of the previous discussion and state from years ago, and direct our efforts on #3103375: Let themes indicate whether they work as front-end and/or admin themes.

AaronMcHale’s picture

Status: Needs work » Closed (outdated)