Solo's flexibility runs into four boundaries that neither a setting nor a sub-theme will move: the region list is fixed markup, the CSS framework is bundled with the theme, there is no component layer, and every value is scoped to a theme rather than to a page.
This page used to carry seven reasons Solo is the most flexible free theme for Drupal. I wrote those reasons, and re-reading them against the files two of the numbers were wrong and one of the claims described something the theme does not do. So here are the same seven, re-counted from the theme on disk, each one paired with the edge it runs into — which is more useful to someone choosing a theme than a list of superlatives.
The seven claims, re-counted from the source
| Claim as published | What the files say | Where it stops |
|---|---|---|
| 24 regions | solo.info.yml declares 25 region keys: 24 placeable plus hidden | The list is fixed in the info file and in the page partials |
| 15 colour fields per region | Unchanged | Colour is per region, never per node or per path on its own |
| Layouts site-wide, per content type, or per page | Overrides are stored per content type; there is no per-page layout setting | Per-page composition is a different tool entirely |
| Mega menu, three levels | 15 mega-menu arrangements in the layout helper; the README describes a three-level main menu | The mega menu belongs to the primary menu |
| Five responsive breakpoints | Two different lists share that word — see below | The one you can select is not the one responsive images use |
| Region-specific customisation | Stands | Applies to declared regions only |
| 50 predefined colour schemes | 50 files in css/predefined/, counted | Switching is deliberate, never automatic |
The breakpoint row deserves its own sentence because it trips up anyone comparing the theme to its documentation. The settings form offers five site values and five menu values — 576, 768, 992, 1200 and 1400 pixels — and those become CSS classes on the page wrapper. Separately, solo.breakpoints.yml declares six entries with a different set of widths, starting at 414 pixels, and that file exists for Drupal's breakpoint system and responsive image styles. They are not copies of each other, and quoting one when you meant the other is how a front-end conversation goes sideways.
The layout row is a correction rather than a nuance. The override is keyed by content type, and the theme reads it only when a node is in context. I have written up how that resolution actually works in grouped regions and per-content-type column layouts.
Boundary one: the region list is markup, not a list
Adding a region to a Drupal theme is two jobs, and only the first one is obvious. You declare it in the .info.yml, and then something has to render it. Solo's page.html.twig does not loop over regions; it includes a sequence of named partials, and each partial names the regions it prints. The starter sub-theme ships with the identical 25-region list precisely so that the parent's partials keep working.
So a sub-theme can declare a twenty-sixth region and place a block into it, and nothing will appear until you also own a copy of the partial that should print it. That is not a defect — it is the cost of a template structure that can be styled per region — but it means "just add a region" is a template job, not a configuration job.
Boundary two: the framework is bundled
Solo carries W3.CSS version 4.13 as a declared library in solo.libraries.yml, under an MIT licence marked GPL-compatible, alongside a set of colour libraries. Loading it is optional — there is a setting for that — but the theme's own layout classes are its own, and the grid you get from the column selectors is Solo's, not a framework you chose.
The consequence for a front-end team: you can add your own stylesheet, and you cannot swap the underlying framework and keep the settings layer. If your organisation has standardised on a CSS toolchain, that decision and this theme are in tension.
Boundary three: there is no component layer
Solo has no components directory and ships no single-directory components. It is regions, templates and settings. There is also no layout plugin: the .info.yml declares no layouts key and there is no layouts directory, so the theme does not supply layouts to Drupal's layout system. There is a stylesheet whose filename mentions Layout Builder, but a stylesheet is styling, not an integration.
If the brief you have been handed names components, or hands you a pattern library to implement exactly, you are being asked for a component architecture and a settings form is the wrong shape of tool. That is a generated starter theme and a front-end build, which is ordinary Drupal theming work and is much cheaper to scope at the start than to discover at sign-off.
Boundary four: settings are scoped to a theme
Everything on the settings form is one value for the whole site, with two carefully limited exceptions: column ratios can vary per content type, and content width can vary per content type or per node once the companion module is installed. Anything else that must change with what is being rendered — a palette for one section, a header for logged-in users — needs a rule engine or code. Solo Utilities is the rule engine, and it is deliberately narrow.
Two things people ask for that Solo will not do
- Automatic dark mode. The string
prefers-color-schemeappears nowhere in the theme's CSS. Schemes are chosen, not detected, and a site that must follow the operating system setting needs its own stylesheet. - Free-form page composition. Regions are fixed positions in a fixed order. An overlapping hero, an element pinned across two region groups, or an editor dragging blocks around a canvas are all outside what the region system expresses.
Four questions to ask of a design before you commit to this theme
- Does any element in the design cross two region groups — a panel that starts in the top container and finishes inside the main one? If yes, that element is CSS you write.
- Does anything need to differ per node rather than per content type? If yes, budget for the companion module or for code.
- Does the brief name components, tokens or a pattern library? If yes, this is a component build.
- Does the design assume the operating system's dark mode? If yes, that is yours to implement.
Four questions, half an hour, and you know whether the theme fits before anybody has installed anything. If you would rather have that judgement made against a real design, send it over and request a quote — a front-end scope written before the build is far cheaper than one rewritten during it.
Common questions
Does building a sub-theme move any of these boundaries?
One and a half of them. You can add and override CSS freely, and you can add a region if you are also willing to own the partial that renders it. The component layer is not something a sub-theme introduces, and the settings remain theme-scoped.
What is the hidden region for?
Parking. It is declared in the info file but the page template never includes it, so a block placed there keeps its configuration and renders nowhere. It is useful for staging a block you are not ready to show; it is not a way to reach a layout the region system does not offer.
Is any of this an argument against using Solo?
No. It is the trade being stated out loud. A theme with a large settings surface buys site builders real control and costs developers a large surface to reason about. Choose it because the specific settings match what you need, and if your own CSS starts fighting the theme, the sub-theme CSS diagnostic order will save you the afternoon most people lose there.
What to do with this
Run the four questions against your design and count the answers that say "CSS you write". None or one, and this is a configuration project. Three or four, and you are commissioning a front-end build on a configurable base — a good plan, provided it is the plan from the start.
