Le CMI drupal 8

Changes du core (v7 et v8)

source : https://assos.centrale-marseille.fr/ftorregrosa/blog/la-configuration-en...

Là où en Drupal 7, il y avait une table « variables » stockant la plupart des variables et chaque modules ajoutaient ses tables custom pour stocker sa configuration plus complexe (comme les modules Views, Panels, etc.,) désormais Drupal 8 possède une table « config » dans laquelle toute la configuration, que ce soit de la configuration simple (l'équivalent des variables de Drupal 7) ou que ce soient des entités de configuration (views, styles d'image, types de contenu, etc.), est sérialisée.

  • Cf "L'introduction des entités de configuration" de ftorregrosa (et sa remarque sur drupal console, qui peux générer des confs).
  • L'introduction des States : En Drupal 8, il y a également séparation entre les données à exporter d'un environnement à l'autre (configuration), des données propres à un site sur un environnement données (état / state).
  • La surcharge de la configuration dans les settings :
    1. La valeur surchargée dans le settings est bien utilisée à l'exécution mais n'est pas enregistrée en base de données. Ce qui a pour conséquences :
      1. Que la valeur surchargée dans le settings n'apparaît pas dans les formulaires de configuration, ce qui est assez perturbant la première fois que l'on teste la surcharge de configuration (l'issue à ce sujet).

      2. Que la valeur en base de données peut à nouveau être utilisée en retirant la surcharge du settings. Pas de risque d'écrasée la valeur originale avec la surcharge.

    2. Avec l'uniformisation du stockage, il est donc possible de surcharger des valeurs d'entités de configuration par environnement. Très pratique pour changer le nom de domaine d'un serveur Solr, Redis, Varnish, etc. d'un environnement à l'autre.

Parmis ses inconvéniants :

  • CMI utilise les UUIDs pour vérifier que la configuration fournie ne provient pas d'un autre site et empêche donc son import si le site possède déjà un élément de configuration avec le même nom machine mais un UUID différent : dans le workflow pensé, il faudrait donc partir d'une base de données de production. Impossible pour un développeur de travailler sur un projet en recréant un site à partir de la configuration, obligation de repartir d'une sauvegarde de production.
  • Il est possible pour les modules, thèmes et profils d'installation de fournir de la configuration à l'installation (dossiers config/install et config/optional), mais la modification de ces fichiers n'est pas prise en compte une fois le module/thème/profil installé.
  • une grosse quantité de modules en config_XXX pour trouver des alternatives pour avoir des workflows de développement évitant les problèmes évoqués.
    Cette page a pleins de liens vers des https://www.drupal.org/project/config_XYZ

 

 

 

Liens

https://www.drupal.org/docs/8/configuration-management

En fr, présente bien ses inconvéniants https://assos.centrale-marseille.fr/ftorregrosa/blog/la-configuration-en...

logo drush