Part two answers the question that follows a block migration: the blocks arrived, so why does the site still not look configured?
Theme settings do not travel
Every value on a theme settings form is stored in that theme's own configuration object — solo.settings for Solo. Copying blocks copies block entities; it does not touch that object. Widths, breakpoints, colours, fonts, menu behaviour and region visibility all start at Solo's defaults and are yours to set. That is a feature rather than a nuisance, because the old theme's setting names mostly do not exist here.
The pass to make after the copy
- Set Solo as the default theme at
/admin/appearance. - Open Block layout and rescue anything that was parked in Footer Menu Container.
- Work down the Solo settings form once, top to bottom, saving as you go.
- Only then judge the look — half of what seems broken is a region that is still empty.
That last point has a mechanical cause worth knowing. Solo only renders settings for regions that actually contain a block; empty regions are hidden from the form entirely, and the message at the top of the page counts the enabled regions in each container for you. The install-and-customise walkthrough covers the same ground in writing.
Two decisions to make once
Sub-theme or not. Solo declares base theme: false — it is a standalone theme, not a sub-theme of the older W3CSS Theme. If you intend to add custom CSS, build on the bundled solo_subtheme, which declares base theme: solo, so a theme update never overwrites your work.
Solo Utilities or not. Solo Utilities is the optional companion module that unlocks per-content-type and per-node widths and rule-based colour schemes. It is not required; without it those sections of the settings form simply explain what they would do.
Solo supports ^10.1 || ^11 || ^12, so the upgrade does not force a core move. Start at the Solo theme page.
Prefer a sub-theme configured properly the first time? That is Drupal theming — or get in touch and describe the site.
