Apprenez Drupal

Sélecteur de langue

Mauricio Dinarte

Conseils pour écrire des migrations Drupal

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.

Utilisation de constantes et de pseudo-champs comme espaces réservés de données dans les migrations Drupal

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.

Migrer les données dans les sous-champs Drupal

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.

Utilisation de plugins de processus pour la transformation de données dans les migrations Drupal

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.

Ecrire votre première 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.

Les migrations Drupal: Comprendre le processus ETL

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.

Qu’est-ce qu’une vue dans Drupal? Comment fonctionnent-ils?

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.

Utiliser les blocs Drupal pour enrichir le contenu de votre site web

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.

La polyvalence des champs Drupal

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).

Quelle est la différence entre un nœud et un type de contenu en Drupal?

On écoute les termes nœud et type de contenu souvent quand on commence apprendre Drupal. Parfois, on les utilise de façon interchangeable, mais ils represent concepts très différents. Commençons apprendre la différence et la manière dans laquelle ils se rapportent. On va apprendre attributs que tous les nœuds partagent, la manière dans laquelle les types de contenu peuvent apporter valeurs par défaut, et comment un type de contenu peuvent apporter des gabarits spécifiques pour collecter différents types d’information.