Problem/Motivation
Now that Claro has been added to Drupal core in #3079738: Add Claro administration theme to core, we can make it the default admin theme in the Umami demo profile.
Proposed resolution
I think that the only changes needed will be in the directory core/profiles/demo_umami/config/install/. There seem to be nine files in this directory that include "seven": check with grep -il seven *.yml. There are eight files block.block.seven_*.yml and system.theme.yml.
You also need to update demo_umami.info.yml which is in the root of the demo_umami directory, and replace "seven" with "claro" in the themes key.
You can try editing and renaming these files, replacing "seven" with "claro". Then import the configuration, or re-install Drupal with the modified Umami profile. It might be safer, and perhaps easier, to
- Install Drupal with the Umami demo profile.
- Export the configuration. Stage and perhaps commit the changes to git.
- Enable Claro and set it as the admin theme.
- Export the configuration. See what has changed.
- Copy any new and changed files to
core/profiles/demo_umami/config/install/. - Remove the UUID and
_core.default_config_hashlines from the new and changed files.
Remaining tasks
User interface changes
When using the Umami demo profile, admin users will see the Claro theme instead of Seven:

API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | afterPatch2.png | 48.83 KB | Ruchi Joshi |
| #25 | afterPatch.png | 242.14 KB | Ruchi Joshi |
| #17 | ootb-claro-default-admin-theme-3087701-17.patch | 7.03 KB | shaal |
| #11 | umami-with-claro-admin-theme.png | 307 KB | shaal |
| #9 | interdiff-3-9.txt | 1.34 KB | markdorison |
Comments
Comment #2
benjifisherComment #3
markdorisonI took a first pass at this but am getting an error during site configuration.
Comment #4
johnwebdev commented#3
You also need to update demo_umami.info.yml and replace
seven with claro.
And then you need to update: system.theme.yml.
Comment #5
benjifisher@markdorison, what did you do that led to those errors? Did you try editing the YAML files directly or did you follow the steps 1-5 in the issue description?
@johndevman, can you update the issue description to mention the .info.yml file?
Comment #6
johnwebdev commentedComment #7
johnwebdev commentedComment #8
shaalThank you for doing this work. Please let me know if I can help you with it. I would use the instructions @benjifisher, and add step 6, to delete the 3 lines that are coming from config-export, but are not needed in the install process (UUID).
One thing to note, according to OOTB Umami's current "rules", Claro will not be enabled by default until Claro becomes stable in core, but it will be great to have a patch for whenever it's ready.
Comment #9
markdorison@johndevman Thanks for the additional tips.
New patch installs Unami with Claro as expected in my testing.
Comment #10
benjifisherThanks to everyone for jumping on this! And thanks to @shaal for pointing out that we will have to wait for Claro to be stable before this issue is committed. I will add Step 6 to the issue description, as suggested in #8.
Looking at the patch, I see one thing that look suspicious.
I guess that file gets added when you export configuration. I think we do not want it as part of this issue, unless something breaks when we remove it.
Comment #11
shaal@benjifisher if we won't add that
claro.settings.ymlI am afraid Drupal CI tests will fail, because it seems to be comparing Umami's install configuration with the exported config of Umami installation.Patch #9 works great!
RTBC :)
Comment #12
shaalAs I mentioned earlier, unfortunately, this patch will have to wait as "Postponed", until Claro becomes stable in core.
Thank you for the great work!!
Comment #13
benjifisher@shaal, +1 for the RTBC/Postponed status.
Do you know which test fails? That file has nothing to do with Seven vs. Claro as the admin theme, so I do not know why the test would pass without this issue and fail after applying the patch (if we remove that file).
Thanks for the screenshot. I will add it to the issue summary.
Comment #14
mradcliffeRemoves the novice tag until unpostponed.
Comment #15
webchickA thought (which, credit to @lauriii on the thought). WHAT IF we were to make this the one and only UI change between Drupal 8.9 and Drupal 9.0?
Pros:
Cons:
Thoughts? :)
Comment #16
xjmFrom a maintenance perspective, I'm not sure if diverging 8.9 and 9.0 in this way is a good idea. I think what we actually want is a visual change between 8.8 and 9.0, and 8.9 is a maintenance implementation detail.
That said, I do think using Claro in 9.0 (and 8.9) is worth considering, since there's no data upgrade paths or APIs to worry about. Claro (like all user-facing core themes) is internal even once it's stable.
Comment #17
shaalI rerolled patch #9
(no interdiff)
Comment #18
webchickBumping this up to needs review since there is something to review.
Comment #19
effulgentsia commentedI think a good next step here would be to review the list of unfinished items from #3066007: Roadmap to stabilize Claro and decide which of those we would want to have done before making it Umami's admin theme. For example:
However, I like the idea that we don't necessarily need all of #3066007: Roadmap to stabilize Claro completed before making it Umami's admin theme.
Comment #20
webchickWell, I think one of the very first steps before that might be to convince the Umami maintainers that this is a good idea to do in the first place. :)
Traditionally, the stance has been "stable features only" because we don't want to create a semblance of false advertising/"smoke and mirrors" with our demo. ("Look at all this WONDERFUL stuff... which you CAN'T actually use yet in the real world! MWAHAHAHAHA!")
For an experimental module, there are also possible upgrade path implications, significant workflow changes between what's possible and not possible with production-level software (e.g. imagefields vs. media + media library, boring blocks vs. layout builder), and so on. All good reasons to take the stance "not until stable" for modules.
For a theme, however, it's visual changes on top of existing functionality only. There's no upgrade path, no external-facing API. The risk therefore seems much lower. IMO it's worth at least talking about whether or not to treat those two things differently...
Comment #21
xjmThis is still a possibility for 9.0 given Umami's "ever-experimental" status under policy, but I do see the case for postponing it until Claro is stable.
Comment #22
markconroy commentedFrom a visual point of view, having gone through the Umami website using Claro as the admin theme, it looks stable enough to me that we could add it to Umami. I like @webchick's point:
However, there are a number of a11y issues that need to be fixed for Claro to become stable and I'm quite nervous about the idea that we might have a theme set in our profile that is less accessible than what we currently have (albeit only temporarily while those issues get fixed).
Because of this, I think we should also ask the a11y team if they think Claro is "good enough" for Umami or if we need to wait until some more of the a11y issues are fixed, and not have it as an Umami maintainers-only issue.
Comment #23
benjifisher@markconroy:
Have you brought this up with the a11y team (e.g., by mentioning it on the #accessibility channel)?
I am adding the issue tag in the hope of getting some attention.
Comment #24
markconroy commentedThanks for adding that tag @benjifisher
It'd be nice to see this issue moving along towards getting committed.
Comment #25
Ruchi Joshi commented@benjifisher- Tested for Drupal 9.1 with patch#17. Claro is enabled as default admin theme. This can be moved to "Reviewed & Tested by Community".
Comment #26
markconroy commentedHi @Ruchi Joshi
Thanks for testing this. However, this cannot be marked as RTBC unless the accessibility team are happy to sign off while there are still some open accessibility issues.
See comment #22 for details.
Comment #27
webchickAre we certain that Claro as it currently stands, accessibility issues and all, is actually less accessible than Seven? I have my doubts. The Claro team has done a tremendous job from what I've seen ensuring things like focus styles, colour contrast, etc. are cared for.
Comment #28
effulgentsia commented@DyanneNova has been recently reviewing Claro's accessibility and I think has encountered some accessibility issues in Claro that are worse than in Seven. Assigning this to her to get that list posted here.
Comment #29
dyannenovaI did find cases where Seven is more accessible than Claro in Windows High Contrast mode. There are child issues for all of the discovered High Contrast issues here: #3080100: Assess accessibility of Claro in High Contrast AKA forced colors mode
Comment #30
markconroy commentedHi @DyanneNova
Thanks for the comment. Based on it, do you have an opinion on whether we could/should start using Claro as our base theme? Are the issues where Seven is more accessible than Claro only affecting users in Windows High Contrast mode, or are the other issues where we think Seven is outdoing Claro to such a degree that it would not be beneficial to add Claro as our admin theme for Umami just yet?
Thanks again.
Comment #32
markconroy commentedFrom looking at the remaining issues in Claro, which seem relatively small, I think at this stage I'd support enabling Claro as the admin theme for Umami. I certainly don't think the experience of using Claro's would be any less enjoyable than the experience of using Seven.
Anyone got any strong opinion for or against this idea?
Comment #33
benjifisherIn #29, @DyanneNovareferenced the meta issue #3080100: Assess accessibility of Claro in High Contrast AKA forced colors mode. I just checked, and that issue has 6 children: is is fixed, and the others are NR. A couple have been waiting for review since October.
Personally, I would like to see this issue go in, but I do not think we should do it until the a11y are addressed. I am not sure I am qualified to review those child issues. Maybe you can help with that, @markconroy.
I am adding the meta issue as related to this one.
Comment #34
shaalMy 2 cents - Claro includes SO many improvements over Seven.
It might have a few edge cases that need to be fixed, but AFAIK there are only a few issues like that.
Comment #35
markconroy commentedDoes Seven do _anything_ for Windows High Contrast mode? If not, and Claro does (even if not perfect yet), then I'd see that as another push for Claro.
I agree with @shaal - it's a huge improvement on Seven and what we currently have, and the issues it still has are much more edge cases than "OMG this site is unusable" cases.
Comment #36
markconroy commentedI"m going to mark this as RTBC. I think Claro is a great theme, much better than what we have with Seven, and the small few outstanding issues are less concerning the the outstanding issues of Seven.
That and the fact that the OOTB maintainers all seem to agree we would like Claro enabled, and there doesn't seem to be much disagreement from the a11y team.
Comment #37
effulgentsia commentedI'm not an accessibility expert, but just by reading what's in the issue summaries of the child issues of #3080100: Assess accessibility of Claro in High Contrast AKA forced colors mode, I think #3171726: Claro Shortcuts star fails WCAG Use of Color and Non-text contrast is an actual accessibility regression as compared to Seven, and #3194669: Misuse of explicit colour for active pager item in -ms-high-contrast media query might be too, though I'm less confident about that. The other child issues of #3080100: Assess accessibility of Claro in High Contrast AKA forced colors mode just say "needs improvement" in their title, so either aren't regressions relative to Seven or just have meek issue titles.
I'm not necessarily recommending that we hold up an Umami improvement on 1 or 2 or 6 regressions for people using High Contrast, especially when Claro improves on accessibility relative to Seven in other areas, so leaving this RTBC.
Comment #38
catchSeems like webchick was broadly in favour of this before, but tagging for product review too.
Comment #39
markconroy commentedThanks @effulgentsia. The only issue there that looks like an actual regression is the shortcut star not having as high a contrast ratio as we currently have (though it's very close). I'd hate to hold this up on something so small, given all the other benefits Claro brings.
Comment #40
webchickFrom a Product Management POV, this is a slam dunk. It improves the admin theme far beyond the current status quo, it gets the theme out in front of more people which hopefully leads to more steam behind closing the remaining issues (and/or finding ones we missed), but it does so in a way that does not impact the default Drupal experience or any existing sites. With only one a11y regression compared to Seven, it feels like this would be a net improvement in accessibility, vs. a detraction.
However, I'm not an expert in these matters. So I pinged in #accessibility to ask some folks to chime in here. https://drupal.slack.com/archives/C2ANFUGGG/p1621009480123300
Comment #41
lauriiiMoving to needs review since this needs input from the accessibility maintainers.
Comment #43
benjifisherNow that #3277053: Mark Claro as Stable has landed, there is no reason to put off this issue. RTBC
I just installed 9.4.x with the patch from #17, and it works as expected. I exported configuration and compared to the original, and the only changes were core hashes and UUIDs.
The testbot will do a more thorough job.
Comment #44
ckrinaRemoving the Needs Accessibility tag because Claro is stable now.
Comment #47
ckrinaCommitted 759f9c5 and pushed to 10.0.x and 9.4.x. Thanks everybody! 🎉
Comment #48
gábor hojtsyComment #49
xjm