Nous avons présenté plusieurs exemples dans le cadre de cette série de blogues sur la migration. Elles ont commencé de façon très simple et sont devenues de plus en plus complexes. Jusqu'à présent, nous avons été plutôt optimistes. Obtenez le code exemple, installez n'importe quelle dépendance de module, activez le module qui définit la migration, et exécutez-le en supposant que tout fonctionne du premier coup. Mais les migrations Drupal impliquent souvent un peu d'essais et d'erreurs. Il s'agit à tout le moins d'un processus itératif. Aujourd'hui, nous allons parler de ce qui se passe après les opérations d'importation et de rollback, comment récupérer après une migration ratée, et quelques conseils pour écrire des fichiers de définition.

Jusqu'à présent, nous avons appris à écrire des migrations Drupal basiques et à utiliser des plugins de processus pour transformer les données afin de répondre au format attendu par la destination. Dans le post précédent, nous avons appris l'une des nombreuses approches de la migration des images. Dans l'exemple d'aujourd'hui, nous allons le changer un peu pour introduire deux nouveaux concepts de migration: les constantes et les pseudo-champs.

Dans le post précédente, nous avons appris comment utiliser les plugins de processus pour transformer les données entre la source et la destination. Certains champs Drupal ont des composants multiples. Par exemple, les champs texte formatés enregistrent le texte à afficher et le format texte à appliquer. Les champs d'image stockent une référence au fichier, le texte de l'alternative et du titre, la largeur et la hauteur. L'API de migration se réfère au composant d'une champ comme sous-champ.

Dans l'entrée précédente, nous avons écrit notre première migration Drupal. Dans cet exemple, nous avons copié les valeurs mot à mot de la source vers la destination. D’habitude, les données doivent être transformées d'une manière ou d'une autre pour correspondre au format attendu par la destination ou pour répondre aux besoins métier. Aujourd'hui, nous allons en apprendre plus sur les plugins de processus et comment ils fonctionnent dans le cadre de le pipeline de migration Drupal.

Dans le post précédent, nous avons appris que l'API Migrate est une implémentation d'un framework ETL. Nous avons également parlé des étapes de l'écriture et de la gestion des migrations. Maintenant, écrivons notre première migration Drupal. Nous allons commencer par un exemple très simple : créer des nœuds à partir de données codées en dur. Pour cela, nous supposons une installation Drupal utilisant le profil d'installation `standard'; qui est fourni avec le type de contenu `Basic Page'. Au fur et à mesure que nous progresserons dans la série, les migrations deviendront plus complètes et plus complexes. Idéalement, un seul concept sera introduit à la fois. Lorsque cela n'est pas possible, nous vous expliquerons comment les différentes parties fonctionnent ensemble. L'objectif de la leçon d'aujourd'hui est d'apprendre la structure d'un fichier de définition de migration et comment l'exécuter.

L'API Migrate est un système très flexible et puissant qui vous permet de collecter des données depuis différents emplacements et de les stocker dans Drupal. Il s'agit en fait d'un framework d'extraction, de transformation et d’alimentation (ETL) complet. Par exemple, il pourrait produire des fichiers CSV. Son utilisation principale, néanmoins, est de créer des entités de contenu Drupal : noeuds, utilisateurs, fichiers, commentaires, etc. L'API est documentée à fond et ses responsables sont très actifs dans le canal #migration en slack pour ceux qui ont besoin d'aide. Les cas d'utilisation de l'API de migration sont nombreux et varient considérablement. Aujourd'hui, nous commençons une série d'articles de blog qui couvriront différents concepts de migration afin que vous puissiez les appliquer à votre projet particulier.

Dans Drupal, une vue est une liste d'informations. Il peut contenir une liste de nœuds, d'utilisateurs, de commentaires, de termes de taxonomie, de fichiers, etc. Une vue scanne votre site Web à l'aide de tous les critères que vous spécifiez et présente les résultats dans le format de votre choix. Exemples de formats : un tableau HTML, un flux RSS, un document PDF, un document CSV, une carte interactive, un diaporama d'images ou une représentation JSON à utiliser comme point final REST. Le même contenu peut être présenté dans plusieurs formats en même temps. Par exemple, vous pouvez présenter un tableau d'informations utilisateur et sur la même page un lien pour télécharger les données au format CSV.

Poursuivons notre voyage pour comprendre plus de concepts Drupal. Comme vous l'avez peut-être déjà remarqué, ils s'appuient l'un sur l'autre. Aujourd'hui, vous apprendrez comment les nœuds, les types de contenu et les champs peuvent être utilisés dans le cadre de configurations de vues. Vous trouverez également des exemples de blocs créés à l'aide de vues.

Nous avons déjà parlé des nœuds, des types de contenu et des champs. Dans Drupal, ils comprennent souvent le contenu principal d'une page. Il est fort probable que vous souhaitiez afficher des informations supplémentaires dans le reste de la page. Cela peut se faire à l'aide de conteneurs appelés blocs (en anglais, "blocks"). Par exemple, le contenu principal d'une page peut être un article de nouvelles et un bloc peut être utilisé pour afficher une liste d'autres articles écrits par le même auteur. Vous pouvez également utiliser un bloc pour afficher une zone de recherche ou un texte de copyright. Voyons ce que les blocs Drupal ont à offrir.

Après avoir compris la différence entre les nœuds et les types de contenu, il faut apprendre un nouveau concept. Les champs (en anglais, fields) sont le mécanisme de stockage de données atomique de Drupal. Ils vous permettent d'enregistrer des informations discrètes qui peuvent être utilisées à des fins d'affichage, de filtrage et de tri. Les champs peuvent être attachés aux nœuds, utilisateurs, termes de taxonomie, blogs et autres entités Drupal. Il est possible de partager un champ entre les paquets d'une même entité. Par exemple, vous pouvez partager un champ d'image entre différents types de contenu (paquets) de l'entité content (nœud).