Récemment, quelqu'un de mon équipe a fait une modification en apparence anodine sur un Single Directory Component (SDC) utilisé par Drupal Canvas : un simple changement d'enum dans le schéma des props du composant, puis un déploiement sur l'environnement de dev.
Le déploiement a échoué pendant :
drush cimavec :
component entity is a versioned config entity, and its loaded version is not the active versionDrupal Canvas ne s'appuie pas directement sur le fichier *.component.yml au runtime.
Pour chaque SDC utilisé par Canvas, il maintient une config entity Component, par exemple :
canvas.component.sdc.<theme>.<component>Cette entité conserve :
active_version, basée sur un hash du schéma des props du composant ;Donc quand vous modifiez le schéma d'un composant — même quelque chose d'aussi simple qu'un enum — la version du composant change.
Après un cache rebuild, Canvas calcule la nouvelle version et l'enregistre en base de données.
Vous pouvez alors vous retrouver avec :
*.component.yml → nouveau schéma / nouveau hash
config sync → ancienne version
base de données → nouvelle version active💥 Et le drush cim suivant peut échouer, parce que la configuration et la version active du composant Canvas ne correspondent plus.
Dès que je modifie le schéma d'un SDC utilisé par Canvas — props, slots, enums, valeurs par défaut, etc. :
drush cr
drush cexPuis je commite les deux côtés du changement ensemble :
*.component.yml
canvas.component.sdc.*.ymlLe schéma du composant et sa configuration Canvas sont en réalité les deux moitiés d'un même changement.
Cela évite aussi que la version Canvas générée dépende de l'environnement qui a lancé le dernier cache rebuild.
Petit détail, mais important dès qu'on fait circuler des changements Drupal Canvas + SDC entre environnements.