solo_copy_blocks 1.0.4

Data-loss fix: Copy Blocks no longer deletes every Solo block when Solo is also the source theme. Covers everything since 1.0.3, the last published release.

Who must update

• Every site using Copy Blocks. Releases 1.0.0 to 1.0.3 delete all of Solo's blocks and copy none back when the source theme is Solo (measured on a test site: 61 blocks to 0).
• Sites that have already lost blocks must restore them from a backup or a configuration export; this release cannot bring them back.

Requirements

• Drupal ^10.1 || ^11 || ^12, and the Solo theme.

Fixes

• Self-copy deleted every block. The form now refuses when the source theme is the target theme, loads the source blocks before deleting anything, refuses when the source has no blocks, and deletes the target theme's blocks rather than a hard-coded solo. Messages are translatable, and the form says that Solo's blocks will be replaced.
• HTTP 500 on every page after an update, until drush cr (#3628961: https://www.drupal.org/node/3628961). The #[LegacyHook] wrappers now use \Drupal::classResolver() instead of \Drupal::service(), so a container compiled before the update no longer breaks the site.
• The Copy Blocks form declares its return types (getFormId(): string, buildForm(): array), so Drupal 12 reports no deprecation for it.

Tests and CI

• New Kernel test
  

  SelfCopyGuardTest</coe); a Unit guard for the hook wrappers.</li>
  <li>CI now also runs on Drupal 10, which the mo
  </ul>
  <h3>After updating</h3>
  <p>Run <code>drush updb

  , then drus adds no database updates.