Canvas-Footer und Menü-Config können durch ddev drush cim -y auf einem
veralteten Branch auf generische Recipe-Defaults zurückgesetzt werden. drush recipe:apply recipes/byte
darf auf einer laufenden SOLCOM-Instanz nicht mehr ausgeführt werden — auch nicht automatisch.
Diagnosiert am 2026-05-17 nach Regression von 19 Config-Files.
Am 2026-05-17 wurden 19 Config-Files diagnostiziert, die auf Drupal/Canvas-Recipe-Defaults zurückgesetzt waren. Betroffen:
canvas.component.sdc.byte_theme.footer.yml)Beispiel-Diff fuer den Footer (vereinfacht):
composer drupal:recipe-unpack (im DDEV post-start Hook)
ist nicht der Verursacher — dieses Composer-Plugin modifiziert nur
composer.json/composer.lock und schreibt keine Drupal-Config.
Die wahrscheinlichste Ursache: Ein manuelles ddev drush cim -y wurde auf
einem Branch ausgefuehrt, dessen config/sync/-Files aelter sind als Commit
72657b3 (der den SOLCOM-Footer hinzufuegt). Beim Import einer aelteren
config/sync/-Version werden die SOLCOM-spezifischen Canvas-Slot-Definitionen
durch die dort gespeicherten Recipe-Defaults ueberschrieben.
Wie es passieren kann:
config/sync/ (vor dem Footer-Commit).ddev drush cim -y importiert die veralteten Config-Files in die
(geteilte) Datenbank.cim in Worktree A ueberschreibt den Stand von
Worktree B.cim fehlen SOLCOM-Footer-Slots im Canvas-Editor.
drush cex zeigt dann Diff gegen config/sync/ — dieser Diff
verraet, welche Files ueberschrieben wurden.
recipe:apply byte ist nicht re-apply-sicher
Zweite Ursache: Ein manuelles drush recipe:apply recipes/byte ueberschreibt
bestehende Config via simpleConfigUpdate — ohne Preservation-Mechanik.
Das Recipe-File recipes/byte/config/canvas.component.sdc.byte_theme.footer.yml
enthaelt generische byte-Recipe-Defaults:
Statt dem SOLCOM-Stand (active_version: 28c9e503a860cda4, langcode: de).
Ein erneutes recipe:apply schreibt diesen generischen Stand blind zurueck und
ueberschreibt den SOLCOM-spezifischen Inhalt vollstaendig. Das ist der Grund, warum
drush recipe:apply recipes/byte auf einer laufenden SOLCOM-Instanz
verboten ist.
cim: Branch-Check.
Insbesondere in Worktree-Setups pruefen, auf welchem Branch die gemeinsame Datenbank
zuletzt konfiguriert wurde. Faustregel: ddev drush cim -y nur ausfuehren,
wenn der aktuelle Branch denselben oder einen neueren config/sync/-Stand
hat als die DB. Im Zweifel erst drush cex und den Diff pruefen.
Skill drupal-config-workflow dokumentiert den sicheren Branch-Switch-Workflow.
drush recipe:apply recipes/byte nicht mehr ausfuehren — auch nicht automatisch.
Das byte-Recipe ist fuer den einmaligen Initial-Setup einer frischen
Drupal-Instanz gedacht, nicht fuer idempotentes Re-Apply. Die Recipe-Files enthalten
generische Defaults; ein erneutes Anwenden wuerde den SOLCOM-Stand vollstaendig
ueberschreiben. Falls die Recipe je wieder benoetigt wird (z. B. fuer eine
neue Instanz), ist ein separater Sync-Schritt davor zwingend erforderlich.
recipe:apply recipes/byte ist kein Routine-Kommando.
Das byte-Recipe ist fuer den einmaligen Initial-Setup einer frischen
Drupal-Instanz gedacht. Auf einer laufenden SOLCOM-Instanz hat recipe:apply
nichts zu suchen — ausser in explizit dokumentierten Upgrade-Szenarien.
Diese Convention gilt ab sofort als projektverbindlich.