Provide config sync toggle for code components (preserve production / CLI-managed)

Overview

"Code components clobbered by config sync — add sync_mode toggle"

AI helped write this issue and plan the fix.

canvas.js_component.* and the paired canvas.component.* entities whose source is js are saved from the in-browser editor in production. drush config:export and drush config:import treat the sync directory as authoritative, so any production-only code component is wiped on the next deploy. This breaks the implicit promise that code components can be authored and edited in production.

Two real workflows need to be supported. Small and medium sites still want config sync but expect production-created components to survive an import — the WordPress model. Sites that adopt Canvas CLI (packages/cli/) want config sync to ignore code components entirely so the CLI is the sole source of truth.

Related: #3573022: [upstream] Data loss: `drush config:import` deletes config (e.g. code component + component config entities) and bypasses config system data integrity checks.

Proposed resolution

1. Add a canvas.settings config object with a sync-mode toggle.

Default config in config/install/canvas.settings.yml:

code_components:
  sync_mode: preserve_production

Schema appended to config/schema/canvas.schema.yml with a Choice constraint covering preserve_production and cli.

2. Add CodeComponentSyncTransformer event subscriber.

New class Drupal\canvas\EventSubscriber\CodeComponentSyncTransformer subscribing to ConfigEvents::STORAGE_TRANSFORM_IMPORT and ConfigEvents::STORAGE_TRANSFORM_EXPORT. Mirrors the pattern in Drupal\canvas\EventSubscriber\ComponentTreeConfigEntityTransformer. No config_ignore contrib module needed — Drupal core's storage transform events are the supported mechanism.

Behaviour per mode:

• preserve_production (default): on import, iterate every canvas.js_component.* and every canvas.component.* with source === 'js' in the active config storage. For any name absent from the incoming sync storage, write the active value into the sync buffer so the importer treats it as already present and never deletes it. Entries that exist in sync still win — tracked components remain authoritative. Export is unchanged.
• cli: on both import and export, delete every canvas.js_component.* and every canvas.component.* whose source is js from the sync buffer.

The paired component entity is matched by reading source from the config payload, not by config-name prefix — canvas.component.* is shared with block, sdc, and other sources, which must not be filtered. JsComponent::SOURCE_PLUGIN_ID ('js') is the canonical match.

Service definition in canvas.services.yml:

Drupal\canvas\EventSubscriber\CodeComponentSyncTransformer:
  arguments:
    $configFactory: '@config.factory'
    $activeStorage: '@config.storage'
  tags:
    - { name: event_subscriber }

3. Add CanvasSettingsForm.

New Drupal\canvas\Form\CanvasSettingsForm extending ConfigFormBase exposes a radio under "Code components". Route canvas.settings at /admin/config/canvas/settings, gated by administer code components. Menu link under system.admin_config_user_interface.

4. Tests.

• Kernel test Drupal\Tests\canvas\Kernel\Config\CodeComponentSyncTransformerTest exercises both modes with MemoryStorage: DB-only js_component survives import in preserve_production; sync entry overrides DB; paired js-sourced component is copied while block-sourced is left alone; cli mode strips both on import and export; non-default collections are ignored.
• Functional test Drupal\Tests\canvas\Functional\CanvasSettingsFormTest covers form access, persistence, and 403 for unauthorized users.

5. Out of scope.

• Per-component granularity — global toggle only.
• Features-like reverter UI for diffing active vs sync.
• Pre-import validation step that warns about pending production edits.
• Content templates have the same underlying problem (in-browser editing of a config entity) and will be addressed in a follow-up; their tree-shaped data needs separate consideration.

User interface changes

A new admin page at /admin/config/canvas/settings ("Canvas") under Configuration → User interface. It contains a single "Code components" section with a radio:

• Preserve production-created components (recommended) — default.
• Manage exclusively via Canvas CLI — opt-in.

No other visible changes. Existing sites get preserve_production on the next install/update, which is strictly safer than the current "hard sync" behaviour — it only prevents deletions, it never overrides config-tracked components.