Every setting on Solo's theme settings form is Drupal configuration, held in one config object named solo.settings — so it exports to YAML, imports on the next environment, and is deleted outright the moment the theme is uninstalled.
I maintain Solo, and the message I answer most often is some version of "the design came back different after we deployed". Almost none of those are theme defects. They are consequences of where theme settings are stored and what Drupal does to that store during an install, an export and an uninstall. What follows was read from Drupal 11.4.6 core and from the theme's own files, not from memory.
Which object the settings are written to
Core resolves a theme setting through ThemeSettingsProvider::getSetting(), which reads the config object named <theme>.settings and caches the result in memory under a config:<theme>.settings tag, so the in-request copy is invalidated when those settings change. Bubbling that tag into your own render array is still yours to do — the provider does not do it for you. For Solo that object is solo.settings. For a sub-theme created from the shipped starter it is solo_subtheme.settings — a different object holding a different set of values.
The defaults are a file you can open: config/install/solo.settings.yml in the theme. Drupal copies it into the active configuration when the theme is installed, and every change you make afterwards is an edit to that object. Nothing about this is special to Solo; it is how core treats any theme's settings, and the older accessor theme_get_setting() now simply forwards to the same provider, and core has deprecated it in 11.3 for removal in 13.
What an export carries, and what it quietly leaves behind
This table is the one I send people before their first deploy. The second row accounts for most "the logo vanished" reports I receive.
| The thing | Where it is stored | Moves with a config export? |
|---|---|---|
| Colours, widths, column ratios, toggles | solo.settings | Yes |
| The logo and favicon images | Your files directory. Config stores only logo.path | No — the path travels, the image does not |
| Which block sits in which region | Separate block.block.* config entities | Yes, as their own YAML files |
| The text inside a content block | A content entity in the database | No |
| A per-node width from Solo Utilities | A node_width content entity | No |
| A sub-theme's settings | solo_subtheme.settings, a separate object | Yes, as a separate file |
Two rows there are worth acting on. Upload the logo through the theme settings form and core saves the file into your public files directory and records a path; deploy the YAML to a server whose files directory does not contain that file and you get a broken image with a perfectly correct configuration. And because block placements are their own config entities, a colour you set on the footer can arrive intact on a server where no block has been placed into the footer at all — in which case Solo has nothing to paint.
The drift nobody made: opening the settings page writes configuration
This one surprises people, so I would rather say it plainly than have it found in a diff. Solo's settings form needs to know how many regions in each group currently hold an enabled block, so it can decide which settings groups to render. The helper that works this out, _count_regions(), does not just count — it writes the result back, setting count_top, count_main, count_bottom and count_footer on solo.settings and saving the object.
The practical consequence: visiting Appearance → Settings → Solo on any environment can change that environment's active configuration, without you touching a field. Your next export then shows a diff nobody deliberately made. It is harmless in itself, but it belongs in its own commit rather than inside an unrelated pull request.
Uninstalling the theme deletes the settings, and it is core that does it
When a theme is uninstalled, ThemeInstaller::uninstall() hands off to ConfigManager::uninstall('theme', $key). That method lists every config object whose name begins with the extension name followed by a dot and deletes each one, across every configuration collection — so uninstalling Solo removes solo.settings and anything else prefixed solo., including translated copies. There is no confirmation step that spells this out and no undo.
The guard most people rely on without knowing it is in the same method: core refuses to uninstall the theme that is currently set as default, and refuses to uninstall the current administration theme, throwing rather than proceeding. So the accident normally happens on the way out of a theme, not while it is in use — you switch the default to something else, tidy up the extension list, and the settings go with the tidy-up.
Recovery is only as good as your last export. With the YAML in version control, reinstalling the theme and importing gives you everything back. Without it, there is nothing to restore from except a database backup.
Why the theme ships 3,196 lines of schema
Configuration schema is what makes a config object typed, translatable and validatable rather than an untyped bag of values. Solo's lives in config/schema/solo.schema.yml and is 3,196 lines long, which is a direct consequence of having a settings form this large.
Three of its keys are deliberately declared type: ignore: site_widths, solo_layouts and menu_template_assignments. Their child keys are your content type machine names, which cannot be known in advance, so the schema declines to describe them rather than pretending to. That has a consequence when you move settings between sites: those overrides are keyed by bundle, so if the target site's content types are named differently, the values import successfully and then do nothing. The per-content-type layout overrides are the place this bites most often.
The settings shape can also change between releases: Solo ships a post-update hook that rewrites older flat keys into the structure the current schema expects, for Solo and every sub-theme beneath it. That is the theme-specific reason for the usual deployment order, whose general case is covered in Drupal configuration management — database updates first, so the hook reshapes your active settings before an import is compared against them.
Four habits that keep a themed site deployable
- Configure locally, export, commit, import, and run database updates before that import after any theme update. A colour changed on production survives exactly until the next one.
- Export after a block layout change, not just after a settings change. Block placements are config, and Solo's settings form depends on them.
- Commit the logo and favicon as files in the repository, and point
logo.pathat the committed copy rather than at an upload. - Decide the sub-theme question before you configure anything, because the settings object is per theme. The sequence is set out in installing and configuring Solo.
If the site is commercial and the deployment is currently somebody remembering to click things in the right order, that is the part worth fixing first — it is ordinary Drupal development work and it is measured in hours.
Common questions
Should theme settings go into a configuration split?
Usually not. A split is for values that must genuinely differ per environment, and a colour scheme is not one of them. The occasional exception is a deliberately different banner or logo on a staging site, and even then a $config override in settings.php is the lighter tool.
I changed a setting on production and it reverted. Why?
Because the next configuration import replaced the active object with the file. Nothing warns you, and the two events are usually days apart, which is what makes it confusing. Make the change locally and deploy it.
Do my settings follow me when I switch to a sub-theme?
No. solo_subtheme.settings is a different object and starts from the shipped defaults. You can copy the values across by hand in the YAML before importing, but nothing does it for you.
What is the fastest way to know my settings are actually safe?
Delete your local site's database, rebuild it from the repository and the configuration import, and see what is missing. That is the only version of this test that tells the truth.
Where to take this next
If you would rather hand the whole deployment story over — exports reviewed, updates ordered correctly, the theme settings reproducible from git — describe your current setup and I will tell you which of the four habits above you are missing.
