Merging Gin as Admin theme

I made a commit of a what I wanted to add as suggestions but GitLab is painfully slow for me so I gave up. The commit includes changes like 'dark mode' instead of 'darkmode' because it is referring to the mode, not the name of the setting. Also, in a few cases I tried to make the distinction between any admin theme and this particular admin theme. Those are user facing and should be checked carefully.

In fact, it is usually confusing what is meant by 'admin' and 'admin theme' in the comments. Is it referring to this particular theme or any administrative theme?

And, I think the doc pages should include an introductory remark for developers that Admin involved from Gin and thus many settings etc use the word 'gin'.

I get 28 words flagged by cspell. Of those 11 are in the cpp dictionary and one in the css dictionary. That is not enough to consider enabling those dictionaries, not that we would use the C++ dictionary anyway. And using the css one is for another issue. Next, is to consider renaming. I think that improves readability so I would prefer that option. However, js and css are not my area so this needs more opinions are needed. If it helps the discussion I can do the renaming work.

I followed the steps in the issue summary after logging in the admin pages result in

Twig\Error\LoaderError: Template "core/themes/admin/templates/navigation/menu--toolbar.html.twig" is not defined in "core/themes/admin/templates/html.html.twig" at line 51. in Twig\Loader\ChainLoader->getCacheKey() (line 51 of core/themes/admin/templates/html.html.twig).

I got the same as #9 but resolved it by uninstalling the Toolbar module. Then you also will want to enable Navigation.

Is it enough just to document that this is needed if you are looking to switch your site over?

Along with general testing, I tested the feature flags and all worked as expected:

1. Login form defaults to use admin theme
2. Setting this to false uses Olivero
3. No sticky actions by default
4. Setting this to content_only enables them on the node forms
5. Setting this to always enables this on all forms

Overall I am in awe of the work that has been done on this so quickly @jurgenhaas and @saschaeggi and whoever else was involved in this superhuman effort :)

There are instances of "Gin" in comments that I think should now be changed to "Admin". I was making suggestions for those but GitLab was being a bit faster. But then I discovered that it isn't showing all the files in the change. So, I am going to step away from this for now. Maybe tomorrow I will make a commit for those changes.

@quietone indeed the size of this MR makes it quite difficult to work with. I would say that updating references to Gin in comments can be done in a follow up mostly for that reason!

@pameeela, thanks! I've updated the issue summary with that.

I also added remaining tasks to help keep track of things to do

Thanks for working on this!

I got the same as #9 but resolved it by uninstalling the Toolbar module. Then you also will want to enable Navigation.
Is it enough just to document that this is needed if you are looking to switch your site over?

I think that it was discussed earlier that Gin will support Toolbar (only the one default position) until it is removed from core. So I think we should fix that error instead of forcing users to use Navigation.

@jurgenhaas, I've updated it again.

I'm wondering, should we add a component "Admin theme" to the core project?

I couldn't think of a reason not to, so I did.

Are we keeping the gin machine name in classes, config, settings keys, etc? There are a lot of references - and changing some of these once this is released will probably be more difficult.

I pushed a commit to update the PHPStan baseline, this is new from Symfony 7.4 and only temporary until #3555532: Since symfony/http-foundation 7.4: Request::get() is deprecated, use properties ->attributes, query or request directly instead. is fixed.

Regarding CSS, if I run yarn build:css I get different build output. Shouldn't any deduplication or other fixes be happening on the .pcss.css files, and the .css files should be machine generated from those? If the .pcss.css and .css differ it feels like something has gone wrong. yarn build:css must run cleanly in case we need to update any other PostCSS files.

For JS we can run yarn lint:core-js-passing --fix to solve most of the formatting problems although there are 40 or so manual fixes to do after that. In the meantime we could skip this by adding to .eslintignore as long as there is a followup to remove it again?

For CSpell ideally we should add cspell:ignore comments to files where the spelling will only appear once (eberhard, grossgasteiger, micha only appear in themes/admin/login/js/wallpaper.js for example). I think some of the others warrant further investigation - I didn't check them all but toolsextra only appears once in a class name, so does this mean it isn't used? Similar tablesaw only appears in the context of .tablesaw-cell-content which is a class name that I don't see in use.

@longwave

For JS we can run yarn lint:core-js-passing --fix to solve most of the formatting problems although there are 40 or so manual fixes to do after that. In the meantime we could skip this by adding to .eslintignore as long as there is a followup to remove it again?

I guess you're referring to the JS inside of migration. We could go either way, but the goal would be to migrate/consolidate those and we'd remove this afterwards.

Regarding CSS, if I run yarn build:css I get different build output. Shouldn't any deduplication or other fixes be happening on the .pcss.css files, and the .css files should be machine generated from those? If the .pcss.css and .css differ it feels like something has gone wrong. yarn build:css must run cleanly in case we need to update any other PostCSS files.

Similar story, where do we get a different build output? Yes, that should be the case. Maybe there was something we didn't pay attention to and it made it's way directly to the .css but that would need to be updated to be included in the .pcss file. For the stuff that is in the migration folder still needs to be migrated, for those we only kept the .css output as it was written in SCSS before (for historical reasons).

I'm not exactly sure in which issue I should comment and if I should at all.

I'm a bit concerned about the scope of this (just looking at the PHP code, this might be the biggest code addition since views got into core in a single MR?). There are thousands of lines of preprocess and other hooks. It's not realistic that this is all meaningfully reviewed. I understand that the decision was made and there isn't really an alternative for this initial merge, but still, there is a lot of very opinionated code that contains all kind of customizations and as already discussed, various workarounds for older versions and contrib and so. I added one more comment on a media alter.

I also noticed that the info.yml file hasn't been adjusted yet. I'm not sure if we support the lifecycle definition in themes, but if so, this should probably be experimental? also stuff like package, version and so on.

I saw that the user login theme negotiator issue was closed in favor of this, making this even bigger and also including changes to non-experimental extensions. Do we really need that feature in the initial merge of this?

For the JS I've ignored the migration directory via .eslintignore and fixed the issues in core/themes/admin/login/js/wallpaper.js. I've also skipped cspell on the wallpaper filenames while I was there.

@saschaeggi to see the different build output just check out this branch and run yarn build:css from the core directory - a large number of the admin .css files get updated with various changes:

$ yarn build:css
...
$ git diff --shortstat
 48 files changed, 2037 insertions(+), 1987 deletions(-)

If we are shipping both .pcss.css and .css files then the build output must be clean/unchanged before this can be committed, because otherwise the next issue to work on this will not know which is correct.

Note so far I'm only looking at this from the technical point of view to get it to pass CI, I share some of the concerns with @berdir about scope and haven't done any manual testing at all.

> The reason for handling this change here as well is that none of the two separate MRs would ever pass tests in isolation, that's why they can only come together. And the reasoning for why this is needed in the first place has been quoted from the Slack discussion with @lauriii.

What tests? Drupal CMS tests? There are no tests in this MR. I don't think this needs to satisfy Drupal CMS exceptations on day 1. Removed contrib integrations will also need to find a new home, it'll need some new dependencies for that anyway. The discussion with @laurii is on how it should be done, which I agree with, not that it needs to be done and must be included.

I also left some review comments on that part, I really think this needs more scrutiny and careful review (and tests).

The page deprecation is https://www.drupal.org/node/3458593, you need to update your node templates to not check for page.

See https://git.drupalcode.org/project/drupal/-/commit/685ad2ba89418998c5912.... You need to stop checking the page variable in your node and term twig templates and look at the view mode instead (which you copied from classy)

Not sure what the process is for changes in Claro, but #2409559: User should be able to identify required fields from field listing added new CSS to Claro for manage fields which will likely need to be copied over/adapted.

What are the next steps on this issue? It would be great to get this committed early in the release cycle.

There are a couple of other CSS commits to Claro since November, e.g.:

commit 929caa86a96916d200855ed3aa66991e0f749133
Author: Dave Long <dave@longwaveconsulting.com>
Date:   Thu Jan 22 14:12:43 2026 +0000

    task: #3565630 Existing Safari workarounds for details element seems to be no longer needed
    
    By: tom konda
    By: smustgrave
    (cherry picked from commit fb0bd735ac169cc2fa8faa3d6dba133fbe8432d5)

commit 253937064d90a0477b5b12e2f49554518ef3bbc1
Author: Dave Long <dave@longwaveconsulting.com>
Date:   Thu Jan 22 10:19:15 2026 +0000

    feat: #3521857 Update Drupal's default file type icons to use SVG
    
    By: jwilson3
    By: smustgrave
    By: mgifford
    (cherry picked from commit 794c6dee90ef848e65603a65e5f10c17236c5294)

Not sure whether these are relevant or not at this point, but in case they are.

Fixed the last failing test.

The bug was due to a line that dates back to 2012 🤯 in the test, which creates a term whose vid is 1.

1?

Vocabulary IDs haven't been serial since Ye Anciente Times. How did this test ever pass? No idea. (I was there, Gandalf. I was there on that day 3,000 years ago...)

Anyway, creating an actual vocabulary and a term assigned to it (via TaxonomyTestTrait) corrects the problem. Commit: https://git.drupalcode.org/project/drupal/-/merge_requests/13737/diffs?c...

@phenaproxima what about all of these? https://www.drupal.org/project/gin/issues/3506302

Accessibility still matters in Core.

I have no opinion on that...? I was asked by @pameeela to resolve the failing test, so I did. If more things need doing in Gin before this is ready to go, so be it.

@mgifford at least some of those issues also affect Claro, such as #3497077: dropdown buttons are broken with Javascript disabled. The split between Claro and Gin is IMO responsible for the lack of development of Claro in core as well as those accessibility issues building up in Gin over time.

The process of bringing Gin into core and unforking the themes (even though initially we'll have essentially three admin themes instead of two, we'll rapidly move towards the point of having one) should mean a lot more focus and attention goes into fixing them, the review that has happened since Gin was added to Drupal CMS has already improved things a lot.

Strongly agree with @mgifford that accessibility matters in core, and also with @catch that merging this will get more attention on those issues, in addition to reducing the duplication of effort across multiple admin themes.

Incredible effort by @jurgenhaas to get this ready and many thanks to @phenaproxima for chasing down those last tests!

Does this pass the core accessibility gate?

Experimental themes (and modules) do not have to comply with core gates or be feature complete. The purpose of alpha experimental stage is to get initial reviews and start creating plans for feature completion and stability. For more information on the experimental process, you can refer to https://www.drupal.org/about/core/policies/core-change-policies/experime....

I discovered some small things that immediately jumped out as something that we need to improve. I will be filing follow-ups for those since it's easier to handle them in separate issues. I've committed this as alpha experimental to make the development easier.

Experimental themes (and modules) do not have to comply with core gates or be feature complete. The purpose of alpha experimental stage is to get initial reviews and start creating plans for feature completion and stability.

@lauriii Thanks!

FYI: It doesn't appear in the UI as experimental, and installing it doesn't give a warning.

@kentr if that's the case, we need a followup. Should be an easy fix.

Congrats everyone!

#3576431: Mark new admin theme as experimental

It's probably a bit too late now, but I wish something this big would have had a bit more of a consensus with the community on naming.

Myself and at least a half dozen other contributors/maintainers (as seen in slack) aren't big fans of the machine name admin

To me, this is a strange decision. Even if we're moving towards a single admin theme in core, the name admin just makes it difficult and confusing to talk about.

Grepping code and finding admin theme specific things also becomes a lot harder...

I agree. And I agree with all the reasons.

The rightful name of the Admin theme should be:

Core theme

Shall we open an issue?

The general idea here is to try to centralise everything in a single admin theme across both core and contrib since duplication causes a lot of problems when trying to develop new administrative UIs. We would not prevent people from creating admin themes obviously, but we'll remove the selection in the UI and core features will work with the 'admin theme', and anything else will need to keep up etc. Just calling it 'admin' is a nod to that.

Having said that, opening an issue to change the name again seems fine - if we come up with something better that's great and should be a find and replace while it's still alpha.

No issue with changing the name either. “Core theme” strikes me as even more problematic though!

Have the accessibility and JS-degradation issues been fixed yet?

I opened #3576646: Rename Gin-based admin theme for the discussion around renaming the theme.

Congratulation!!

Maintainers were not added to all the places. Opened #3578745: Add maintainers of Admin theme to MAINTAINERS.txt.