Drupal 8, améliorations back-end : Configuration, entités, cache, webservices - partie 6

Un nouveau système de gestion des configurations

La fonctionnalité la plus attendue par les développeurs (et les webmestres) est sans doute le nouveau système de gestion des configurations.

Auparavant (D7 et inférieurs), le contenu et les configurations du site étaient stockées en base de données.

De fait, le déploiement de nouvelles configuration d’une version de développement vers une version de pré-production ou de production était toujours une affaire risquée. Même en utilisant des solutions comme le module Features ou les fonctions hook_update_N(), cela restait compliqué. Sans parler de la bonne vieille méthode de noter TOUT ces changements effectués en développement sur un bout de papier et de les reporter manuellement dans l’environnement suivant…

Mais ça c’était avant !

Dans D8, tous les changements de configuration (des plus simples comme le nom du site jusqu’aux entités, vues, rôles utilisateurs, types de contenus, etc.) passent par une nouvelle API de configuration.

Chaque environnement (prod / préprod / dev) possêde un 2 entrepôts (2 états) :

• Actif (la configuration en cours)
• Staging (pour y mettre les modifications à venir en provenance d’un autre environnement, comme ceux de dev quand on est sur la préproduction)

Par défaut, les entrepôts continuent à être stockés en BDD, mais il est possible à tout moment de les exporter / importer sous forme de fichiers (au format YAML). Et D8 dispose d’une interface graphique pour les manipulations les plus courantes.

Voici un exemple de ce nouveau _workflow_

1. Sur le site en dev, export de la configuration active sous forme de fichiers (une archive tar)
2. En production, import des fichiers dans l’entrepôt de staging.
3. Dans l’interface de configuration, il est possible de voir ce qui a changé.
4. Si les changements sont ok, on synchronise de staging vers active en production.

A propos du déploiement de contenu

D8 introduit le concept de UUIDs (identifiants uniques universels). Le concept est que chaque site Drupal pour chaque bout de contenu, génère un identifiant suffisamment long pour être unique (et même d’un site à l’autre). Par exemple : b2423870-b19b-45e7-8407-076aee906870.

Cet UUID permet de savoir (indépendamment d’un autre ID tel que le nid) si un contenu existe ou pas sur la destination finale d’un site à migrer et même si ce contenu n’a pas le même id sur le site source et le site destination.

Entités à tous les étages

Les entités étaient une nouveauté clé de la version 7 de Drupal, permettant de rajouter des champs à d’autres types (pas au sens de content type) de contenus que les noeuds. Par exemple : termes de taxonomies, utilisateurs etc.

Cependant cette introduction fut très limitée et nécessitait l’ajout de modules supplémentaires comme Entity API pour être vraiment utilisable.

Avec D8, cette l’API entity a été entièrement revue, non seulement pour combler ses lacunes mais aussi pour faciliter le travail des développeurs.

Toutes les entités font désormais partie de la même classe objet avec une seule interface standard. Tout ce qui est susceptible d’être créé plus d’une fois a été transformé en entité. Il en existe désormais 2 sortes :

1. Config entities
2. Content entities

Quelles différences ?

Chaque entité dispose d’un système de révision identique à celui disponible pour les noeuds.

La fin du hook_schema() ?

Avec les 2 API : Entity et Config / State, il n’y a quasiment plus de (bonnes) raisons de maintenir ses propres tables à la main en plus de celles de Drupal.

Avec Drupal 8, les développeurs auront moins de code à écrire pour obtenir le même résultat, mais ces changements ouvrent la voie à une portabilité du code sur d’autres bases de données comme MongoDB par exemple.

Web Services

Permettre de créer des applications mobiles à partir de back-ends Drupal et faciliter la communication entre sites internets et ressources tierces, tels étaient l’un des buts de D8. Cette 8ême version dispose donc d’une API REST disponible nativement. Une fois cette API correctement configurée (et il y a même une interface graphique pour cela), le contenu de votre site peut être rapidement disponible au format JSON par exemple : 

   [title] => Array
    (
        [0] => Array
            (
                [value] => Hello, world!
                [lang] => en
            )
)
[body] => Array
    (
        [0] => Array
            (
                [value] => <p>This is my <strong>awesome</strong> article.</p>
                [format] => basic_html
                [summary] =>
            )
)

Voici un exemple de site mobile réalisé avec la libraire jQuery Mobile dont le contenu est extrait de Drupal :

Drupal 8 est également fourni avec une nouvelle bibliothèque externe : Guzzle qui permet de faciliter les échanges (au format HTTP) avec des webservices tels que Twitter ou Github au moyen d’une syntaxe simple.

Et pour finir, le module RESTFul Webservices inclus dans le core permet d’exporter toute vue au format REST.

Ce qui veut dire qu’il est possible de créer des flux JSON ou XML en quelques clics et sans modules supplémentaires !

Une gestion du cache améliorée

• Entity cache module est inclus dans le core
• Cache tags pour permettre une granularité plus fine dans la gestion et la purge des caches à chaque création / modification de contenu.
• toutes les fonctionnalités de cache, telles que l’agrégation CSS/JS sont activées par défaut.

@lcoullet

> Partie 1 : Présentation des nouveautés et spécificités de Drupal 8

> Partie 2 : Drupal 8, mobile first

> Partie 3 : Améliorations pour les sites builders

> Partie 4 : Le multilinguisme

> Partie 5 : Améliorations Front-end

> Partie 6 : Améliorations Back-end