Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
There have been several requests so far to provide customizable settings to adjust the admin interface to several desires/needs.
Proposed resolution
Provide a form with several settings to customize the UI. For example:
Font Size- WON'T FIX, see comment #13- Table cell padding or general spacing
- Palette
- Accent Color
- Dark mode
- Accessibility settings
- Reduce motion
- Highcontrast mode
- etc.
So from this options proposed we should decide where they need to be defined and who should be able to change them:
- Settings defined across the site (per theme / per site)
- Settings defined per user (like dark mode / accessibility wise)
- Settings defined per component (like decreasing table padding or thumbnail size on Media library)
Remaining tasks
Decide per setting the following:
- In which form should it live?
- Who should be able to change it (editor/content author vs site-builder)
- Which settings/values
Comment | File | Size | Author |
---|---|---|---|
#5 | Screenshot 2019-07-11 at 19.45.11.png | 49.59 KB | rembrandx |
Comments
Comment #2
ckrinaComment #3
lauriiiComment #4
ckrinaThere could be 3 levels of configuration:
- Building the site (per theme / per site)
- Per user (like font size / accessibility wise)
- Per component (like decreasing table padding or thumbnail size on Media library)
Comment #5
rembrandx CreditAttribution: rembrandx at Dropsolid commentedFor the customization of font-size, I made a proof of concept in another issue
The result looks like this:
Clicking the links saves your preset in localStorage and retrieves it when refreshing the page. The little tabs are a nav-tag with a list and links.
Classes are set on the HTML-tag in order to resize font-size on that tag using percentages.
Comment #6
saschaeggiComment #7
huzookaComment #8
martijn.cuppens CreditAttribution: martijn.cuppens at iO commentedHow will this be implemented exactly? Regenerate a CSS file by doing a find and replace in the CSS files or what's the plan?
Comment #9
AaronMcHaleI suppose looking at the core color module as a starting point/precedent, since we already do theme manipulation with that module. Maybe color could become a more generic theme customisation module.
Comment #10
ckrinaExactly @AaronMcHale, thanks! The discussion about the color/palette changes is happening here: https://www.drupal.org/project/ideas/issues/3090894.
But to know what is going to be configurable in Claro's settings form each element's option and level of configuration needs to be defined before jumping into technical implementation. Feel free to suggest what you think is the best for each. My bet for the current ones listed in the issue summary would be:
Comment #11
saschaeggiFor me the following options should be user based:
* Dark mode
* Accessibility settings (e.g. High contrast mode)
But it would also make sense for better customisation options to provide some settings on both theme level and user level, e.g.:
* Accent Color
So you could set a default accent color for your project but the user would still be able to override it if he likes to.
Btw: As a proof of concept I've already integrated Accent Colors to Claro with this theme: https://www.drupal.org/project/gin
Comment #13
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedRe: #5
Font-size user-preferences aren't Claro's job (or even Drupal's). Understanding WCAG SC 1.4.4 Resize Text is emphatic that text resizing is the responsibility of the user-agent, not the web-site. Rather, our responsibility is to ensure that Claro plays well with the user-agent's text sizing features. Claro is already doing very well in this regard - see #3087225: [META] Assess Claro's conformance with WCAG Text spacing, Text resize, and Reflow..
I've never seen custom text-resize controls which provided anywhere near the level of flexibility offered by the browser's own controls. Typically they offer a very opinionated and/or limited range of sizes, and often aren't very robust in situations where the user has already applied settings of their own. In the worst examples I've seen, they actually prevented the browser's text-resize controls from having any effect. I don't think it's worth the effort to develop (and maintain) them.
There are some circumstances where a web site may need to implement their own controls, but by and large these aren't relevant for Drupal's default admin theme:
For web sites (or distributions) which warrant text resize controls, I think it's a job best left to contrib projects. A bunch of such modules already exist, covering several major Drupal core versions. These vary in their approach (and effectiveness), but most provide a block which can be placed anywhere, and try to be agnostic to themes.
@rembrandx - I appreciate that you've gone to the effort of building a proof-of-concept. I'll provide feedback on your implementation in that issue.
Comment #14
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedUpdating summary; won't-fix font size controls.
Comment #16
benjifisherWe discussed this issue at #3186531: Drupal Usability Meeting 2020-12-11.
I am making a small update to the issue summary based on #13.
My personal opinion is that the three categories mentioned in the issue summary should be three separate issues:
The simplest is (1). Decide what settings to provide, add them to the form at
/admin/appearance/settings/claro
, and figure out how to modify the theme based on the settings. Other than the decision of which settings to provide, this seems like an implementation issue, not a design issue.(2) is more complicated. One question is how permanent the options will be. We could add a form to
/user/%/edit
and store the settings in the database. Or we could add a form in a block, position it wherever it is needed, and store the results in a cookie or the session. Probably the session. We could even do both: when a user logs in, copy settings from the database to the session.Either way, we want to be careful when implementing the feature not to break caching. We do not want different markup depending on user preferences. For example, to allow dark mode, we might use JavaScript to add a CSS class to the
<body>
tag, and then modify all the CSS rules to respect that class.On second thought, since Claro is an admin theme, maybe the pages are not cached anyway. Never mind?
As we discussed at the Usability meeting, (3) has to be made more specific. What do we mean by a component? However that is answered, I think we want some way for a component to declare its settings. Then the settings form in (1) has to collect those options and present them to the site administrator. Maybe this is not so hard to implement: Claro can define a configuration schema to be used by its components, and the settings form can collect all the config items. (Or is defining configuration schemata something that only modules can do?)
Comment #20
mgiffordThis is similar to https://www.drupal.org/project/fluidui
Exposing this information as a choice in the CMS would be interesting. However, you'd kinda want it to be something that anonymous users could take advantage of too.
Another plugin is https://github.com/skipto-landmarks-headings but you haven't mentioned anything like that. It could fit into this category of user choices.
Comment #23
ckrina