Solo Copy Blocks copies every block placement and its configuration from your site's current default theme into the Solo theme in one click, remapping region names that don't match between the two. It declares core_version_requirement: ^10.1 || ^11 || ^12 and has no dependency beyond Drupal core itself.
What the module actually does — read from the code, not the marketing copy
The project description on drupal.org frames this as built exclusively for migrating off the W3CSS theme. The source tells a slightly different, more useful story: the single function that does the work, _solo_copy_blocks_and_config_to_solo_theme(), takes whatever theme is currently your site's default theme as the source and always copies to solo as the target — it never checks that the source is W3CSS specifically. It works from any default theme. The region-remapping rules just happen to be named for W3CSS and Solo's own region conventions, which is why it fits that migration best.
Requirements
| Requirement | Value |
|---|---|
| Drupal core | ^10.1 || ^11 || ^12 |
| Other modules | None |
| Permission needed | administer themes — a Drupal core permission, not one this module defines |
Before you run it — the order of operations matters
Because the source theme is always whichever theme is currently default, the sequence you install things in decides whether the module does anything useful:
- Leave your existing theme as the default. Do not switch to Solo yet.
- Install the Solo theme, but choose Install, not Install and set as default.
- Run Solo Copy Blocks. It reads your still-current theme as the source and Solo as the target.
- Only after the copy has run, switch Solo to be the default theme.
If Solo is already the default theme when you run the form, the source and target are the same theme, and the module has nothing meaningful to copy.
The region mapping
Blocks are sorted by weight before they move, so relative ordering survives the copy. Most regions map straight across by name when both themes declare one with that name; the exceptions are handled explicitly:
| Block is in this region | Moves to | Condition |
|---|---|---|
fixed_search_bar | fixed_search_block | If the target theme declares that region |
bottom_forth | bottom_fourth | If the target theme declares that region |
auto_hidden_blocks | Your chosen default region | Always, and the block is set disabled |
Block ID starting with <theme>_messages | system_messages | Matched by block ID prefix |
Block ID starting with <theme>_help | content | Matched by block ID prefix |
| Anything else | Same region name, if it exists in Solo | Otherwise falls back to the default region |
A block whose target ID already exists in Solo is skipped, not overwritten — the module logs a warning and leaves the existing block alone, so re-running the form is safe rather than destructive. The form itself hard-codes the fallback region to footer_menu.
Drupal 12 region handling
Core changed how a theme's full region list is fetched: Drupal 11.4 and later expose it through ThemeHandler::getTheme()->listAllRegions(), where earlier versions used the procedural system_region_list(). The module checks the running core version and calls whichever one actually exists, rather than assuming one API across every supported core — the kind of detail that silently breaks a module supporting ^10.1 || ^11 || ^12 in one line if it is skipped.
Running it
Install with Composer, then visit the form:
composer require drupal/solo_copy_blocks
drush en solo_copy_blocks -yNavigate to Configuration → System → Copy Blocks to Solo Theme, or go directly to /admin/config/system/solo-copy-blocks, and click Copy Blocks. The form has no other settings — everything about the migration is determined by the code path described above. It reports a plain count when it finishes: how many blocks were migrated, or a message that nothing needed migration if the source theme had none placed.
Afterward, check the actual block layout for Solo — /admin/structure/block?theme=solo — before switching it to the default theme. Confirm the regions look right and that nothing landed in the fallback footer_menu region that should have kept its original placement; the log messages the module writes — visible at /admin/reports/dblog if the core Database Logging module is enabled — name every block it skipped because a matching ID already existed in Solo, which is the one case worth a manual look.
Common questions
Does it delete my old theme's blocks?
No. It reads from the source theme without modifying it. What it does delete, first, is every existing block already placed in the Solo theme, so the copy starts clean rather than layering on top of leftover Solo blocks from an earlier run.
Can I choose a different target theme?
Not through the form. The target is hard-coded to solo in the function itself, which matches the module's stated purpose but means it cannot be repointed at a sub-theme without editing the code.
Will this work migrating from a theme that isn't W3CSS?
Functionally, yes — the code only checks that both the source and target themes exist and are installed. The special-cased regions (search bar, bottom fourth, help/messages blocks) are named for W3CSS and Solo's own conventions, so a non-W3CSS source theme will fall back to same-name-or-default mapping for everything, which still works, just with less precision.
What if I run it twice by accident?
Nothing breaks. Blocks that already exist under their computed target ID are skipped with a logged warning rather than duplicated or overwritten.
Moving a real site onto Solo?
Solo Copy Blocks is free, and it solves exactly the one problem in its name. If the rest of a theme migration — sub-theming, region layout, a full Drupal 11 or 12 upgrade around it — needs a hand, that is what I do for a living.
Look at the Solo theme itself, read about my Drupal services, or get in touch to talk about the migration.
