Comment rationaliser les migrations multisites WordPress avec MU-Migration

Migrer un site WordPress autonome vers un environnement de réseau de sites (ou « multisite ») est une entreprise fastidieuse et délicate, l'inverse est également vrai. L'importateur WordPress fonctionne raisonnablement bien pour les sites plus petits et plus simples, mais laisse place à l'amélioration. Il exporte le contenu, mais pas les données de configuration du site telles que les configurations Widget et Customizer, les plugins et les paramètres du site. L'importateur a également du mal à gérer une grande quantité de contenu. Dans cet article, vous apprendrez à rationaliser ce type de migration en utilisant MU-Migration, un plugin WP-CLI.

Comprendre le multisite

Un multisite WordPress vous permet d'exécuter plusieurs sites Web au sein de la même installation WordPress. Il est souvent appelé « réseau multisite ». WordPress.com est probablement le plus grand exemple de réseau multisite, exécutant des milliers de sites dans la même instance WordPress.

Un multisite WordPress peut être parfaitement adapté à plusieurs cas d'utilisation, dont certains incluent :

• Votre client peut avoir plusieurs propriétés, et il peut être judicieux de regrouper tous ses sites dans une installation WordPress unique, partageant un seul domaine, mais sans s'y limiter.

• Une fois que vous l'avez configuré, il s'agit d'un processus simple et direct pour créer de nouveaux sites et tirer parti des thèmes et des plugins déjà disponibles sur le réseau.

Une compréhension approfondie du fonctionnement du multisite dépasse le cadre de cet article, mais vous pouvez consulter les liens suivants :

• "Créer un réseau", Codex, WordPress.org

• "WordPress Multisite : Fonctions et méthodes pratiques", Kevin Leary, Smashing Magazine

Comprendre les défis

Les différences entre la structure d'un site unique et d'un multisite WordPress sont tout à fait raisonnables. Avec le multisite, chaque sous-site obtient son propre ensemble de tables de base de données, à l'exception de la table de l'utilisateur ( wp_user ) qui est partagée entre tous les sites. La façon dont cela fonctionne dans WordPress est que chaque ensemble de tables de sous-site a l'ID du site ajouté à chaque nom de table ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Cette structure de base de données elle-même introduit déjà certaines complexités. Par exemple, comment migreriez-vous un sous-site multisite vers une installation unique ? Évidemment, vous ne pouvez pas simplement exporter et importer la base de données dans une seule installation — les noms de table sont différents ! Vous devrez soit renommer les tables dans le fichier .sql exporté, soit utiliser une requête ALTER TABLE SQL pour renommer les tables après les avoir importées. Il en va de même pour l'inverse : si vous importez un seul site en multisite, les préfixes des tables devront également être mis à jour. Cela ressemble à trop de travail, non ?

La table de l'utilisateur dans le multisite est globale, ce qui signifie que vous ne pouvez pas simplement importer la table de l'utilisateur à partir de votre site unique car elle remplacerait complètement la table de l'utilisateur global multisite. Si vous faites l'inverse, en extrayant un sous-site de WordPress et en l'important dans un seul site, vous reporterez tous les utilisateurs du réseau, même ceux qui n'appartiennent pas au sous-site en cours de migration. De plus, si vous migrez un sous-site d'un multisite à un autre, l'exportation de la table de l'utilisateur est complètement hors de propos.

La meilleure solution consiste à exporter les utilisateurs séparément, mais cela introduit un autre problème : lorsque les utilisateurs sont importés, ils obtiennent des ID différents. Pour résoudre ce problème, il est nécessaire de garder une trace des identifiants des nouveaux utilisateurs, de créer une table de mappage et d'utiliser la table de mappage pour mettre à jour toutes les références aux identifiants des utilisateurs dans WordPress ! Encore une fois, trop de travail, non ?

Ce ne sont là que deux exemples des défis auxquels on peut être confronté face à des migrations comme celle-ci. Il y a un tas d'autres choses mineures qui doivent également être prises en charge, comme déplacer le dossier de téléchargement vers l'emplacement approprié, migrer les enregistrements dans la base de données qui référencent l'ID du site, etc.

Rencontrez MU-Migration

MU-Migration est un plugin WP-CLI que j'ai créé en travaillant sur plusieurs migrations de clients et plus tard open-source par 10up. Il a été conçu pour rationaliser le processus de déplacement de sites de sites WordPress uniques vers une instance multisite (ou vice-versa). Il exporte essentiellement tout dans un package ZIP qui peut ensuite être utilisé pour importer le site dans l'installation WordPress souhaitée.

Cela fonctionne en exportant le contenu du site et éventuellement le thème, les plugins et les dossiers de téléchargement dans un package zip qui peut être facilement importé dans une autre installation WordPress. Lorsque vous utilisez MU-Migration, vous n'avez pas à vous soucier des détails techniques sous-jacents de la migration. Il s'occupera simplement de tout cela pour vous afin que vous puissiez vous concentrer sur ce qui est important : fournir une migration réussie à vos clients.

Installation de WP-CLI et MU-Migration

Pour utiliser MU-Migration, vous devez d'abord installer WP-CLI, l'outil de ligne de commande officiel de WordPress. L'installation de WP-CLI est aussi simple que d'exécuter les commandes ci-dessous sur votre serveur :

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

Après avoir exécuté ces étapes, vous pourrez exécuter WP-CLI en tapant simplement wp à partir de n'importe quelle installation WordPress, tant que vous êtes dans le répertoire racine de WordPress.

Par exemple, sur votre dossier d'installation WordPress, essayez d'exécuter la commande suivante :

 $ wp theme status

Il s'agit d'une simple commande qui répertorie tous les thèmes disponibles, en mettant en évidence celui qui est actuellement actif.

Enfin, pour installer MU-Migration, vous pouvez utiliser la commande package install . Utilisez la commande suivante pour télécharger et installer MU-Migration en tant que plug-in WP-CLI.

 $ wp package install 10up/mu-migration

Exécution d'une migration simple

L'utilisation de MU-Migration est assez simple. Pour notre premier scénario, nous allons déplacer un seul site WordPress vers une installation WordPress multisite.

Exporter le site unique

Nous allons commencer par exporter le site unique. Pour ce faire, nous devons utiliser la commande export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

La commande ci-dessus exportera l'ensemble du site dans un package ZIP, les drapeaux --themes , --plugins et --uploads sont facultatifs et incluront le thème actuel, tous les plugins et le dossier de téléchargements, respectivement, dans l'exportation. Selon la taille de votre site, le processus peut prendre un certain temps, mais pour la plupart des sites, le processus d'exportation ne devrait pas prendre plus de quelques minutes.

Une fois terminé, il créera un fichier appelé single-site.zip contenant toutes les données, thèmes et plugins du site ainsi que le répertoire des téléchargements. L'étape suivante consiste à le déplacer vers le serveur où vit le multisite WordPress. Vous pouvez utiliser votre client SFTP préféré ou une solution plus robuste comme rsync .

Importation du site unique dans le multisite

Avec le fichier exporté dans votre serveur multisite, il vous suffit d'utiliser la commande d'importation depuis le répertoire multisite de WordPress ; Inutile de dire que WP-CLI et MU-Migration doivent également être installés sur le serveur de destination.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

La commande ci-dessus va prendre le fichier single-site.zip , l'extraire et tout importer dans le multisite. Cela créera un nouveau sous-site dans votre réseau. Le paramètre --new_url est facultatif ; il demandera à MU-Migration d'effectuer une recherche et de remplacer afin de remplacer toutes les occurrences de l'URL du site exporté par celle spécifiée. Ce paramètre est pratique lorsque la migration inclut un changement d'URL ou si vous importez localement, ou même dans un environnement intermédiaire.

Le processus d'importation prend généralement plus de temps et dépend de la taille du site que vous importez, mais n'ayez crainte, MU-Migration vous tiendra au courant au fur et à mesure de l'exécution de la migration. Une fois le processus terminé, MU-Migration vous informera de l'URL finale de votre site importé. Il est fortement recommandé de vider toutes les couches de cache qui s'exécutent sur votre serveur, en particulier Memcache ou Redis.

Réexécuter une migration

Lors des migrations, il est assez courant de faire d'abord un essai à blanc dans le but de tester les choses avant d'exécuter la migration finale, ce qui signifie généralement prendre une autre exportation et réimporter dans l'installation multisite de destination. Cependant, notez que dans notre premier exemple de migration, MU-Migration a créé un nouveau sous-site au sein du réseau afin d'importer le site unique par-dessus. Exécuter à nouveau exactement la même commande conduirait à la création d'un autre sous-site, ce qui n'est pas exactement ce à quoi nous nous attendions.

Heureusement, il est possible de spécifier un blog_id , qui indique à MU-Migration de remplacer le sous-site par le blog_id spécifié. Par exemple, supposons que la commande d'importation précédente a créé un sous-site avec 2 comme ID et que vous souhaitez réexécuter la migration. Vous pourriez faire ce qui suit :

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

Si vous ne connaissez pas le blog_id , vous pouvez l'obtenir via les paramètres d'administration réseau ou en exécutant $ wp site list .

Extraction d'un sous-site à partir d'une installation multisite

MU-Migration prend également en charge l'extraction de sous-sites à partir d'installations multisites et leur importation soit dans un autre multisite, soit dans un seul site.

Pour ces deux scénarios, nous exécuterions la commande d'exportation à partir d'une installation multisite et non à partir d'un seul site ; cela signifie que nous avons besoin d'un moyen de spécifier quel sous-site nous voulons exporter. Pour ce faire, il suffit de passer le paramètre --blog_id à la commande export :

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

Dans cet exemple, nous exportons un sous-site avec un ID égal à 3 ; cela créera un fichier ZIP prêt à être importé dans un autre multisite ou dans un seul site. La commande pour importer dans un site unique et multisite est exactement la même, MU-Migration détectera s'il fonctionne sur multisite ou non et s'y adaptera automatiquement. En passant, lors de l'importation dans une autre instance multisite, vous pouvez également spécifier le paramètre --blog_id pour remplacer un sous-site existant.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Conseils pour exécuter de grandes migrations

Bien que les exemples précédents fonctionnent très bien pour les migrations de petite à moyenne taille, la migration de sites volumineux vers ou depuis plusieurs sites peut prendre un temps raisonnable. Dans cette section, je partagerai quelques leçons apprises lors de plusieurs migrations de type entreprise.

Créer un plan de migration

Les migrations de données sont souvent nécessaires, mais c'est une partie négligée de nombreux projets. Les migrations peuvent être lourdes et complexes, mais lorsqu'elles sont planifiées de manière appropriée, elles peuvent être indolores. La création d'un plan de migration doit être la première étape de tout projet de migration.

Un plan de migration typique comprend des éléments tels que :

• L'impact de la migration sur tous les processus éditoriaux de production (c.-à-d. gels de contenu, exigences de migration différentielles).

• Quelle est la durée prévue de la migration ?

• Comment les sauvegardes seront-elles restaurées ? Comment une migration ratée sera-t-elle gérée ?

• Comment le processus d'exportation affectera-t-il les performances du site ? De nombreux sites ne peuvent pas se permettre une exportation de base de données pendant les heures de pointe.

En règle générale, les migrations doivent être aussi transparentes que possible et, idéalement, le jour du lancement, tout le gros du travail aurait déjà été effectué et seules les étapes strictement nécessaires devraient être effectuées. Cela signifie que vous devez migrer tout ce que vous pouvez avant la date de lancement réelle, car cela vous laissera de la place pour corriger les erreurs et effectuer le contrôle qualité. S'il s'agit d'une nouvelle construction de site et que vous migrez des données, vous pouvez souvent bénéficier d'une fenêtre de gel du contenu et faire déplacer votre contenu à l'avance. Vous pouvez également utiliser des stratégies pour déplacer progressivement votre contenu si possible. Consultez la section suivante pour un exemple de cette technique.

Bien que souvent négligé, un plan de migration approprié peut éviter une grande variété de problèmes lors d'une migration. Ne laissez pas des circonstances imprévues faire échouer votre migration, planifiez à l'avance ! Pour une discussion plus approfondie sur la planification d'une migration, je vous encourage à consulter la section migration des meilleures pratiques de 10up.

Utilisez Rsync pour copier progressivement les téléchargements

Le dossier de téléchargement des grands sites peut être extrêmement volumineux, et le compresser dans un fichier ZIP pour une extraction ultérieure n'est pas toujours la solution la meilleure et la plus rapide. Il existe plusieurs autres façons de copier le dossier de téléchargement sur le serveur de destination. Un outil couramment utilisé pour la migration de type entreprise est rsync , qui peut transférer des fichiers entre serveurs plus rapidement qu'avec une solution SFTP standard, et en plus, il peut suspendre et restaurer les transferts. Il garde une trace de ce qui a déjà été transféré, ce qui signifie que nous pouvons progressivement synchroniser nos fichiers. Par exemple, vous pouvez commencer à synchroniser les fichiers quelques jours avant la migration proprement dite pour gagner du temps. Ensuite, le jour de la migration, il vous suffit de synchroniser les fichiers pour vous assurer que tout ce qui a été ajouté depuis la dernière synchronisation est transféré sur le serveur de destination.

La seule mise en garde de cette approche est que vous devrez déplacer manuellement les sous-répertoires des téléchargements au bon endroit car le multisite a une structure légèrement différente pour le dossier des téléchargements : chaque site obtient son propre sous-dossier où son nom est l'ID du site .

Comme dernier exemple, voyons comment nous pourrions migrer un grand site unique vers une instance multisite. Nous allons commencer par exporter le site unique dans un package ZIP et exécuter un test de simulation sur le serveur de destination. À ce stade, le site ne serait accessible à personne puisque le domaine pointe toujours vers l'ancien serveur, ce qui signifie que vous pouvez pointer en toute sécurité le fichier de votre hébergeur vers le nouveau serveur afin de tester la migration. Vous pouvez également activer un plugin comme Restreindre l'accès au site sur le site de destination pour vous assurer qu'il n'est en aucun cas accessible au public.

Pour notre test de simulation, nous exportons le site quelques jours ou semaines avant la date de migration prévue pour tester et avoir une idée de la durée du processus. Notez que le dossier de téléchargement n'est pas inclus.

Faites d'abord un essai à sec

Faites toujours un essai à sec en premier. Idéalement, un essai à blanc devrait avoir lieu sur le serveur réel ou dans un environnement intermédiaire avec une pile de serveurs similaire.

Envisagez d'utiliser l' --mysql-single-transaction

La commande d'importation prend également en charge un --mysql-single-transaction qui encapsulera l'exportation SQL dans une seule transaction pour valider toutes les modifications de l'importation à la fois, empêchant l'écriture de submerger le serveur de base de données, en particulier dans les environnements MySQL en cluster.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

Avec rsync , nous pouvons facilement transférer le fichier exporté généré :

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

Ensuite, nous exécutons la commande d'importation sur le serveur de destination :

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

Maintenant, nous devons savoir quel est le blog_id du sous-site nouvellement créé ; nous pouvons obtenir cette information en exécutant:

D'après la sortie de la commande ci-dessus, nous savons que notre site a été importé avec l'ID 2. Nous en aurons besoin pour déplacer correctement le dossier de téléchargement à l'aide de rsync . À partir du serveur de site unique, nous exécuterions ce qui suit :

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

La commande ci-dessus copiera l'intégralité du dossier de téléchargement au bon endroit sur une installation multisite, qui se trouve sous le dossier sites et dans un dossier où son nom est simplement l'ID du site (dans ce cas, 2). À ce stade, nous pouvons maintenant modifier le fichier de l'hôte pour faire pointer le domaine de site unique vers le serveur multisite ; Ensuite, nous pouvons effectuer des tests pour nous assurer que la migration a fonctionné comme prévu.

Pour la migration finale, tout serait pareil, à l'exception que nous --blog_id=2 à la commande d'importation :

 $ wp mu-migration import all site.zip --blog_id=2

Et comme avantage, la synchronisation des téléchargements se produira beaucoup plus rapidement puisque rsync ne transférera que les fichiers qui ont été modifiés ou ajoutés depuis la dernière synchronisation.

Conclusion

La migration vers ou depuis plusieurs sites est difficile et l'outil présenté dans cet article simplifie l'ensemble du processus de migration en réduisant l'effort à quelques commandes CLI. MU-Migration est activement utilisé en production depuis plus d'un an et est un projet entièrement open source. Le plugin est développé sur Github et les pull requests sont les bienvenues !