- 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
Principe d'une migration drupal 7 vers drupal 8 en 2019
mup configure-only
Suite à un mup (on peux en faire plusieurs), c'est à dire une longue commande de type "ddev exec drush migrate-upgrade ... --configure-only",
la syntaxe type étant
drush migrate-upgrade --legacy-db-url=mysql://user:password@server/db --legacy-db-prefix=drupal_ --legacy-root=http://example.com --configure-only
on va importer les données d'un drupal 7, dans ce nouveau drupal 8 installé (en y effacant les données de type configuration éventuelles, donc autant le laisser vierge, surtout quand on débute), à l'aide de commandes
-
ddev exec drush migrate-import upgrade_d7_nomID
(ou drush mim IDmig), -
voir l'état de la migration avec
ddev exec drush ms
mais aussi l'UI (via l'url en admin/structure/migrate/manage/migrate_drupal_7/migrations), chaque id pouvant générer des messages (ou pas) à un drush mmsg id_mig
Les données vont etre transférées, petit à petit, de tables intermédiaires (créées à cet effet) vers les tables du drupal 8, via divers drush mim id1,id12,id13,id2 et drush mr id12
Alors que si son fait un mup sans --configure-only
, il fait tout d'un coup, drush ms ne renvoi rien.
Dans la pratique
-
le
"mup --configure-only"
va créer plein de configurations de migration (nomméesupgrade_d7_nomID
). Leur nombre dépend des modules actifs dans le drupal 7, et 8 quand on lance la commande, on voit passer ces lignes :Exporting d7_global_theme_settings as upgrade_d7_global_theme_settings
Exporting d7_image_settings as upgrade_d7_image_settings
Exporting d7_image_styles as upgrade_d7_image_styles
En base de donnée, mup travaille sur la table config du drupal 8, crée des tables en migrate_map et migrate_messages.
En cas de soucis sur une d7_nommigration, il est utile d'y rechercher des lignes pour lesquelles destid1 est NULL. Tracer aussi dansMigrateExecutable::import()
la bouclewhile($source->valid) (cf
https://stackoverflow.com/questions/38874193/what-way-to-debug-ignored-i...) -
un drush ms retourne des lignes comme:
Group Migration ID Status Total Imported Unprocessed Last Imported
Import from Drupal 7 upgrade_d7_user_role Idle 7 7 0 2018-11-01 05:59:21
(migrate_drupal_7)
Import from Drupal 7 upgrade_d7_comment_type Idle 10 0 10
Import from Drupal 7 upgrade_d7_field_instance Idle 64 0 64 -
les drush mim retournent des lignes, par ex:
[error] Missing filter plugin: filter_null.
[notice] Processed 4 items (4 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_filter_format'
[notice] Processed 34 items (34 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_field' - ddev exec drush list --filter=migrate donne plus d'infos sur ces commandes
-
Drush vérifie certaines dépendances:
ddev exec drush mim upgrade_d7_shortcut
[error] La migration upgrade_d7_shortcut n'a pas rempli les pré-requis. Missing migrations upgrade_d7_menu, upgrade_d7_shortcut_set, upgrade_d7_menu_links.
ddev exec drush migrate-import upgrade_d7_shortcut --execute-dependencies
Introduction et remarques importantes :
- L'ordre des import est essenciel, car certains champs en référencent d'autres (citons les tables users et node-type, qui sont requises par bp d'autres données).
-
Si migrate voit qu'il manque des données, il crée des données temporaires (nommées stubs), pour les relier ensemble par la suite.
Par ex, au moment où on importe le contenu de ses articles, des termes de taxonomie (référencés via un champs définit sur ce type de contenu donné, qu'on nomme souvent node_bundle), alors que les termes n'existent pas encore. - Les ID des nodes, termes... resteront les meme (site source et destination). Les articles non publiés sont récupérés, en non publiés.
-
Par contre : les vues ne sont pas migrées, les vocabulaires récupérés sont parfois aplatis (si Williams était sous Poire, on va bien récupérer ces 2 termes, mais ils auront le meme père : 0), on a des soucis entre les versions des modules (core ou contrib) v7 et v8... Bien des soucis pour migrer les traductions (module i18n)...
Voir les bugs en cours de migrate-upgrade -
Aucun contenu s'affiche ? Il faut :
- ajouter les droits
-
ouvrir chaque bundle (article, page, book...) car tous les champs liés à un vocabulaire ont perdu le vocabulaire.
Ex à admin/structure/types/manage/article/fields/node.article.field_tags Partie Type de référence / Vocabulaire + Valeur par défaut
-
Attention aux champs qui sont configurés differement selon les bundles.
- Par exemple, field_monimage qui utilise le widget media_browser dans article mais un widget file ou image dans book dans la migration upgrade_d7_field_formatter_settings (qui dépend aussi de upgrade_d7_view_modes). Ainsi, il faut souvent modifier le drupal 7 avant de le migrer : changer les bundle, désactiver des modules... On en profite pour nettoyer, avec VBO (utile pour mettre à jour des sitemaps et metatags...) et ranger les fichiers dans files (ca va les déplacer dans le dossiers définits dans les bundles) avec organize_files (v7 seule).
- Plus génant, le soucis des champs texte : Conflicting text processing settings in Drupal 7
-
Commencer par documenter le drupal 7, nottement sa volumétrie (cf ordre mes migration). Je me suis rendue compte, en testant et prenant ces notes, que j'allais devoir m'y prendre différement, j'y ai donc copié quelques requetes SQL basiques, pour savoir ce qu'on laisse tomber (récupérer ou non, copier à la mano) ou pas.
-
Bon nombre des mes fichiers (pdf, txt, jpg...) sont gérés via des entités Images media v7 et des types de fichiers qu'on gère via une URL admin/structure/file-types/manage/image/fields
Or, ces dernières années, il y a eu de gros updates sur ces modules, et je n'ai pas toujours bien testé les modifications des confs.
concerne les champs v7 field_file_image_alt_text, field_file_image_title_text et field_filetag - Vis à vis des commentaires, qui ont bp changés... J'en avais peu sur le drupal 7, idem pour les révisions. Je vais donc finallement laissser tomber ces aspects là. Faut-il désactiver dans drupal7 ou désinstaller ces modules (forum, commentaire...) : il faut les désinstaller, sinon les commentaires sont recréés.
- les plugins ckeditor... CKEditor CodeSnippet à https://www.drupal.org/project/codesnippet
-
Bon nombre des mes fichiers (pdf, txt, jpg...) sont gérés via des entités Images media v7 et des types de fichiers qu'on gère via une URL admin/structure/file-types/manage/image/fields
En faisant ses premiers tests, on se rend compte qu'il faudrait modifier la structure du site d'origine : optimisation de taxonomies ou de bundle, renommage et réimport de champs.... On peux tenter de le faire lors de la migration - et c'est là que ca se complique, surtout pour des modules comme media (et ses sous-modules) ou basés sur la taxonomie.
C'est la raison pour laquelle j'ai opté pour ddev : ddev snapshot -n unnom et ddev restore-snapshot unnom sont efficaces et rapides.
test fichiers:
ddev exec drush mim upgrade_d7_file --limit=10
ddev exec drush mmsg upgrade_d7_file
ddev exec drush list --filter=migrate
migrate:status (ms) List all migrations with current status.
migrate:import (mim) Perform one or more migration processes.
migrate:rollback (mr) Rollback one or more migrations.
migrate:stop (mst) Stop an active migration operation.
migrate:reset-status (mrs) Reset a active migration's status to idle.
migrate:messages (mmsg) View any messages associated with a migration.
migrate:fields-source (mfs) List the fields available for mapping in a source.
migrate:upgrade (mup) Perform one or more upgrade processes.
migrate:upgrade-rollback (mupr) Rolls back and removes upgrade migrations.
ddev exec drush mfs upgrade_d7_taxonomy_term_machin
-------------- -----------------------------------------------------------
Machine Name Description
-------------- -----------------------------------------------------------
tid L'identifiant du terme.
vid Identifiant (VID) du terme existant
machine_name Nom système du vocabulaire
name Le nom du terme.
description La description du terme.
weight Poids
parent Les identifiants (ID) Drupal des termes parents du terme.
format Format de la description du terme.
-------------- -----------------------------------------------------------
ddev exec drush mfs upgrade_d7_field_formatter_settings
------------------ ----------------------------------------------------
Machine Name Description
------------------ ----------------------------------------------------
id L'identifiant (ID) de l'instance du champ.
field_id L'identifiant (ID) du champ.
field_name Le nom du champ.
entity_type Le type d'entité.
bundle Le paquet de l'entité.
data Les données de l'instance du champ.
deleted Supprimé
type Le type du champ
instances Les instances du champ.
field_definition La définition du champ.
view_mode Le nom machine d'origine du mode de visualisation.
formatter Les paramètres du formateur de champ.
------------------ ----------------------------------------------------