Site Officiel
Migration Media et Images Inline
Dans la série d'articles sur la migration de mon site https://www.vincentliefooghe.net/content/migration-drupal-7-vers-drupal-8 j'en viens maintenant à une partie qui m'a pris pas mal de temps et demandé un peu de développement.
Sur mon site en Drupal 7, j'avais utilisé le module Media_Wysiwyg et Colorbox, qui me permettaient d'insérer des images directement dans le texte.
Je n'ai pas trouvé d'équivalent sous Drupal 8, mais en utilisant comme format d'affichage "Colorbox" pour le champ media_image, ceci répond à mon besoin : ouvrir un champ image dans une "lightbox".
Il reste donc à convertir les fichiers en média, et ensuite à convertir, dans le corps du texte de chaque contenu, les tags "colorbox" en tags "drupal media".
Lors de la migration, les fichiers ont bien été importés. Par contre ils ne sont pas reconnus comme media par Drupal ,et donc pas réutilisables.
Après avoir cherché - en vain - des modules qui géraient ceci, j'ai fini par passer par un bout de programme PHP qui utilise les fonctions de Drupal pour réaliser cette opération.
Le code php est le suivant :
query("select * from file_managed where filemime like 'image%'")->fetchAll();
foreach ($results as $file ) {
echo "File name:",$file->filename," Id : ",$file->fid," mime : ",$file->filemime," uid : ",$file->uid;
echo "Creation du Media Image pour ",$file->filename,PHP_EOL;
$media = Media::create([
'bundle' => 'image',
'uid' => $file->uid,
'langcode' => $file->langcode,
'field_media_image' => [
'target_id' => $file->fid,
'alt' => $file->filename
]
]);
$media->setPublished(TRUE);
$retour=$media->save();
if ( $retour != 1 ) {
echo "Retour KO ? ",$retour,PHP_EOL;
}
}
return (TRUE);
On peut le lancer avec drush, via la commande :
drush --uri=drupal.loc scr /chemin/vers/mon/fichier.php
Après cette étape, on récupère bien dans la librairies de media tous les fichiers
Pour convertir les tags, j'ai développé un programme PHP qui va remplacer les instructions inline Colorbox, par exemple
[[{"type":"media","view_mode":"colorbox","fid":"88","attributes":{"alt":"","class":"media-image","height":"300","typeof":"foaf:Image","width":"494"}}]]
par
Le script sera lancé avec en paramètre le Node Id à traiter :
php mediaInline.php -i nid
Par exemple
php mediaInline.php -i 136
Note : j'ai fait le choix de traiter les contenus un par un. Au total, j'avais identifié une vingtaine d'articles concernés. La migration unitaire me permettait de vérifier le traitement pour chacun.
Afin de voir le résultat, il faut vider le cache Drupal avec la commande :
drush cr
vincentl
lun 20/04/2020 - 21:54
Migration avec le module migrate_upgrade
On va installer les 2 modules suivants : migrate_upgrade, migrate_tools.
composer require drupal/migrate_upgrade composer require drupal/migrate_tools Puis activer les modules :
drush pm:enable migrate_upgrade migrate_tools -y Dans le fichier settings.php , il faut ajouter la définition de la base source.
Important : elle doit s'appeler migrate.
Par exemple :
$databases['migrate']['default'] =
array ( 'database' => 'dbdrupal7',
'username' => 'user_drupal7',
'password' => 'mdp_drupal7',
'prefix' => '',
'host' => 'localhost',
'port' => '3306',
'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
'driver' => 'mysql'
);
Dans la version que j'ai installé, on peut utiliser migrate_upgrade pour générer les scripts de migration, qui seront lancés avec drush.
Attention : à cause d'une incompatibilité avec drush 10, cette fonction nécessite que l'on modifie le fichier vendor/drush/drush/includes/drush.inc pour ajouter la définition de drush_print :
function drush_print($message = '', $indent = 0, $handle = NULL, $newline = TRUE) {
$msg = str_repeat(' ', $indent) . (string)$message;
if ($newline) {
$msg .= "\n";
}
if (($charset = 'UTF-8' ) && function_exists('iconv')) {
$msg = iconv('UTF-8', $charset, $msg);
}
if (!$handle) {
$handle = STDOUT;
}
fwrite($handle, $msg);}
Sinon on a le message :
drush migrate-upgrade --legacy-db-key=migrate --configure-only [error] Error: Call to undefined function drush_get_option() in drush_print()
Lancer la commande avec le chemin vers le répertoire source "legacy", ce qui permet de migrer les fichiers également :
drush migrate-upgrade --legacy-db-key=migrate --legacy-root /var/www/drupal7/vincentl --migration-prefix=upg1_ --configure-only
On peut ensuite voir le résultat avec la commande drush migrate-status
Et on peut lancer la migration avec :
drush migrate:import upg1_d7_taxonomy_vocabulary drush migrate:import upg1_d7_taxonomy_term_categorie drush migrate:import upg1_d7_taxonomy_term_tags drush migrate-import --group=migrate_drupal_7
Note : je lance d'abord les migrations de taxonomie pour que la génération des liens de menu se passe correctement. Comme dit précédemment, le processus est assez itératif et a demandé plusieurs essais avant de trouver les bons réglages.
Après cette étape, le contenu a été migré, ainsi que les types de contenu, les menus, etc.
Il reste à faire quelques mises au point et reprise de paramétrage sur les formats de texte (insertion du bouton media par exemple), ainsi que refaire le thème, et traiter le cas des images inline.
vincentl
lun 20/04/2020 - 21:42
Processus de migration vers Drupal 8
Le processus de migration a été testé plusieurs fois. Je suis parti sur la base d'une sauvegarde du site Drupal 7 (fichiers + base de données).
J'ai installé ça dans un container LXC sur mon PC, ce qui me permettra de supprimer tout cela une fois la migration terminée.
Au final, on a donc un container sous Debian 10 avec PHP 7.3.11 et une base MariaDB 10.1.
L'idée est donc la suivante :
Le processus a été fait de manière itérative, je m'y suis repris à 3 ou 4 fois avant d'avoir un processus qui tienne la route.
Une fois la base de données créée, on procède à l'installation de Drupal 8.
A la date d'installation, la version est Drupal 8.8.5.
Il est maintenant fortement recommandé d'utiliser composer pour installer et mettre à jour Drupal.
Sachant que même l'installation de modules utilise composer, c'est la solution que j'ai utilisé. C'est d'ailleurs très pratique quand on refaire plusieurs fois la même installation, puisqu'une fois le fichier _composer.json _ généré, il est possible de s'en resservir.
Mon fichier comprend les modules suivants :
"repositories": [<br />
{ "type": "composer",<br />
"url": "https://packages.drupal.org/8" }<br />
],<br />
"require": {<br />
"composer/installers": "^1.2",<br />
"drupal/colorbox": "^1.4",<br />
"drupal/core-composer-scaffold": "^8.8",<br />
"drupal/core-project-message": "^8.8",<br />
"drupal/core-recommended": "^8.8",<br />
"drupal/honeypot": "^1.30",<br />
"drupal/pathauto": "^1.6",<br />
"drupal/tagclouds": "^1.0",<br />
"drupal/token": "^1.6",<br />
"drupal/xmlsitemap": "^1.0@RC",<br />
"drush/drush": "^10.2" }, On remarquera que drush est installé en même temps que Drupal.
Une fois le répertoire d'installation créé, et le fichier composer.json copié dans ce répertoire, l'installation se fait simplement :
composer install
A ce niveau, on peut déjà accéder au nouveau site (il faut auparavant avoir paramétré le virtualhost qui pointe sur le bon répertoire), entrer les paramètres de la base de données. J'ai personnellement choisi d'installer uniquement le français, car je ne vais pas gérer le multilingue.
Comme le site sera migré, on peut s'arrêter avant la configuration du site.
L'étape suivante est de préparer et lancer la migration.
vincentl
dim 19/04/2020 - 12:45
Migration Drupal 7 vers Drupal 8
Mon site perso n'est pas très complexe, ni au niveau contenu (environ 200 articles) ni au niveau modules Drupal.
La version utilisée est Drupal 7.69.
En plus des modules du "core", j'utilise des choses plutôt classiques :
Le thème est un développement custom, basé sur Adaptative Theme. Il sera à refaire.
Dans tout ça, les seuls module non portés en D8 et pour lesquels il faudra trouver une alternative sont media_colorbox et botcha.
Pour l'antispam, j'ai opté pour le module honeypot, et pour media_colorbox, le paramétrage de l'affichage pour les médias de type image va suffire.
Côté volumétrie, on a :
On utilise 2 langues : français et anglais (9 en anglais, le reste en français ou neutre).
Afin de simplifier la migration, je vais changer la langue des articles en anglais pour les assigner au français ou au neutre.
Pour les alias d'URL, même modification (on assigne tout au "All languages").
Vu la faible volumétrie, je fais cela directement via l'interface web de Drupal, ce qui me permet de m'assurer que tous les champs sont correctement mis à jour.
Suite aux tests effectués, j'ai aussi modifié le champ field_alt_text pour enlever colorbox_link du mode d'affichage.
Les différentes étapes de la migration seront détaillées dans la suite de cette série d'articles, avec les problèmes que j'ai pu rencontrer.
Vincent
dim 19/04/2020 - 12:40
Si vous développez avec drupal, vous connaissez peut-être les fonctions dump, dpm ou kint, (sinon, lisez ma rapide présentation de kint.)
Une autre fonction très pratique mais moins connue est ddm(), anciennement connue sous le nom de dd(), qui permet de dumper les paramètres dans un fichier, au lieu de les afficher dans la page. Cette fonction est donc très pratique dans les cas où l’on a aucun retour d’affiché (batch, hook_update, EventSubscriber...)
Note : Cette fonction vient du module devel, le module doit donc être installé et activé pour que la fonction soit disponible.
Le paramètre passé à la fonction est dumpé dans le fichier temporary://drupal-debug.txt, ainsi, sur mon site le wrapper temporary:// est configuré dans le dossier ../files/tmp. (Note : cette configuration se fait directement dans le fichier settings.php de drupal, elle était avant dans Configuration / Médias / Système de fichier)
Image
Je peux donc afficher le contenu de ce fichier directement dans un éditeur de texte. À savoir que les tableaux et objets sont dumpé hiéarchiquement, ce qui est pratique mais qui peut rapidement alourdir ce fichier !
# Dans un de vos fichier php : ddm($variable);
Image
On peut assi ajouter des labels à ce que l'on dump pour éviter de se perdre quand on dump plusieurs variables :
function kgaut_2020_preprocess_node(array &$variables) { /** @var \Drupal\node\Entity\Node $node */ $node = $variables['elements']['#node']; ddm('------------------'); ddm($node->getType(), 'Type de noeud'); ddm($node->getTitle(), 'Titre'); ddm($node->getCreatedTime(), 'Created');...}Image
Enfin, la fonction bach tail, on peut afficher en live ce qui est dumpé, dans un terminal, sans avoir à recharger le fichier, la commande à exécuter est ci-dessous :
# Chemin à adapter en fonction de votre organisation : tail -f /vhosts/kgaut.net/files/tmp/drupal_debug.txt
Évidement, cela ne vaut pas un "vrai" debuger comme xdebug ou autre, mais c'est mieux que rien !
Une nouvelle section sur le site pour vous partager une petite revue de presse du monde drupal afin d'occuper votre week-end confiné avec un peu de lecture en français et en anglais.
L'assemblée générale de l'association avait lieu il y a quelques jours, découvrez la composition du bureau : https://www.drupal.fr/articles/2020/decouvrez-bureau-2020-lassociation-drupal-france-francophonie.
Après les Drupal Dev Days (repoussés à une date inconnue encore), c'est au tour de la DrupalCon de Barcelone d'être déplacée du 8 au 11 décembre 2020 au lieu des 14 au 17 septembre 2020. Plus d'informations en anglais : https://events.drupal.org/barcelona2020/covid-19-public-health-info.
Extrait du livre Drupal 8 Module Development, en anglais : https://www.webomelette.com/automated-testing-drupal-8.
Toujours sur les tests unitaires : une présentation de Fabien Clément sur phpunit et Drupal 8 (français) : https://www.lequipe.tech/blog/les-tests-sous-drupal-8-phpunit.
Toutes les explications pour créer un thème D8 en partant de 0 (anglais) : https://www.specbee.com/blogs/how-create-custom-drupal-8-theme-9-simple-steps.
La version 9 est prévu pour sortir le 3 juin 2020, cette semaine est sorti la seconde version beta pour préparer la version finale.
Découvrez l'annonce de sortie de la beta2 : https://www.drupal.org/project/drupal/releases/9.0.0-beta2.
Le portail officiel contenant toutes les informations concernant Drupal 9 (anglais) : https://www.drupal.org/docs/9.
Le point sur les nouveautés de Drupal 9 (français) : https://bluedrop.fr/content/chemin-vers-drupal-9-migration-drupal-8-drupal-7.
Découvrez comment tester Drupal 9 avec composer (français) : https://kgaut.net/snippets/2020/installer-et-tester-drupal-9-avec-composer.html.
Programme de test de migration de Drupal 8 vers Drupal 9 (anglais) : https://www.drupal.org/blog/get-involved-participate-in-the-beta-test-process-for-drupal-9.
Une checklist pour ne rien oublier (anglais) : https://www.axelerant.com/resources/team-blog/qa-checklist-editorial-workflow-moderation.
Le versionnement sémantique arrive avec Drupal 8.8.3, en lieu et place des 8.x-2.0, les versions seront maintenant numérotées 2.0.0. Découvrez ce que cela veut dire pour vos modules et comment faire la transition : en français : https://kgaut.net/blog/2020/drupal-9-modules-et-versionnement-semantique.html et en anglais : https://www.drupal.org/node/1015226#semver-transition.
Et vous, qu'avez-vous lu cette semaine ? Partagez-vos liens en commentaire ci-dessous !
L'assemblée générale de l'association a eu lieu le 12 mars 2020 et vous étiez nombreux en présentiel ou à distance, merci de votre implication !
Retrouvez le support de la présentation.
Le nouveau bureau élu :
Avec l'arrivée prévue le 3 juin 2020 de drupal 9, il n'y a pas besoin de créer une branche 9.x-1.x spécifiquement pour drupal 9, vous pouvez facilement indiquer que votre module est compatible avec cette nouvelle version en ajoutant dans votre fichier mon_module.info.yml la clé suivante :
core_version_requirement: ^8 || ^9
La clé core est à conserver pour garder la compatibilité avec les versions inférieures à drupal 8.7.7 (oui c'est d'un pratique...) Exemple dans un de mes modules.
En outre, il en sera bientôt terminé des versions de module "8.x-1.0", le versionnement sémantique est adopté et est compatible à partir de drupal 8.8.3, C'est à dire que les nouvelles branches de vos projets seront nommées 2.x (au lieu de 8.x-2.x) et les tags (versions) pourront être sous la forme :
2.0.0-beta1
2.0.0
2.0.1
2.1.0
Si vous passez au versionnement sémantique, les numéros de versions doivent être incrémentés, ainsi, si actuellement vous avez actuellement une branche 8.x-2.x, conservez là pour toutes les versions de drupal inférieures à 8.8.3, mais vous pouvez dès maintenant créer une branche 3.x pour la compatibilité avec les versions 8.8.3+ et 9.0.0 de drupal.
Il est possible de spécifier qu'une branche ne sera compatible qu'avec drupal 9 dans le fichier info.yml :
core_version_requirement: ^9
Plus d'informations sur le versionnement sémantique
Plus d'informations sur les changements du fichier mon_module.info.yml
tl;dr
Si vous avez un module avec une branche 8.x-2.x :
Votre module est compatible avec drupal 9 : vous pouvez ajouter la clé "core_version_requirement: ^8 || ^9" à votre module.info.yaml (c'est ce que j'ai fais pour mon mini module popin : https://www.drupal.org/project/popin. Vous pourrez passer au versionnement sémantique pour la prochaine version majeure de votre module
Votre module nécessite de plus gros travaux pour être rendu compatible, vous pouvez garder la branche 8.x-2.x pour drupal 8 et démarrer une branche 3.x qui sera une branche de travail pour drupal 9.
Dans cette exemple, j'ai un champ (field_communiques_texte_wysiwig) qui a été créée en text brut long mais qui doit être migré en wysiwig avec son contenu
Il peut être parfois utile de vouloir relancer un hook_update_n, pour ce faire vous pouvez utiliser cette commande drush. Dans cette exemple, je veux rejouer le hook my_paragraph_update_8001
drush ev "drupal_set_installed_schema_version('my_paragraph', '8000');" ; drush updb
La première version beta de Drupal 9 est sortie il y a quelques jours, et la version stable est prévue pour le 3 juin.
Si vous souhaitez tester dès aujourd'hui et par exemple vérifier si vos modules sont compatibles, voici comment installer la première beta avec composer :
Dans le dossier où vous souhaitez installer drupal :
composer create-project drupal/recommended-project:9.0.0-beta1 ./
Ensuite configurez votre serveur web pour pointer sur le dossier web et c'est parti :
Image
Apidae tourisme est un « réseau d'informations touristiques » qui permet aux offices du tourisme, mairies... De créer des « lieux » (restaurants, hôtels...) ainsi que des évènements sur des cartes de manière collaborative.
Dans le cadre d'un ancien projet, j'avais du développer une intégration avec l'API de ce service et un site drupal. J'avais à l'époque développé ce module sur github afin de peut-être un jour le mettre à disposition de tous. Un drupalistos m'a signalé récèment qu'il était listé sur la page des intégrations disponible sur la doc développeur d'Apidae.
Rebelote pour un projet que je vais attaquer, du coup j'ai pris un peu de temps pour packager le module que j'avais développé à l'époque, le nettoyer un peu afin de le publier sur drupal.org. C'est chose faite aujourd'hui !
Le module permet à intervalle régulier de synchroniser les données venant d'Apidae et de créer / mettre à jours des nœuds en récupérant différents champs (noms, description, médias, téléphone, coordonnés GPS...)
Le module gère le multi-langue et on peut ainsi récupérer des traductions des fiches et générer des traductions des nœuds.
Actuellement seulement certains champs sont mappés, mais je compte rendre ça administrable dans un futur proche.
Je suis preneur de suggestions et n'hésitez-pas à me contacter si vous souhaitez de l'aide ou des informations dans sa mise en œuvre.
La page du module sur drupal.org : https://www.drupal.org/project/apidae_tourisme
Vous souhaitez participer à la Drupal Con ? Retrouvez toutes les informations nécessaires et le programme dans notre article.
Voici le premier article du nouveau format mis en place sur ce site. C'est un format de type Quickie où je vais parler, démontrer, résoudre une problématique d'un cas réel.
Dans ce premier exemple nous allons voir comment altérer une route existante, d'un module contrib ou du cœur pour changer l'url, la callback, les permissions ...
Les contextual filters ou filtres contextuels sont une fonctionnalité très utile du module views de drupal : il permettent, comme le nom l'indique de filtrer les éléments affichés en fonction d'un paramètre contextuel (lié à un nœud, à l'internaute, un paramètre GET...).
Certains sont fournis de base avec drupal mais ils ne conviennent pas forcement à tous les cas d'utilisation.
Dans le cas présent, le but est de filtrer des nœuds en fonction de la localité de l'utilisateur (techniquement un terme de taxonomie) afin que l'utilisateur ne visualise que les nœuds qui concerne sa commune. Les nœuds ont un champ « référence à un terme de taxonomie » multiple, même chose pour l'utilisateur mais simple pour lui. Donc un nœud peut concerner plusieurs communes alors qu'un utilisateur n'appartient qu'à une seule commune.
Création du filtre contextuel :
# web/modules/custom/mon_module/src/Plugin/views/argument_default/UserLocalite.phpisAnonymous()) { return 'all'; } $user = User::load($user->id()); // getLocalitesId() est une methode personnalisée de la classe User // qui retourne l'id du terme de taxonomy de la localité return $user->getLocalitesId(); } // Ma classe implémentant CacheableDependencyInterface, on peut ainsi ajouter des paramètres // de cache, si ça n'est pas nécessaire, il suffit de supprimer l’implémentation et les deux méthodes ci-dessous. public function getCacheMaxAge() { return Cache::PERMANENT; } public function getCacheContexts() { return ['user:localite']; }}Il nous reste plus qu'à sélectionner le filtre dans la liste des filtre contextuels de drupal, en choisissant bien le champs sur lequel le filtre doit s'appliquer (dans mon cas : node.localites_cibles) :
