 Donc ça c'est une méthode pour faire une migration à partir d'un Drupal 6 à une installation de WordPress récente. Donc mon nom c'est Emmanuel Decari, je suis membre du réseau Kumbit. Donc Kumbit c'est un collectif autogéré, on favorise beaucoup les groupes progressistes. On est entre 10 et 15 personnes à peu près, c'est non-héarchique. Ça fait 10 ans qu'on existe et puis on fait du Drupal, du WordPress et puis aussi AmberJS qui est un framework pour les applications mobiles. Donc il y a des logiciels qui sont disponibles où vous pouvez importer à partir d'un Drupal 6 à un WordPress. Il y en a un que j'ai déjà essayé qui est FG Drupal to WordPress. Par contre même si vous avez une version premium, il y a souvent des limites. Donc je pense que dans ces cas-là ça peut convenir pour des sites qui sont assez simples, mais dès que vous voulez comme traiter les données entre votre première importation puis votre exportation ou importation dans WordPress, ça devient assez difficile. On n'a pas nécessairement le contrôle sur les post-tip et les custom post-tip de destination. Le HTML, souvent comme c'est dans un Drupal 6, c'est probablement que les gens l'utilisent depuis longtemps. Le HTML est souvent à nettoyer. Il y a des balises de Word, ça peut être dans un encodage comme ISO 859 ou Windows, enfin. Et aussi dans Drupal parfois, vous allez avoir un champ qui va être lié à un autre, mais lors de l'importation dans WordPress, on va avoir juste comme un numéro, une identifiant du champ qui a été lié, mais pas le contenu. Donc ça c'est une autre limite. Puis souvent il faut utiliser d'autres logiciels par la suite pour traiter les données. Donc ça peut être une solution dans des cas simples, mais dès que vous voulez faire quelque chose d'un peu sophistiqué, je peux faire ma méthode. Je ne dis pas que la méthode que je vous expose est la meilleure, mais c'en est une. Donc c'est vraiment une méthode où on va utiliser Bache sur la ligne de commande ou votre shell préféré. Ça prend une connaissance du XML, puis en particulier de expats, mais c'est pas une connaissance nécessairement très sophistiquée. Il faut simplement être capable d'adresser et faire des recherches dans un fichier XML à partir de expats. Expats, ça ressemble un peu quand on fait une recherche à une URL, c'est simplement pour retrouver une ressource dans un document qui est vraiment structuré. On va utiliser l'applicatif PHP, mais sur la ligne de commande. Descript PHP, Descript Bache, WVP-CLI, qui est, je pense, tout le monde connaît, qui est un binaire sur la ligne de commande pour pouvoir exécuter des commandes pour WordPress, et le client MySQL. Puis guide, c'est toujours comment, pour pouvoir regarder les versions de tout ce qu'on fait. Donc ça, c'est le diagramme d'une importation idéale. Ce qu'on fait au début, c'est qu'avec votre client, vous avez essayé de trouver le choix des contenus à exporter, puis vous allez lister les notes qui correspondent à chaque contenu. Donc, je ne sais pas, c'est quoi votre familiarité avec Drupal, mais dans Drupal, ce qui pourrait correspond à des posts, c'est simplement des notes et c'est des identifiants numériques. Ensuite, lors de l'importation dans WordPress, une étape intermédiaire, c'est nettoyer donc le HTML. On peut aussi manipuler les données, c'est-à-dire qu'on peut décider que, par exemple, dans Drupal, on a des auteurs, mais on a un système où les auteurs sont dans une taxonomie et on voudrait, dans WordPress, utiliser comme un logiciel, comme co-author plus, qui permet d'avoir de multiples auteurs pour juste un post. C'est là où on va manipuler cette donnée-là avant de l'importer dans WordPress. Et puis, c'est la même chose pour les logiciels, dépendant des logiciels qu'on installe. On peut vouloir utiliser ces données-là pour qu'on concorde avec les logiciels qu'on a installés. Dans WordPress, il faut penser à nos custom post types lesquels on va utiliser pour qu'elles correspondent à ceux qu'on a retenus dans Drupal. Et puis, comme je l'ai dit, les logiciels qui seront là pour la destination. Donc, c'est pas mal ce que je viens de dire. Il faut vraiment porter attention à la structure de l'ancien site, voire si on peut pas simplifier cette structure-là, parce que souvent, c'est comme le moment où la personne veut un nouveau site, mais peut-être que l'ancienne structure est pas optimale. On peut comme rendre ça optimale et puis aussi bénéficier de fonctionnalités qui existent dans WordPress, qui ne sont pas dans Drupal et vice-versa. Donc, on peut proposer des post types et des taxonomies dans WordPress. Et pour essayer de faire une analyse, le mieux, c'est de faire un tableau et voir les correspondances entre Drupal et WordPress. Donc, un tableau, donc dans un tableur, comme dans Excel ou autre, vous prenez les types de contenus qui correspondraient à un post type dans WordPress. Donc, on l'aurait comme revue. Le nombre d'entrées, combien d'entrées dans ce post type-là et les champs. Donc, il y a le nom du champ, c'est ce qui est affiché dans le site web et puis le nom machine. Et on essaie de faire correspondre ça à ce qu'on veut dans WordPress. Des fois, les correspondances sont pas directes. Comme ici, dans ce type de contenu, il y a plusieurs hauteurs. Donc, on va se servir de quarter plus pour, on va se servir de quarter plus pour ajouter plusieurs hauteurs, vu qu'on peut pas faire ça de façon native dans WordPress. On va décider, par exemple, que l'auteur de WordPress, ça va être le même. Par exemple, si c'est un collectif, l'auteur va être collectif, mais au post, il va être ajouté plusieurs hauteurs avec quarter plus. La même chose pour le numéro de revue, on peut se servir de ACF, donc c'est Advanced Costume Film, et faire un champ pour donner un numéro de revue qui sera différent de l'identifiant du post. Donc, l'idée, c'est de faire les correspondances, de pouvoir étudier ça, réfléchir. On ne voudra pas écrire des scripts quand il n'y a pas beaucoup d'éléments à importer. C'est plus facile de le faire manuellement en général. Donc, comme je disais, il faut cerner aussi la structure du site de destination, pour ajouter des taxonomies. Puis, il faut aussi décider avec la client, c'est quoi qu'on doit importer, qu'est-ce qui est vraiment nécessaire, parce que parfois, il y a des choses qui sont plus pertinentes. La même chose pour les fichiers, les images. Donc, il faut décider, si on veut tout importer, ou simplement une série de fichiers d'images pour le site de destination. Puis, il faut à peu près estimer combien d'images, puis combien de fichiers on va importer. Donc, là, on va commencer à être dense. Donc, dans Drupal 6, la façon de procéder, c'est d'installer un module qui s'appelle Node Export, qui permet d'exporter en plusieurs types de formats. Le format que j'ai choisi, c'est XML. Donc, on installe avec Drush, qui est un binaire qui ressemble à WP-CLI. C'est la même idée sur la ligne commande. Et ensuite, on active ce module. Donc, Node Export va nous permettre d'exporter au format XML les nodes qu'on a rechoisis, par type de contenu. Donc, une fois que tout est activé, on va avoir une possibilité d'exporter en XML. Et comme c'est écrit ici, JSON n'est pas compatible. En tout cas, il n'existe pas pour Drupal 6 avec Node Export. Donc, la meilleure façon pour essayer de trouver les nodes qui sont exportés par type de contenu, c'est de rentrer simplement dans le client MySQL. On peut rentrer par Drush, comme on peut le faire avec WP-CLI. Et ce qu'on veut essayer de trouver, c'est le nom machine. Donc, par exemple, ici, c'est le nom qui est affiché, c'est revu, le label, mais le nom machine, c'est revu en minuscule. Donc, une fois qu'on a trouvé ça, il faut simplement faire une requête et essayer de trouver et de lister tous les identifiants, tous les nids qui correspondent, par exemple, ici dans cet exemple, au content type revu. Donc, là, on a tout trouvé. Ce qu'on veut faire, c'est le garder dans un fichier texte. Donc, le mieux, le plus facile pour créer ce fichier texte, c'est simplement d'utiliser le client MySQL. Puis, la requête, si on le voit, c'est l'acnid. Et ce qu'on fait, c'est simplement une redirection vers un fichier texte qu'on aime ici. Et ce qu'on va avoir comme résultat, donc, c'est toutes les nodes qui correspondent au content type revu dans ce fichier texte. Ça va, je vais pas trouver. C'est bon. Donc, une fois qu'on l'a fait ça, on va exporter au format XML notre content type revu. On fait d'abord une copie de sauvegarde. Donc, ça, c'est la commande avec Drush. Et puis, une fois qu'on l'a fait, notre copie de sauvegarde, on va utiliser avec Drush une fonctionnalité qui nous permet d'exporter toutes les nodes. Là, c'est juste un exemple. Comme ici, j'exporte juste la node 7.45 dans un fichier texte ici au format XML. Donc, pour faire ça, on peut utiliser simplement un petit script bash. Je ne vous demande pas de le comprendre, mais l'idée ici, c'est qu'on part de ce qu'on avait enregistré. C'est-à-dire tous les nodes qui correspondent au content type revu. Puis, on fait une boucle dedans et on exporte ici dans un fichier texte XML. Ça fait que chaque node va avoir son propre fichier texte XML. Donc, une fois qu'on a fait le script, il suffit juste de le lancer. Et puis, bon, ça, c'est ce qui est affiché, comme je fais un output sur le terminal. Et on va créer donc un fichier revu 001.xml, revu 009.xml. Puis ça, ça correspond au nid qu'on est en train d'exporter. À la fin, on va avoir un répertoire qui va contenir, comme, 1000 ou plus, 100 fichiers XML qui correspondent donc toujours à notre content type revu. Ça, ça vous donne un peu une idée d'une node spécifique. Donc, on retrouve pas mal tout ce qu'on a besoin pour faire l'importation dans WordPress. Là, on a le net. C'est toujours commande à avoir. Si il y a quelque chose qui ne fonctionne pas. Mais comme il y a le langage, enfin, il y a beaucoup de champs ici qui sont exportés, dont le BODY ici. Puis ici, on peut voir que le BODY a été htmlisé, ce qui n'est pas nécessaire maintenant si on utilise Unicode. Donc, c'est vraiment important. Comme je l'ai dit au début, quand on exporte à partir d'une vieille installation comme un Drupal 6, le html est souvent pas au norme. Donc, le caractère accentué peut être converti. L'encodage peut être en ISO 8859 ou un paquet d'encodage différent. Puis même, à travers ce que vous allez exporter, ça peut être des encodages différents aussi. Word, c'est vraiment une plaie. On va avoir plein de trucs qui viennent de Word comme des installs, des paquettes de craps dont on n'a pas besoin. Puis ce qu'on veut, c'est faire une autre exportation avec juste le BODY pour le moment où on va importer dans WorkPress. Donc, on va extraire le BODY du fichier xml et en extraisant le BODY du fichier xml, on peut commencer à nettoyer le html. Moi, j'utilise deux librairies que j'aime bien. C'est html purifier et puis html lowered. Le premier, ça permet de, comme on va le voir, d'éliminer comme toutes les classes et puis tout le CSS qui est online. Le second, ça va être pour faire une présentation qui va être plus lisible. Ça va être plus organisé. Puis il y a toujours html tidy aussi qu'on peut utiliser. Donc, on fait un script avec une boucle qui va lire les fichiers xml. On va convertir le html en enlevant les entités. Comme je l'ai dit tout à l'heure, ça, c'est une des configurations qui permet d'enlever les classes et tout. Et puis avec html lowered, on peut comme embellir le code. On peut aussi utiliser des regex pour des trucs qui sont plus particuliers. Après, on va créer le fichier avec l'extension html. Et c'est vraiment un processus qui est assez long à faire. Parce que si c'est vraiment sur une longue période de temps puis il y a beaucoup de gens qui sont intervenus, le html risque de pas être conforme ou standard ou les gens peuvent décider d'avoir organisé les choses d'une autre manière. Ça, c'est assez long à faire. Il faut le faire. Donc, le code, ça ressemble un peu à seul. Ici, je fais une boucle dans mon répertoire xml. Ici, avec expat, j'extraie le body. Et après, je le traite avec les librairies, les fonctionnalités, je peux faire des regex, etc. Et je crée mon fichier html du body. Dans WordPress, on va créer un custom post type revu selon ce que vous avez besoin. Et puis avec le logiciel Advanced Custom Field, on va ajouter des champs particuliers pour ce custom type. Comme ici, donc, j'ai une liste de gens que j'ai créés avec ACF pour pouvoir qui vont travers à l'importation. Donc, ça, c'est un exemple d'escript, une partie d'un script PHP qui sert à l'importation. La même chose. Donc, on roule à travers notre répertoire qui contient, comme le xml du content type revu de Drupal. Et là, on va commencer à signer des valeurs. Ça, c'est assez particulier. Il faut vraiment étudier. On va le voir dans une prochaine diapositive, mais comme faire les liaisons entre les champs qui sont identifiés dans le fichier xml et les champs d'Andrupal. Ce n'est pas toujours évident parce que, comme vous pouvez voir, des fois, il y a des longs qui veulent à peu près rien dire. Donc, ça, c'est comme un petit travail de détective qu'il faut faire, mais ça se fait assez facilement dans un éditeur xml. Ça, c'est une particularité dont je vais parler avec ACF. ACF a des champs de référence et si on veut assigner des valeurs aux champs comme hauteur qu'on a créé, il faut aussi passer toujours la référence qui est liée à hauteur. Ça va toujours être la même. La même chose. Donc, on va aller chercher, par exemple, le chemin vers les fichiers PDF qu'on aura dans notre document xml. Donc, on y crée un script PHP. On fait une boucle dans notre épertoire où on a tous nos documents xml pour le content type. Et ensuite, on utilise WP-CLI à partir de notre script PHP en utilisant un système commun qui fait un appel directement au shell. La première commande qu'on utilise de WP-CLI, donc on l'a abrévié avec WP, c'est WPostCreat. Ça, c'est une commande pour créer un post et ça nous retourne le post ID qu'on va conserver dans notre script. Donc, le mieux, c'est de quand on fait une commande comme ça, qu'on va passer au shell, on va vraiment l'assembler. Moi, je trouve plus facile de rouler mon script à l'extérieur de l'installation de WordPress. Donc, on peut servir de l'argument pack pour indiquer à WP-CLI où est l'installation WordPress. Et puis, c'est là où on va passer le chemin vers le body parce qu'on va l'importer à partir du fichier. Donc, ça a l'air vraiment d'être du charabia, vous pourrez regarder ça chez vous tranquillement. Mais ça, c'est toute la commande qu'on va passer à système. Donc, il y a l'auteur, il y a le titre, il va avoir aussi le chemin vers le body. Une fois qu'on a ça, on reçoit dans post ID le numéro du post ID et on peut faire une petite vérification rapide si on a bien reçu quelque chose qui est un chiffre. Donc, je lui ai mentionné tout à l'heure, on va utiliser ACF et il y a une subtilité à comprendre, c'est que chaque champ ACF a une référence qu'il faut passer. J'ai mis une référence un peu où c'est expliqué. Donc, juste pour expliquer encore, si par exemple on a une auteur qui s'appelle Agathe, la framboise Agathe, elle va avoir un identifiant qui va toujours être le même, même si on passe par exemple dans le champ auteur, le clair Isabelle, au clair, le souligné auteur aura le même identifiant. Donc, ça, c'est important à passer. Pour trouver ces identifiants-là dans ACF, vous simplement faire une petite requête SQL et vous allez voir tous les identifiants qui correspondent à vos champs ACF. Donc, ici, c'est la même chose. Donc, on va chercher la valeur de hauteur, on passe ce qu'on a trouvé comme référence, la même chose pour numéro. On assemble la commande et puis après, on fait simplement une boucle dans cet array et on utilise le système pour ajouter donc ces champs ACF. Pour ajouter des fichiers liés à notre post-ID, on utilise W Media Import. Donc, c'est la même chose. On a été chercher la référence, le chemin vers le fichier dans notre fichier XML et puis on passe la commande directement au shell via le script PHP. Il faut vraiment regarder de façon assez poussée ce que vous avez dans le Drupal, ce que vous voulez importer, les champs, les longs machines. C'est vraiment bien d'avoir un bon éditeur XML. Il y en a un en code libre, XML Copy Editor. Moi, celui que je préfère, c'est exigène parce que je préfère des requêtes expats sur l'ensemble de fichiers XML dans un répertoire. Ça, c'est écrit en Java. Quand vous faites vos importations, vous risquez de faire souvent la même importation pour le même content type. Comme a revu un moment donné, vous allez vous apercevoir que c'est pas bon ou vous allez montrer à votre client et puis elle va dire oui mais je voudrais avoir cette telle chante ou telle chante en trop et tout. Fait que toujours faire une sauvegarde de la BD et puis aussi essayer de faire votre sauvegarde de la BD avant toute importation juste pour avoir comme le WordPress Vierge avec les champs ACF et tout pour avoir commencé à les faire à chaque fois. Plus après, vous pouvez faire votre importation. J'utilise beaucoup comme vous avez peut-être vu dans le code ECO et puis des logs parce que ça permet de trouver facilement les erreurs ou d'arrêter le processus. Quand vous avez 10 000 éléments à importer, vous voulez voir où ça coincé parce que des fois ça peut planter pour une virule ou une crotte quelque part. Essayez de faire un type de contenu à la fois, pas comme faire le mega script qui va tout importer d'un coup. C'est mieux de vraiment y aller une à la fois et puis de mettre ça dans votre guide pour pouvoir revenir s'il y a des changements à faire. Ça vaut vraiment la peine de prendre le temps pour nettoyer le HTML comme probablement vous n'aurez pas besoin de aucun CSS inline ou ce genre de choses-là parce que vous allez le faire par la suite dans WordPress. Et puis, le signe de sa geste c'est que vraiment les importations ont toujours des surprises, c'est toujours d'oublier les heures, sérieux d'être plus long de ce que vous voulez. Donc voilà, on a un peu de temps pour les questions s'il y en a. Ok, moi je suis parti d'une première importation, que j'avais fait à partir d'un système de gestion de contenu qui s'appelle Alfresco. C'est quelque chose que on a fait pour la CSN, Cumbit. Donc c'est un peu comme un genre de pattern que j'ai fini par mettre au point mais c'est long, c'est assez long. Une fois qu'on a comme la structure, ça va plus rapidement importer les types de contenu, mais chaque type de contenu des fois a des particularités et il faut jouer avec et tout. Comme je disais au début, c'est limité souvent ces plugins-là. Probablement que parfois vous avez des valeurs ou des champs que vous voulez à un autre endroit dans WordPress, vous voulez pouvoir nettoyer facilement le HTML avant qu'ils soient importés. Ça permet... Je ne dis pas que cette technique-là est bonne pour toutes les importations dans WordPress, mais avec les plugins, j'ai trouvé qu'elle avait vraiment des limitations et ça, ça me permettait de faire une importation beaucoup plus fine. Bon, tout le monde est bouché. Ok, merci bien. Gros merci aussi à tous les bénévoles qui ont permis de le faire.