Solo gathers thirteen of its regions into four containers — top, main, bottom and footer — counts how many regions in each container have something in them, and uses that count to decide which column-ratio setting applies, which a single content type can then override.
That sentence contains the whole feature, and each clause in it is where somebody gets stuck. The counting is the part nobody expects, and it explains almost every "I chose a ratio and nothing changed" message I get. Here is the mechanism as it exists in the theme's own code, then the three rules that decide whether your override actually fires.
The four containers and what is in them
| Container | Regions it gathers | Ratio selectors | Per-content-type override |
|---|---|---|---|
| Top | Top first, second, third | Two-column, three-column | Yes |
| Main | Left sidebar, content, right sidebar | Two-column, three-column | Yes |
| Bottom | Bottom first, second, third, fourth | Two-, three- and four-column | Yes |
| Footer | Footer first, second, third | Two-column, three-column | Yes |
Four containers, thirteen regions. Every other region the theme declares stands on its own and has no ratio to set, because it occupies its whole row.
The bottom container is the only one with a four-column selector, for the obvious reason that it is the only group with four regions in it. Its options are equal quarters, 16.6/33.3/33.3/16.6, 33.3/16.6/16.6/33.3, and 16.6/33.3/16.6/33.3. The two-column selector offers seven ratios — 50/50, 67/33, 75/25, 80/20 and the three mirrored versions — and the three-column selector offers 33.3/33.3/33.3, 25/50/25 and 20/60/20.
The counting, and why it is the part that confuses people
There are two counts in this feature, at two different layers, and knowing which is which saves an afternoon.
On the settings form, a helper loads the block entities assigned to each region of the active theme and counts a region as occupied only when it holds at least one enabled block. A region stuffed with disabled blocks counts as zero. Those totals are stored on the theme's settings and decide which settings groups the form renders at all.
At render time, the page preprocess does something subtly different: it asks whether each region has actual content in the page render array for this request. Then it assigns the layout class — one occupied region gets a single-column class, two get the group's two-column setting, three get the three-column setting, four get the four-column setting.
The consequence is that the live setting is decided by the page, not by your intent. If your footer has three regions but only two of them render on a given page, the three-column ratio you configured is not the one in force there — the two-column one is. This is the most common cause of "my layout setting is being ignored".
The main container has one extra behaviour worth knowing. When exactly two of its three regions are occupied and you have never saved a two-column value, the theme picks a sensible default based on which sidebar is missing — wider content on the side where the sidebar is absent. Save a value yourself and your value wins; the smart default only fills a vacuum.
Switching on per-content-type layouts
Each container's Layout Settings tab carries its own checkbox — there is no global one. Tick it and a collapsible group appears for every content type on the site, each with its own two-column and three-column selectors, and on the bottom container a four-column one as well. The groups are revealed by the checkbox state, so they are hidden until the feature is on.
The values are stored against the container, the column count and the content type's machine name. That storage shape matters in two situations, and both are quiet failures rather than errors: if you copy the theme settings to a site whose content types are named differently, the overrides import and then do nothing; and if you are upgrading from an older Solo, the keys used to be flat and a post-update hook moves them into this nested shape, so run your database updates before you go looking for settings that appear to have vanished.
The three rules that decide whether your override fires
- It is per container. Enabling per-content-type layouts on the main container does nothing for the footer. Four containers, four checkboxes.
- It is per column count. An override you saved in the three-column selector is consulted only on pages where three regions of that container are occupied. Save the two-column value as well if two is what your pages actually render.
- It needs a node in context. The preprocess takes the node from the route and reads its bundle; with no node there is no bundle, so a View page, a taxonomy term page, the front page and the search results all fall back to the global ratio. This is not configurable, and it is the rule people discover last.
Rule three is the one to design around. If the pages you most want to look different are Views listings, per-content-type layouts are the wrong tool and you want block visibility conditions or a different region layout instead.
A worked example
Say articles should read as content plus a right sidebar at 80/20, and landing pages should be one wide column. Place a block into the content region and one into the right sidebar; that makes the main container two-occupied, so the two-column selector is live. Set the global two-column ratio to 80/20. Then tick per-content-type layouts on the main container and leave the article override at 80/20 or blank.
For landing pages there is no one-column override to find: a single occupied region already renders full width, so you get it by having no sidebar block visible — a block visibility condition, not a layout setting. Ratios come from settings; occupancy comes from block placement.
If you would rather have the block layout and the container ratios designed together and handed over documented, that is ordinary Drupal development work and is usually a short engagement rather than a project.
Where this sits next to the alternatives
It replaces a second theme, or a Layout Builder rollout, when the only thing differing between your content types is column proportion — and does not, when the difference is which components appear, in what order, or when an editor needs to compose the page.
It is also worth knowing what its neighbours do. Content width per content type and per node is a separate feature that needs the companion module; the same per-content-type idea applied to the editing screen rather than the public page is per-content-type node edit form templates; and because all of this is theme settings, it is configuration that has to be exported and deployed like any other, which is covered in how Solo's settings survive a deploy.
Common questions
I picked a ratio and the page did not change. Why?
Almost always the occupancy count. Count how many regions in that container actually render on the page you are looking at, and check you set the selector matching that number. Two occupied regions never read the three-column setting.
Does this work on the front page or a Views listing?
The global ratios do. The per-content-type overrides do not, because those pages have no node in the route and therefore no bundle to match against.
Can one node have its own layout?
Not a layout, no. Per-node granularity exists for content width only, and only with the companion module installed.
Do I need a sub-theme for this?
No. It is entirely settings, and no template override is involved. You do need to treat it as configuration and export it, because it will not travel any other way.
Next steps
Before configuring anything, count the occupied regions in each container on the page you care about, and set only the selectors matching those numbers. Add per-content-type overrides only where a type genuinely needs a different proportion — every override is one more thing the next person has to find.
If a site has already grown a set of layout settings nobody can explain, an audit of the block layout and the container ratios together is a short piece of work and usually ends with fewer settings rather than more. Drupal services covers how that is scoped.
