Let themes indicate whether they work as front-end and/or admin themes

🤔 Could we still do this in Drupal 9.0?

I think that's a reasonable middle ground.

The only reason I even wrote #3 is because it's hard for me to imagine anybody is using e.g. Seven as a front-end theme or Bartik as an admin theme. But of course a single counterexample is sufficient … so it's too risky for D9, because it'd break the no-BC-break promise.

+1!

Since we do not have ACTUAL telemetry to tell us this information :sadface: here is a sad attempt at data-gathering to see how prevalent 2 themes vs. 1 theme for admin vs. front-end is: https://twitter.com/webchick/status/1266047189349892096

@lauriii's gut is that the vast majority use different themes, and I want to believe that is true, but I also have major PTSD from attempting to get Seven into core in the first place, where the number of very loud people using the same theme for both was a significant hindrance. :P

+1

+1.

Does this mean we don't have to worry about Update Manager and other admin-only UI changes in Bartik and Umami (and Olivero when it comes into core)? If so, +100. ;)

Should the title be: "Let themes indicate they can work as admin themes"?

Thanks,
-Derek

Ohh that's a good one to ask theme to opt in as admin themes. To do that we'd need to explicitly stated what should be implemented/working to opt in (views UI, dialogs, field UI, etc.)

Really like this approach.

Well! That seems pretty definitive. :) Let's do this!

Would one of the core maintainers be willing to explicitly answer this question from #11?

Does this mean we don't have to worry about Update Manager and other admin-only UI changes in Bartik and Umami (and Olivero when it comes into core)? If so, +100. ;)

In #13 @lauriii says:

The change we'd like to see is that Bartik and Umami cannot be enabled as an admin theme because AFAIK at least practically we are not supporting them being used as admin themes.

That mostly implies a "yes" answer to my previous question, but I don't want to misunderstand or misinterpret anyone. Please be explicit. If we go forward with this plan, can all admin-only UI changes in core only have to worry about Seven and Claro? If someone NW's an Update Manager issue with "can we get screenshots for Bartik?" can I link here and politely tell them to piss off? 😉

Thanks!
-Derek

It duplicates #550102: Allow a theme to set itself as an admin or frontend theme exclusively

The Twitter poll in #14 says 4.6% use the same theme, and at least 2 responses gave very valid reasons why.

@baddysonia (https://twitter.com/baddysonja/status/1266086377122398211):

Yes or when building business process management systems with Drupal. Then it is almost always the same theme for admin and frontend. Example: real estate mgt system, meeting notes system, freight mgt or something similar. We have a couple of them built with Drupal

@NaheemSays (https://twitter.com/NaheemSays/status/1266052943347843074):

The same theme - a custom one with very little css targetting specifically the admin pages. The admin pages were a good test to see if there are edge cases that need to be considered.

(Aside: that's pretty much how I've been testing the form element styles in Olivero recently.)

I've seen a site which used Seven as the sole theme. Drupal was being used as a headless CMS, so it didn't need a front-end theme. But the editors will still visit nodes to read them. When you looked at content it was very plain; laid out more or less like the node form, just without editable inputs. (They displayed all the field labels.)

The headless CMS use case could be a common one I think. IIRC the Contenta distro did something similar, but was using a single contrib admin theme. Whatever the outcome of this issue, it would be good if we didn't prevent the default core admin theme from being used as the sole theme.

Now for a really fun fact... @joachim offered to maintain the Garland theme in contrib, precisely because he still uses it as an admin theme! See #2279347: co-maintainer request. That was 6 years ago, but he's still maintaining it minimally.

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, 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).

We should not have 3 issues dealing with the same request. Let’s close this issue and use instead #550102.

Agree we need to consolidate these issues, I was actually learning towards closing #550102, an extract from a Slack thread:

I'd suggest we close #550102: 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.

This issue might be a good one to continue the discussion on, since we have some data collection (via Twitter poll).

@AaronMcHale: Feel free to do the changes now before [#550101] gets updated with new comments. Conversely, [#550101] can be kept as is and updated to take into account current version of Drupal and headless usage.

👍

We could potentially still keep #550102: Allow a theme to set itself as an admin or frontend theme exclusively open in case we'd like to have stronger separation between front-end and admin themes.

In that case, I suggest opening a META issue and list tasks that have an issue opened or not.