- Accueil
- Info légales
- Aide (FAQ)
- Les tags de ce site
- Bloc note
- Articles techniques
- Notes system
- Divers articles
- Drupal
- Notes ITIL 2007
- Notes MS
- Dans le quartier...
- Emploi
- Recettes de cuisine et adresses gourmandes
- mes applis ubuntu préferées
- Divers acronymes du monde social
- Internet 2018
- P2 meublé à louer - quartier du Poteau 75018
- apcos - réseaux sociaux et outils
- Articles techniques
- Divers liens
- Fun
- Mon CV IT
- Nouveautés
upgrade vers drupal 8
Exemples Beer et Wine
Avec migrate_drupal, migrate_drupal_multilingual 8.6.2, migrate_plus, migrate_tools... en 8.x-4.0, migrate_upgrade 8.x-3.0-rc5
La base : migrate_example du module migrate_plus
Lire /migrate_plus/migrate_example/README.txt : explique comment créer un groupe de migration BEER... et la structure des dossiers. Ici, la version du module est 8.x-4.0
Cet exemple explique 2 composants importants :
-
configuration de la migration : fichiers YAML des dossiers config/install et migrations
-
migrations
ces fichiers (nommés migrationID.yml) configurent directement les plugins de migration. A utiliser qd la conf est codée en dur et ne doit pas etre écrasée (via UI web). Il faut ensuite faire un drush cr -
config/install
ces fichiers conf des entitées de configuration, et sont nommés migrate_plus.migration.migrationID.yml
-
migrations
- source des plugins (dans src/Plugin/migrate/source)
Lire ensuite :
- migrate_plus.migration_group.beer.yml ou comment créer un groupe de migration BEER
-
migrate_plus.migration.beer_term.yml ou comment lire les data source, les traiter et où les enregistrer
- instructions de bases : id, label, migration_group et migration_tags
-
le plugin de source obligatoire (lignes 19 à 24), associé à src/Plugin/migrate/source/BeerTerm.php (ce fichier a diverses fonctions: query(), fields et function getIds)
source:
plugin: beer_term -
le plugin destination obligatoire, qui va écrire les données dans les bonnes entitées (ici des termes de taxo).
destination:
plugin: entity:taxonomy_term -
le traitement suit (lignes 38 à 79), après process: chaque champs de destination sera rempli par quelle sources (il pourra etre rempli via plusieurs plugins lancés successivement) ?
-
le plugin par défaut (qu'on n'a pas besoin de nommer), le plus simple est get
Fichier de conf migrer des termes lignes de migrate_plus.migration.beer_term.yml notes id: beer_term
label: Migrate ... de source vers termes
migration_group: beer
migration_tags:
- examplesource:
plugin: beer_term
destination:
plugin: entity:taxonomy_termla base
(se passe de commentaires)Source:
voir src/Plugin/migrate/source/BeerTerm.phpprocess:
name: style
description: detailsIci, on copie la source, un champ nommé style, vers un champs (terme de taxo) nommé name + un champs details vers description
Rq: à gauche la destination, à droite les sourcesvid:
plugin: default_value
default_value: migrate_example_beer_stylesCodage en dur de la valeur de destination : cas simple du plugin default_value (là, contrairement à la ligne ci dessus, les valeurs sont à droite du =)
- vid : ID du vocab de destination
parent:
plugin: migration_lookup
migration: beer_term
source: style_parentplugin migration : pour garder le lien entre les ids source et destination. Ici, le nom des termes sert d'ID dans la v7, la v8 aura un champs ID de terme.
Ici, sur beer_term lui-meme, pour référencer les parents d'abordmigration_dependencies: {}
dependencies:
enforced:
module:
- migrate_exampledépendences : laissé vide pour le moment
-
le plugin par défaut (qu'on n'a pas besoin de nommer), le plus simple est get
-
Les users : migrate_plus.migration.beer_user.yml et BeerUser.php
migrer les users migrate_plus.migration.beer_user.yml (extraits) notes source:
plugin: beer_user
destination:
plugin: entity:user
process:
pass: password
mail: email
init: email
status: status
roles:
plugin: default_value
default_value: 2Le BeerUser.php
(dans /modules/contrib/migrate_plus/migrate_example/src/Plugin/migrate/source/) a une fonction prepareRow pour récupérer leurs bières favorites (dans leur user profile v7)
=> cas de référence circulaire entre users et beers.name:
plugin: dedupe_entity
source: username
entity_type: user
field: name
postfix: _dedupe_entity est un plugin de process
Dans la source, on pouvait avoir des users avec le meme nom, il va créer un nom unique en cas de doublon : est-ce que le nom qu'on traite existe déja (dans destination) ?
Le second sera renommé selon _1, puis _2...created:
plugin: callback
source: registered
callable: strtotime
changed: '@created'
access: '@created'
login: '@created'callback permet ici de filter sur une valeur en entrée (de la source) via une fonction PHP.
Le timestamp v7 est en yyyy-mm-dd hh:mm:ss et non au format Unix.La v7 a 1 seul champs, registered, la v8 plusieurs - ici on les remplit d'un coup avec la meme valeur (issue de date de la création).
@ la suite est interprétée comme le nom de la destination (et non de la source)field_migrate_example_gender:
plugin: static_map
source: sex
map:
0: Male
1: Female
bypass: trueplugin de process static_map
On change des 0 ou 1 (du sex source) en champ texte (ici: Male et Female)Si sex vide, le user n'est pas importé. Or, on veux que si sex vide, le user soit traité, champ laissé vidé
field_migrate_example_favbeers:
plugin: migration_lookup
source: beers
migration: beer_nodeEn général, on commence par migrer users et termes, puis les nodes.
Ici, chaque user a dans son profile des reférences vers des nodes non importés - on a une référence circulaire entre users et beers.Référence circulaire : la migration crée des stubs d'attente (ici, il crée des stubs de nodes de type beer vides, dans la table d'association beer_node). Quand on importera les bières, il remplira d'abord ces bières vides, au lieu de créer de nouveau nodes beer.
-
migrate_plus.migration.beer_node.yml (et son BeerNode.php)
Ex migration des nodes migrate_plus.migration.beer_node.yml Notes id: beer_node
label: Beers of the world
migration_group: beer
migration_tags:
- example
source:
plugin: beer_node
destination:
plugin: entity:node
process:type:
plugin: default_value
default_value: migrate_example_beer
title: name
nid: bid
uid:
plugin: migration_lookup
migration: beer_user
source: aid
sticky:
plugin: default_value
default_value: 0
field_migrate_example_country: countries
field_migrate_example_beer_style:
plugin: migration_lookup
migration: beer_term
source: terms
'body/value': body
'body/summary': excerpt
migration_dependencies:
required:
- beer_term
- beer_userCodage de bundle
/ étant un car spécial YAML, il faut mettre des quotes. Ici / sert à séparer nom de champs avec la valeur interne, pour récupéréer des champs textes (avec résumés)
Les nodes beers ont des ref vers des termes et users (qui doivent etre importés en 1er, d'où ajout de dépendance).
optional dependencies : modifie l'ordre d'affichage (et lancées par défaut), mais de facon informative
Puis : migrate_example_advanced du module migrate_plus
Modules et outils de migration
Nom | Où ? | Que fait-il ? |
---|---|---|
Migrate | module du core Drupal 8 | API pour migrer la configuration et le contenu vers Drupal 8. La source peux etre sur un autre systeme |
Migrate Drupal | module du core Drupal 8 | Fourni les classes necessaire à la migration (cf ligne prec) d'un site Drupal source vers Drupal 8 (cas particulier de Migrate). |
Migrate Drupal UI |
module du core Drupal 8 (8.1+) + module pour les v8 précédentes |
Fourni une UI pour upgrade de Drupal 6 ou Drupal 7 vers Drupal 8 |
migrate_upgrade | Contributed module | La commande drush migrate-upgrade ne marche pas avec 8.3.1 mais avec les 8.2 |
Migrate Tools | Contributed module |
Prpose des options supplémentaire à drush (migrate-status, migrate-import, migrate-rollback, migrate-stop, migrate-reset-status, migrate-messages, migrate-fields-source) et des outils UI pour gérer ses migrations. 8.x-4.x - Compatible with Drupal 8.3.x |
Migrate Plus | Contributed module | APIs pour grouper des migrations, manipuler des données en entrée lors des migrations, code ex pour construire ses migrations personnalisées |
Migrate Manifest | Contributed module | Ajoute une commande drush pour lancer des migrations template-based SQL à partir d'un fichier manifest |
Migrate UI | Contributed module | une UI pour modifier et configurer les migrations en général (pas que des sources Drupal). |
Migration plugins | Dans le core et modules | Donne mapping pour la configuration et le contenu content d'u module. Par example, les plugins de migration qui gèrent la taxonomy et les termes stockés dans le module de taxomonie du core. |
En archive (mais tjs utile):
Upgrading from Drupal 6 or 7 to Drupal 8 (de mars 2017) à https://www.drupal.org/upgrade/migrate
Réécrit pour drupal 8. Installer une v8 (activer Migrate) qui a accès (db et fichiers) à version antérieure (à migrer), il va modifier la v8 en cours avec le contenu récupéré (sans modifier le site d'origine).
que le contenu, users, taxo, bloc menus et format de filtre ; pas les views, i18n.
Le core drupal 8 a 3 sous modules: 'Migrate', 'Migrate Drupal', and 'Migrate Drupal UI'.
'Migrate drupal' requiert migrate. En fait 2 systèmes séparés: un pour les updates (ex: de 8.0 vers 8.1 - toujoursavec url/update), et un pour les 'upgrade/migration' (de v7 vers v8, ressemble à migrate ou migrate_2d).
principe
Installer une v8 (activer Migrate du core) et qui a accès (db et fichiers) à version antérieure (à migrer) - on garde une v8 vierge pour comparaison, il va modifier la v8 en cours avec le contenu récupéré.
Puis activer migrate_upgrade sur la v8. Aller à son url/upgrade (entrer les infos de la bd)
préparer puis soit avec UI (mais pas de rollback) soit avec drush.