The Solo theme ships 50 pre-built colour schemes, and Solo Utilities lets you decide which one loads on which pages using the same condition system Drupal already uses for block visibility.
I maintain both projects, so here are the exact mechanics rather than a feature list — what is actually on disk, what conditions you really get, and where the limits are.
What the 50 schemes are
Each scheme is a standalone CSS file in the theme, under css/predefined/, named after the palette — solo-midnight-navy-duo.css, solo-ivory-whisper.css, and so on. There are exactly 50 files there; I counted them rather than repeating the marketing figure.
Because a scheme is one stylesheet rather than a set of theme settings, switching is a file swap, not a rebuild. Nothing is compiled, nothing is stored per-node, and reverting means selecting a different one.
The theme itself declares core_version_requirement: ^10.1 || ^11 || ^12 and php: ^8.1 in solo.info.yml, and base theme: false — Solo is a base theme in its own right, not a Classy or Starterkit descendant.
Choosing one for the whole site
The theme settings form has a Predefined Color Schemes section with two selects: a category, then a scheme within it. Pick one, save, done. No module required, no code.
That is enough for most sites. The rest of this page is about the case where it is not.
Different schemes on different pages
This is what Solo Utilities adds. Install it the usual way:
composer require drupal/solo_utilities
drush en solo_utilities
drush crIt then provides a configuration entity called a colour schemes rule, managed at /admin/config/solo_utilities/color-schemes-rules. A rule is a scheme plus a set of conditions plus a conjunction — AND, meaning every condition must pass, or OR, meaning any one of them.
Which conditions you actually get
This is the part worth being precise about, because the rule form does not define its own conditions. It asks Drupal's condition plugin manager for the available ones, which means you get whatever condition plugins your site has installed. On a Drupal 11.4.6 site, core supplies:
| Condition | Provided by | Matches on |
|---|---|---|
| Entity bundle | Core entity system | Content type, and other entity bundles by deriver |
| Pages | system | Path patterns, so any URL or wildcard |
| Roles | user | The current user's roles |
| Language | language | Interface or content language |
| Current theme | system | Which theme is active |
| Response status | system | HTTP status, so you can style 403 and 404 differently |
Solo Utilities special-cases one of these. For the Current theme condition it replaces the standard theme list with Solo and its sub-themes only, which stops you building a rule that can never match.
What you do not get on stock core: there is no taxonomy-term condition. If you want "all articles tagged Events get the dark scheme", either use the Pages condition against the term's path pattern, or install a contributed module that provides a term condition. Any condition plugin from contrib appears in the rule form automatically.
Things worth knowing before you build rules
- Solo Utilities does not declare the theme as a dependency. Its
solo_utilities.info.ymldepends only ondrupal:node; the Solo relationship is checked at runtime instead. So the module will install on a site that is not running Solo, and simply have nothing to act on. - Rules are configuration entities, which means they export to YAML and deploy through configuration sync like anything else. Build them locally and ship them; do not create them on production.
- The Advanced Settings tab is a placeholder. It currently says custom colour overrides and CSS variable controls are planned. Treat that as not yet available rather than as a feature.
If you are new to Solo, installing and customising it is the place to start, and what else Solo Utilities does covers the rest of the module. For a build where the theme has to do more than a settings form allows, that is Drupal theming work.
Common questions
Does switching schemes affect performance?
One scheme is one stylesheet, so the cost is one CSS file. Rules are evaluated per request like block visibility conditions; keep the number of rules sensible and it is not a factor.
Can I edit a scheme's colours?
Not through the interface today — the advanced options are a placeholder. Copy the CSS file into a sub-theme and override it there, which also survives updates to the base theme.
What happens if two rules both match?
Test it on your site before relying on a specific outcome. Rule precedence was not verified for this article, and it is the kind of thing worth confirming with two deliberately overlapping rules rather than assuming.
Do the schemes meet contrast requirements?
Check the specific scheme against your content with a contrast tool. Palettes are designed as pairs, but the text you put on them is yours and a contrast pass is quick.
Will this work on a Solo sub-theme?
Yes, and the Current theme condition is deliberately limited to Solo and its sub-themes for exactly that reason.
Next steps
Set one scheme site-wide first and live with it for a week. Per-page rules are genuinely useful for microsites, campaign landing pages and role-specific admin experiences, but they are the second step, not the first.
If you want a Drupal site built on Solo without doing the theme work yourself, Drupal services covers it, or tell me what you are trying to achieve visually and I will say whether a scheme rule does it or whether you need a sub-theme.