Conf de dev migration

Submitted by Jenny on Sat, 11/03/2018 - 11:18

Tags:

Présentation (rapide) de l'environnement ddev8, qui va servir à Migrer vers drupal 8 (page de 2015 actualisée) , ici un site drupal 7 (env de prod, chez l'hébergeur : php 5, apache, mysql) vers drupal 8 (sous php 7.2, ngninx, mariadb) dans un env de dev.

On aura drush 9.5.2 (en fev 2019) et un drupal 8.6.8 dans un environnement de developpement. Pour l'utilisateur (sur le pc hote, où est installé ddev), un ddev describe montrera les interfaces de base : on peux surfer (depuis l'hote)

le drupal 8 est accessible via https://ddev8.ddev.local
PhpMyAdmin est à http://dded8.ddev.local:8036
emails à http://ddev8.ddev.local:8025 MailHog

Quelques commandes fréquentes, pèle-mele de commandes ddev, composer et drush 9, sont en bas de cette page - drush 9 est très différent de drush 8 (et antérieures).
D'autres commandes ddev sont à ddev : commandes fréquentes (que fait ddev config sur les settings.php, détails sur la db). upgrade vers drupal 8 commente des exemples, et présente les divers modules de migration. L'ancien (date de 2018) Test de ddev a des liens vers la doc ddev, des notes d'un essai d'install et surtout des notes sur la configuration de ddev8

Env de dev "ddev8" - introduction

L'hote (conf de ddev)

Mon poste est sous ubuntu 18.04.1 (sous Gnome3) (linux, Ubuntu "Bionic Beaver", la LTS en nov 2018), avec php 7.2... ddev est un docker "simplifié", avec des images et utilitaires de divers CMS (drupal 7, drupal 8 et d'autres).

Le serveur de dev est un docker 18.06.1-ce (je ne détaille pas cette install) mais vérifier:

docker-compose version et vérifier que docker est ok via:
docker run --rm -t -p 80:80 -v "/$PWD:/tmp/projdir" -v "/$HOME:/tmp/homedir" busybox sh -c "echo ---- Project Directory && ls //tmp/projdir && echo ---- Home Directory && ls //tmp/homedir"
+ install de "ddev" (etre dans le dossier /.../ddev8), installé via curl -L https://raw.githubusercontent.com/drud/ddev/master/scripts/install_ddev.sh | bash
ajouter bash_completions.d avec sudo cp /tmp/ddev_bash_completion.sh /etc/bash_completion.d/

Vérifier avec ddev version (le 7 fev 2019, il retourne:)

bgsync        	drud/ddev-bgsync:v1.5.2       
cli           	v1.5.2                        
commit        	v1.5.2                        
db            	drud/ddev-dbserver:v1.5.2-10.2
dba           	drud/phpmyadmin:v1.5.2        
ddev-ssh-agent	drud/ddev-ssh-agent:v1.5.2    
docker        	18.06.1-ce                    
docker-compose	1.23.2                        
domain        	ddev.local                    
router        	drud/ddev-router:v1.5.2       
web           	drud/ddev-webserver:v1.5.2

Le drupal (dans le serveur ddev)

Alors on installe (le code d')un drupal 8 (etre dans son dossier ddev8) - ceci télécharge les .php de drupal 8, ne l'installe pas

ddev config --project-type php --php-version 7.1
ddev composer create drupal-composer/drupal-project:8.x-dev --stability dev --no-interaction
ddev config

Vu de l'hote, un simple drush st montre Drush 9.5.2 (pas d'alias dans /etc/drush/aliases.drushrc.php et rien de particulier dans /home/userlinux/.composer/vendor/drush/drush/drush.yml.

Le drupal 8.6.x n'étant pas installé (via l'url), seul le lien phpMyAdmin fonctionne (ici http://ddevd8.ddev.local:8036 attention, les ports changent quand ddev se lance), composer et drush.
Une fois installé (via l'URL par ex), le dossier ddev8 pèse déja 127,2 Mo (voir l'arborescence des fichiers à Test de ddev).

Surveiller le poid de /home/userlinux/.ddev si l'on fait des snapshots.
Le dossier ddev8 pèse vite (4 Go), avec des snapshots dedans (cachés dans ddevd8/.ddev/db_snapshots), 50 Mo de fichiers de mon site de prod compris, 2 db.
Certificats en /home/userlinux/.ddev/certs

ddev8

Une fois terminé, on aura un environnement, nommé ddev8, presque complet pour lancer une migration (de drupal v7 vers drupal v8) :

drush 9.5.2 (doc accessible depuis l'hote via les dossiers /.../ddev8/drush),
drupal 8.6.8 (accessible de l'hote via le dossier ddev8/web),
phpmyadmin (logué non en root, mais en db/db seul => on ne peux pas l'utiliser pour voir/créer la 2e db),
conf test serveur d'emails "MailHog", drupal console, composer...
- sur nginx/1.14.2 (ddev logs -f montre aussi toute la conf) et php 7.1.26,
- avec MariaDB 5.5.5-10.2.19 : serveur db et user/pw = db/db (le compte root est root/root) pour le drupal 8 (de destination).
- 1024 M Ram (php.ini)

Le drupal 8 (mono-site ie 1 seule db, un seul virtual host, ddev exec cat /etc/nginx/sites-enabled/nginx-site.conf ou mieux, ddev logs -f).

Il reste à : créer une db (pour y importer la db version drupal 7 plus tard), récupérer les outils drush de migration (et backup).

Création de la db7 (où on importera la base drupal 7 - le mot de passe du compte root MariaDB est root) :

ddev8$ ddev describe --> récup port MySQL
ddev8$ mysql --host 127.0.0.1 --port 32768 -u root -p

mysql> CREATE DATABASE IF NOT EXISTS db7 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
mysql> show databases;
mysql> GRANT ALL PRIVILEGES ON `db7`.* TO 'db'@'%';
mysql> show grants for 'db'@'%';
mysql> FLUSH PRIVILEGES;
mysql> \q
Bye

Pour sortir, saisir \q Voir les différentes bases : show databases; Pour voir les tables de la base "db", faire: use db; SHOW TABLES;
GRANT ALL PRIVILEGES ON `db7`.* TO 'db'@'%'; Pour voir db7 dans phpadmin (mis comme la base db), sinon plutot:
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON db7.* TO 'db'@'localhost' IDENTIFIED BY 'db';
Téléchargement des outils de migration (etre dans le projet ddev8$ ou les ajouter dans ddev8/composer.json)
ddev composer require drupal/migrate_upgrade:^3 ddevcomposer require drupal/migrate_tools ddev composer require drupal/migrate_plus
Voir ce qui est installé avec ddev exec drush pml | grep Ena
On note le thème actif: Stark, bartik est là mais non installé.

Faire une backup des 2 bases de données (db7 est encore vide, les modules contrib et de migrations non installés) avec ddev snapshot -n nom-dump-ini

En pratique... ou d'où lancer quelles commandes ?

Si l'on vient d'installer ddev, il montre les liens pour administrer le drupal 8, sinon, faire: cd ddev8 puis (si besoin ddev start) puis ddev describe
La plupart des commandes sont lancées depuis le bash shell, après le prompt, en ddev8$

De l'hote (vrai pc qui a le serveur docker, et qui a lancé le ddev start depuis le dossier ddev8$) on lance (en ligne de commande, etre dans son projet, ici sous le prompt ddev8$, là où est composer.json) depuis l'hote :

les "ddev composer require drupal/contrib" (dl de modules, via le composer du serveur de test), les commandes ddev (ddev logs -f)... mais
les commandes drush (donc de migrations) sont gérées par le drush v9.5 du containeur, donc après un ddev exec, par ex un: ddev exec drush st

De temps en temps, un message s'affiche pour mettre à jour ddev ou l'image utilisée (drupal, console, composer et drush).
Attention aux commandes "composer", car souvent, elles modifient un fichier composer.json... et des fichiers "composer.json", il y en a dans beaucoup, beaucoup d'autres endroits :p

Update du core drupal 8 (lire /ddev8/drupal/README.md): composer update drupal/core webflo/drupal-core-require-dev symfony/* --with-dependencies

Etude des modules (modifs sur le drupal 7)

entity reference, ckeditor sont intégrés. Soucis des langues (en déactivant i18n, certains vieux articles sont en anglais + divers modules de redirections étaient désactivés) :/
Pour récupér les plugins ckeditor, rechercher dans les modules contrib, ex: le bon codesnipet? Désinstaller (et non désactiver) les modules "abandonnés" dans le drupal 7 avant d'exporter (honeypot: désactiver seul, car desinstall KO).
Global Redirect v7 : intégré à Redirect v8

Si l'on doit travailler sur un ddev le drupal 7, on a les difficultés supplémentaires :

Les environnements ddev pour drupal 7 et 8 sont très différents: drupal 7 plutot orienté drush (avec drush 8.1.15, voir drush help sql-dump) et surtout sans composer.
- Par ex pour drush 8 et drupal 7 : ddev exec drush sql-dump --result-file=chemin/result-file
- alors que pour drush 9 (drupal 8) : ddev exec drush sql:dump --result-file mig1 ddev exec drush theme:enable bartik
si le drupal 7 n'est pas dans defaut mais un autre dossier (soucis de liens en dur). Tester avec quelques fichiers (mup avec http, chemin des dossiers locaux).

Il est utile de documenter le drupal 7 : regarder les widgets des champs persos, la volumétrie du site (car on abandonne des trucs au passage)...

Si on récup son drupal 7 dans un autre ddev "drupal 7":

export de la db (modules désinstallés..)
- Je teste un export (ddev7) mysqldump --host=127.0.0.1 --port= --user=db --password=db --databases db > ../v7_190212.txt
  Si on l'importe, import en base db (et non db7)
- donc, plutot passer par les phpmyadmin

Voir Principe d'une migration drupal 7 vers drupal 8 en 2019 - Liens dans cette page : Quelques commandes

Configuration pour migrer

Il est important d'installer le drupal 8, depuis l'url de l'hote, en fr, profil minimal (avec standard, il crée Articles et ses divers champs, ca va poser soucis) plus les modules drush et drupal 8 requis (les migrate-tools et autres).

Coté drupal 7 (site à migrer), faire un export de la base (et des fichiers sous le dossier sites/files), qu'on importera sur le serveur "db". Il faut importer ce dru7.sql dans notre env de dev, dans une base séparée (et les bons privilèges au user db/db). Ici, l'env de dev du drupal 8 est une MariaDB, base db et deux users : db/db pour drupal et le user root/root (*).

Débutants, ne pas confondre les users (* je le note user/pw, son nom est user et son mot de passe est pw). On ne parle pas ici des comptes utilisateurs dans le site drupal, mais des utilisateurs "coté infrastructure" : Le serveur de base de donnée (ici MariaDB), a un user root/root - on ne trouve pas de suite cette info dans la doc ddev. La base nommée db et le user db ont été créés et configurés par ddev (et le drupal-composer), et c'est ce que connait drupal (cf le ddev/web/sites/defaut/settings.ddev.php). Le user db a des privilèges limités (que sur la base db), alors que root est admin de toutes le db et nous permetra donc de créer la seconde db, où on importera la base du drupal 7 à migrer.

Car, avant de lancer la migration en ligne de commande via drush, il faut avant tout disposer sur le serveur (ici un ddev) :

d'une copie de la base du drupal 7 (que l'on va migrer).
un drupal 8 vierge (l'import va écraser le user ID 1, admin drupal 8, créé lors de l'installation du drupal 8 de destination) - le laisser vierge de contenu. Doit-on ou non créer les types de media? Les conf de texte ?
Puis, prets à être installés (téléchargés, mais non activés ou installés, voir la modif necessaire du settings.php), les modules de migrations (migrate, migrate_drupal 8.6.9, migrate_tools et migrate_plus 4.1 , migrate_upgrade ici en 8.x-3.0-rc5 puis 8.x-3.0 et éventuellement migrate_file 1.1) et les modules voulus (cad, installés sur la v7 source **).
En fev 2019, pas sur la doc drupal https://www.drupal.org/docs/8/upgrade/upgrade-using-drush Donc, je ne fais pas Modifier le settings .php (en nom-projet/web/sites/default). Mais, en fait, il faut la faire, ici retirer les commentaires en haut de ddev_drush_settings.php et ajouter les lignes (base du drupal 7 à migrer, importée en db7, avec prefixe de table pretbl_ optionnel) :
```
$databases['drupal_7']['default'] = array(
  'database' => "db7",
  'username' => "db",
  'password' => "db",
  'host' => "db",
  'driver' => "mysql",
  'port' => 3306,
  'prefix' => "pretbl_",
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);
```
Il vaut mieux copier les fichiers (du drupal 7 à migrer) en local (sous sites/default/sites/unnom) et lancer le mup avec --legacy-root= qui a le bon chemin (un ddev exec drush st le montre : Drupal root : /var/www/html/web
Faire un snapshot avant de commencer la migration (nommé ddevd8_avtmig) - il ne doit pas avoir de trace des exemples Beer et Wine + une sauvegarde des fichiers (snapshot ne sauve que la db).

Note : Il est astucieux de faire un (après le prompt, qui ressemble à "user@host:chemin../ddev1/drupal$ "): ddev snapshot -n migvierge
Cela pourra etre utile pour recommencer depuis de début, après un ddev restore-snapshot migvierge
Car, quand on lance le mup, les .yml de configuration (qui mappent les champs v7 vers les champs v8) sont importés en base (les modifier par la suite ne change rien, car ils ont déja été importés - voir 2 solutions plus bas). En base, mup (ou migrate-upgrade) ajoute des lignes dans la table config, et chaque mim va créer des tables nommées migrate_map_ et migrate_message (des migrate_map_d7_field_instance, migrate_map_upgrade_contact_category...).

Note 2 : en installant avec le profil minimal, le bundle article ne sera pas créé (sinon, doublons de champs lors de la migration). Par contre, il faudra activer les modules du core (sauf article), généralement installés par le profil defaut (Configuration Manager, Custom Block,...).

** modules necessaires pour moi, du core : block_content, CKEditor, config (Configuration Manager), Custom Block, Contact, media, menu_link_content, views_ui et les modules pathauto (avec ctools et token), metatag, admin_toolbar_tools et le thème bartik 8.6 (pour récupérer les blocs aux bons endroits) ddev exec drush theme:enable bartik (avant le mup).
ddev composer require drupal/admin_toolbar ; ddev composer require drupal/pathauto ; ddev composer require drupal/metatag ;

Migrer (données du drupal 7 existant vers drupal 8)

Vérifier que sur le drupal 8 installé, il n'y a pas de données (ID de node), que tous les modules requis sont installés (modules du core drupal 8 et modules contribs à migrer), qu'on a importé la bonne db7, que settings.php n'a pas été écrasé (lors maj, si oubli d'avoir effacé les commentaires).
Ne pas avoir migrate_example_setup et migrate_example_advanced_setup

Import de la db7

ddev8$ mysql --host 127.0.0.1 --port 32768 -u db -p db

mysql> use db7;
mysql> source ../transferts/mig1.sql;
mysql> \q

Lancer la configuration de la migration

Vérifier sur le drupal 8 (avant import) :

le thème, sinon ddev exec drush theme:enable bartik
qu'il ne reste pas de résidu de tout autre test, avant d'importer en base la préconfiguration de la migation (sinon, faire un ddev restore) :

ddev exec drush migrate-upgrade --legacy-db-url=mysql://db:db@db/db7 --legacy-db-prefix=prefixe-de-table --legacy-root=http://url.v7 --configure-only

les droits sur les modules installés, ajouter ckeditor dans les format de texte (et conf barres d'outils), créer les types de média par défaut. On peux aussi faire une installation standard (avec les types de media, et conf ckeditor faites), exporter la configuration (à admin/config/development/configuration/full/export), dézipper le fichier, et récupérer les confs.

Gérer les migrations

En gros : commencer par les users, conf systeme et les vocab (ie upgrade_d7_taxonomy_vocabulary). Puis :

Récupérer les résultats dans son tableur : ../ddev1/drupal$ ddev exec drush ms --group=migrate_drupal_7 --fields=id,total,imported,unprocessed,last_imported --format=csv > ../chemin/nom-fichier.csv
importer les termes via plusieurs "upgrade_d7_taxonomy_term_ID"
filtres de texte (drupal 7 a 3/4 messages filter_null manquant - seul "Plain text" ok) et oembed (cf Module media_oembed)
upgrade_d7_node_type (requis par bp d'autres, et comment_type) et ceux qui en dépendent directement : les divers upgrade_d7_node_bundle et upgrade_d7_node_bundle_revision (soucis révisions et i18n)
Les champs : upgrade_d7_field puis d7_field_instance et leurs widgets
books : après upgrade_d7_node_bundle.

On peux aussi jeter un coup d'oeil via l'interface web, avec l'url /admin/structure/migrate/manage/migrate_drupal_7/migrations
Plus sur cette page, avec un site drupal 7 bilingue, concernant l'ordre de migration

En route, ajouter sur les blocks breadcrumb, et les droits sur les données importées ....

Quelques erreurs ou bugs rencontrés :

message filter_null manquant
=> /admin/config/content/formats/manage/full_html et https://ddevd8.ddev.local/admin/config/content/formats/manage/filtered_html
* Éditeur de texte:= ckeditor + conf barre à faire
Activer les transferts d'images non coché + new items ici à étudier
- Plain text ok (Éditeur de texte: aucun)
- oembed (Éditeur de texte: aucun) https://ddevd8.ddev.local/admin/config/content/formats/manage/oembed?destination=/admin/config/content/formats
  a le message "Le filtre filter_null est manquant"
The "file_rendered" plugin does not exist
The "text_plain" plugin does not exist
Missing file with ID 101 : soucis de chemin
ddev exec drush mr upgrade_d7_file

modifier les définitions des migrations

Ajout host virtuel pour avoir une autre base (multi site)

Au vu des bugs sur la migration i18n et la volumétrie des données du drupal 7, je préfère récupérer sur le site principal les données FR, et avoir un autre site (meme fichiers php, mais autre db) avec les quelques pages bilingues (moins de 20).

Ex de conf d'hotes virtuel ngninx à Installer drupal 8 et drush 8.1 sur un Pi - test 2

https://stackoverflow.com/questions/49785023/how-can-i-create-and-load-a...

Plus

https://www.drupal.org/docs/8/upgrade/upgrade-using-drush
drush migrate-upgrade --legacy-db-url=mysql://user:password@server/db --legacy-root=http://example.com --configure-only
avec 'user' 'password' info user de la db source (ici drupal 7), 'server' est le nom du serveur db source, 'db' est la base de donnée source et 'http://example.com' est la racine du site source un drupal 7).

https://www.drupal.org/docs/8/upgrade/known-issues-when-upgrading-from-d...
https://www.drupal.org/node/1561820

commandes ddev (etre en ddev1/drupal $)

en tp réel (CTRL+C pour sortir) et montre confs des services : ddev logs -f
ddev logs -s db montre log que le container db soit lancé ou non
ddev ssh (pour le container web) ou ddev ssh -s db (pour le container db)
backup
- console drupal: ddev ssh ; drupal database:dump ; drupal database:restore --file undump.sql
- snapshots ddev en ddev1/drupal/.ddev/db_snapshots : ddev snapshot -n nombackup et ddev restore-snapshot nombackup
ddev remove (lancé en ddev1/drupal $) est non destructif : efface les containeurs mais pas la db
ddev remove --remove-data efface conteneurs et db

drush 9

ddev exec drush theme:enable bartik

ddev ssh drush sql:dump --result-file=../db-export.sql

ddev exec drush cget system.site
ddev exec drush state:get system.cron_last
ddev exec drush queue:list
ddev exec drush core-status --fields=*

migration

ddev exec drush list --filter=migrate montre toutes les commandes (et avoir accès à l'aide: drush help mmsg)
ddev exec drush migrate-status ou drush ms
ou via l'url (si module UI activé) /admin/structure/migrate/manage/migrate_drupal_7/migrations
ddev exec drush ms --group=migrate_drupal_7 --fields=id,total,imported,unprocessed,last_imported --format=csv > ../chemin/ms.csv
ddev exec drush migrate-import ID_migration ou drush mim ID_migration plus: drush mim --help
Ou en 1 seul coup ddev exec drush migrate-import --all ; mais en général, on commence par un test.
Lance les tables dépendantes (node_type, user_role et user), puis celle demandée : ddev exec drush mim upgrade_d7_node_book --execute-dependencies
ou par paquets de 10: mim nom_mig --limit=10
ou plus précis (import du user qui a l'ID 5 dans la db source): mim ID_migration --idlist=5
si bloqué en Import (drush ms montre Status tous en Idle, à part sur un en importing), reset statut avec ddev exec drush mrs upgrade_d7_ID
annuler une ou des migrations avec un "drush migrate-rollback" ddev exec drush mr upgrade_d7_ID
alors que mupr annule et efface les opérations d'upgrade.
ddev exec drush mmsg ID_migration

ddev exec drush mr upgrade_d7_file
ddev exec drush mim upgrade_d7_file

basiques :

ddev exec drush mim upgrade_d7_theme_settings,upgrade_d7_user_mail,upgrade_d7_image_styles
ddev exec drush mim upgrade_search_page,upgrade_system_image,upgrade_system_logging,upgrade_system_rss,upgrade_system_site,upgrade_d7_contact_settings,upgrade_d7_user_role
ddev exec drush mim upgrade_default_language,upgrade_user_picture_field,upgrade_user_picture_field_instance

ddev exec drush migrate-import d6_upload_field,upgrade_d6_book_settings,upgrade_d7_global_theme_settings,upgrade_d7_language_types,upgrade_d7_search_settings
ddev exec drush migrate-import upgrade_d7_system_file,upgrade_update_settings,upgrade_user_picture_entity_display,upgrade_user_picture_entity_form_display,upgrade_d7_shortcut_set_users

1 erreur corrigée avec un
drush sql-query "DELETE FROM key_value WHERE collection='system.schema' AND name='outside_in';"

commandes composer (etre en ddev1/drupal $)

composer require 'drupal/migrate_manifest:^1.7'

composer require drupal/pathauto:^1.3   composer require 'drupal/ctools:^3.0’   composer require 'drupal/schema_metatag:^1.3'  
composer require ‘drupal/entity_browser:^2.0’
composer require drupal/permissions_by_term:^2.3

admin_toolbar 1.24

ddev exec drupal config:edit IDmig

Languages

You are here