CMI : De la théorie...

CMI, ou « Content Management Initiative » représente l’une des avancées majeures de Drupal 8 visant à répondre à un besoin semblant simple au premier abord : Apporter une solution permettant de synchroniser la configuration d’un site entre plusieurs instances.

Comme le disait Greg Dunlap, le leader du projet :

CMI hopes to separate management of your code and content once and for all! We want to make it possible to store your site’s configuration in a standard API separate from its content, soliving issues like feature management and content staging that are cumbersome in previous Drupal versions.”

Mais ça ressemble à quoi ?

Il s’agit principalement d’une API fournissant aux développeurs une manière simple, standardisée, de stocker de la configuration de telle sorte qu’elle soit déployable. Pour l’utilisateur final, cela signifie que nous sommes désormais capables de créer et configurer un site sur un serveur (de développement, de préproduction) et de le « déplacer » ensuite en production cette même configuration.

Pour bien comprendre le fonctionnement, il faut d’abord clarifier deux notions que CMI utilise : Active storage et Staging Storage.

• L’Active Storage est un espace, par défaut la base de données, où Drupal stocke la configuration courante du site.
• Le Staging Storage est lui un espace, par défaut le système de fichier, où Drupal stocke la configuration qu’il va devoir importer.

Chaque changement entre le Staging et l’Active peut être visualisé dans l’administration de Drupal.

Examinons ensemble un exemple d’un fichier de configuration, ici le fichier définissant le type de contenu « Book » :

langcode: en
status: true
dependencies:
  enforced:
    module:
      - book
name: 'Book page'
type: book
description: 'Books have a built-in hierarchical navigation. Use for handbooks or tutorials.'
help: ''
new_revision: false
preview_mode: 1
display_submitted: true

Comme on peut le voir, la configuration reste très compréhensible et facile à lire. Le plus important à comprendre est que ces fichiers fonctionnent sur un mode déclaratif.

Qu'est-ce que le mode déclaratif ?

Voyons ce que nous dit Wikipedia :

La programmation déclarative est un paradigme de programmation. Il consiste à créer des applications sur la base de composants logiciels indépendants du contexte et ne comportant aucun état interne. Autrement dit, l'appel d'un de ces composants avec les mêmes arguments produit exactement le même résultat, quel que soit le moment et le contexte de l'appel.

En programmation déclarative, on décrit le quoi, c'est-à-dire le problème. Par exemple, les pages HTML sont déclaratives car elles décrivent ce que contient une page (texte, titres, paragraphes, etc.) et non comment les afficher (positionnement, couleurs, polices de caractères, etc.). Alors qu'en programmation impérative (par exemple, avec le C ou Java), on décrit le comment, c'est-à-dire la structure de contrôle correspondant à la solution.

Autrement dit, en simplifiant, on pourrait dire :

• Programmation impérative : décris à la « machine » comment faire quelque chose, et il en résulte ce que vous escomptez.
• Programmation déclarative : décris à la « machine » ce que vous souhaitez qu’il se passe, et laisse la machine trouver comment y arriver

CMI n’est pas features !

Si vous aviez l’habitude (et vous devez l’avoir !) d’utiliser le module Features, vous serez peut-être un peu perdu au début. En effet, il ne faut pas oublier le but initial de Features était de pouvoir packager des « trucs » ensemble afin qu’ils puissent être réutilisés.
Ce n’est pas du tout le but de CMI. Ici, on exporte systématiquement l’ensemble de la configuration de votre site, et non pas une petite section.

Pour résumer, CMI est donc un outil permettant de gérer la configuration de manière déclarative, versionnable, et déployable.

Prochaine étape, la pratique !