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ées upgrade_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 dans MigrateExecutable::import() la boucle while($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

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