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. Les deux peuvent être utilisés comme données génériques dans la ligne de temps de migration. Avec d’autres plugins de processus, ils vous permettent de construire des valeurs dynamiques qui peuvent être utilisées dans le cadre du pipeline de processus.

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. Aujourd’hui, nous allons apprendre comment migrer vers ces sous-champs et savoir quels sont les sous-champs disponibles.

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.