Solo Utilities is the companion module that turns three of the Solo theme's conditional features on: per-node content widths, colour schemes that switch by content type or URL, and full control over how block titles are rendered. None of the three exist in Solo on its own, and all three stay invisible until two separate conditions are met — which is the single most common reason a site builder installs the module and then reports that "nothing happened".
What the module actually adds
Read from the module source rather than the release notes, Solo Utilities ships three site-builder-facing capabilities:
- Custom node widths. A Custom Width select is added to every node form, backed by a small
node_widthcontent entity that stores a width class against a node ID. - Colour Schemes Rules. A configuration entity that maps one of Solo's predefined colour schemes onto a set of visibility conditions, so a page can change palette without a second theme.
- Block title visibility. A pair of selects on every block configuration form that decide whether a block title is rendered at all, and which HTML element wraps it.
The module's own solo_utilities.info.yml declares core_version_requirement: ^10 || ^11 || ^12, php: ^8.1, and exactly one dependency: drupal:node. It does not declare the Solo theme as a dependency, because Drupal modules cannot depend on themes — which is precisely why the activation gate below exists in code instead.
The activation gate, and why nothing appears
Two conditions have to hold before any of these features surface, and they are checked independently.
One: Solo has to be in the active theme hierarchy
The module reads the site's default theme out of system.theme and walks the base theme chain looking for solo. Installing Solo is not enough. Solo has to be the default theme, or the ancestor of whatever theme is default — a sub-theme, a sub-theme of a sub-theme, any depth. If your default theme is Olivero and Solo is merely installed, every Solo Utilities feature stays switched off and the module will not warn you.
Two: the matching checkbox in Solo's theme settings
Each feature has its own toggle at Appearance → Settings → Solo. Custom node widths live under Global & Misc → Layout & Dimensions; block title visibility lives under Global & Misc → Block & Visibility. Solo hides those checkboxes entirely when the module is not installed and shows an explanatory note in their place instead, so if you can see the checkbox, the module is enabled and the only remaining question is the theme hierarchy.
If you are still getting oriented in Solo's settings screen, the walkthrough in how to install and customise the Solo theme covers the layout of that form before you start hunting for individual toggles.
Precedence rules like this are where a theme starts costing more to change than it did to build. If that is where you are, Drupal theming is the shape of the work.
Per-node widths, and the precedence rule nobody documents
With the feature on, the node form gains a Custom Width select offering nine values: None, 800px / 50rem, 1024px / 64rem, 1280px / 80rem, 1440px / 90rem, 1600px / 100rem, 1920px / 120rem, 2560px / 160rem, and 100%. Choosing None falls back to the width above it.
The order of precedence, stated in Solo's own settings description, is worth committing to memory: an individual node's width beats a content type's width, which beats the site-wide global width. Nearly every "my width setting is being ignored" report resolves to a per-node value set months ago on the one node being tested. Check the node before you check the theme.
There is a short screen recording of this behaviour on dynamic content width by content type or single node if you would rather watch it than read it.
Colour Schemes Rules
This is the feature that justifies the module for content-heavy sites. A rule is a configuration entity holding a chosen colour scheme, a set of conditions, and an AND/OR conjunction. The conditions are not bespoke: the module asks Drupal's own condition plugin manager for the plugins available in its context, which is the same family of conditions you already know from a block's visibility tab — content type, user role, request path, language, and so on. Rules live at Configuration → System → Solo Utilities, they respect five separate permissions, and each one can be enabled or disabled without deleting it.
The palettes themselves belong to the theme, not the module. Solo's dynamic colour schemes covers what is in the set and how the categories are organised.
Block title visibility
The third feature replaces Drupal's single Display title checkbox with two selects: a visibility mode of Visible, Visually hidden (screen readers only) or Do not render at all, and a tag chooser offering h1 through h6 plus a non-semantic div. The tag select hides itself when the mode is set to Do not render at all, which is a small touch that saves a lot of confused support threads.
Why that matters is a longer story than it looks, and it is covered properly in why hidden block titles still affect SEO and accessibility.
Installing it
Solo Utilities is a published contributed project, so install it the way you install anything else: composer require drupal/solo_utilities, then drush en solo_utilities -y or enable it from the Extend page. Older write-ups — including the module's own README, which has not caught up — tell you to drop the folder into modules/custom. Do not do that. A Composer-managed contrib module gets update notifications and a clean upgrade path; a hand-copied one gets neither.
Common questions
Does it work with a Solo sub-theme?
Yes. The hierarchy check walks the whole base theme chain, so a sub-theme of Solo, or a sub-theme of that sub-theme, all qualify. Solo ships an empty starter sub-theme for exactly this purpose.
Will it work with a theme that is not Solo?
No, and this is deliberate rather than an oversight. Every feature is gated on finding solo in the theme hierarchy, and the block-title feature additionally depends on Solo's own block templates to render the chosen tag. Installed alongside an unrelated theme the module is inert.
What happens to my per-node widths if I uninstall the module?
The stored widths are a separate content entity, so they are the module's data, not the node's. Treat an uninstall as data loss and export or record anything you want to keep first. Verify this on a copy of your site before you do it on production — needs checking against your specific Drupal version.
Do I need it just to change colours?
No. Solo's global colour controls and its predefined schemes are part of the theme. You need the module only when you want the palette to change conditionally, or when you want per-node widths or block title control.
Where this fits
Solo Utilities is worth installing on any Solo site that has more than one kind of page. It is the difference between a theme you configure once and a theme that responds to the content it is rendering — and none of it requires a line of custom code.
If you are weighing Solo up against other options first, the evaluation checklist for free Drupal themes is the better starting point. If you already run Solo and want the conditional behaviour built and tested properly rather than discovered by trial and error, that is ordinary Drupal development work — tell me what you are building and I will tell you whether it needs the module at all.
