Un éditeur de contenus touristiques francophone et anglophone a vu son site Polylang, initialement conçu pour deux langues, croître au fil des ans jusqu’à devenir difficile à administrer : plus de 12 000 articles cumulés, 45 Go de médias partagés sans distinction claire par langue dans la bibliothèque, et surtout deux équipes éditoriales distinctes (l’une française, l’autre anglophone basée à Dublin) qui se marchaient régulièrement sur les pieds dans un back-office commun non séparé. La décision a été prise de basculer vers un réseau WordPress multisite, un site distinct par langue, plutôt que de continuer à faire cohabiter tout le monde dans une seule installation Polylang.
Cet article ne revient pas sur MultilingualPress, solution alternative pensée nativement pour ce type d’architecture multisite et déjà traitée par ailleurs, mais détaille la méthode de migration technique retenue pour faire évoluer un site Polylang existant vers cette nouvelle structure, sans reconstruire le site de zéro.
Pourquoi Polylang ne suffisait plus
Polylang gère très bien la traduction dans une installation unique tant que le volume de contenu et le nombre de contributeurs restent modérés. Passé un certain seuil, deux limites structurelles sont apparues sur ce projet : l’absence de séparation des rôles et permissions par langue (un rédacteur anglophone voyait l’intégralité des 12 000 articles français dans ses listes d’administration, sans filtre natif satisfaisant), et une bibliothèque de médias unique où retrouver une image spécifique à la version anglaise devenait fastidieux, aucune convention de nommage n’ayant été imposée dès le début du projet plusieurs années auparavant.
Étape 1 : activer le mode multisite
La première étape technique a consisté à activer le mode réseau de WordPress sur une copie de staging du site, via l’ajout de la constante dans wp-config.php puis la configuration réseau standard :
define( 'WP_ALLOW_MULTISITE', true );Une fois le réseau initialisé via Outils → Créer un réseau, deux nouveaux sites ont été créés au sein du réseau : fr.exemple-staging.com comme site principal, et en.exemple-staging.com comme second site, chacun destiné à héberger uniquement le contenu de sa langue respective.
Étape 2 : répartir le contenu existant
Le contenu du site Polylang d’origine, avec ses relations de traduction stockées dans les tables wp_term_relationships associées à la taxonomie interne language de Polylang, a été exporté séparément par langue via un script s’appuyant sur la fonction native pll_get_post_language() pour filtrer chaque article selon sa langue avant export :
$articles_fr = get_posts( array(
'post_type' => 'post',
'posts_per_page' => -1,
'lang' => 'fr',
) );
foreach ( $articles_fr as $article ) {
// Export vers un fichier WXR filtré, un par langue
}Chaque export WXR filtré a ensuite été importé dans le site correspondant du nouveau réseau via l’outil natif d’import de contenu WordPress, en conservant les identifiants d’auteur pour ne pas perdre l’attribution éditoriale des dix dernières années de publication.
Étape 3 : répartir les 45 Go de médias
La répartition des médias a représenté la partie la plus longue de la migration. Faute de convention de nommage permettant de déduire automatiquement la langue d’une image à partir de son nom de fichier, chaque média a été rattaché à sa langue en croisant les tables wp_posts (type attachment) avec les articles qui les référençaient réellement dans leur contenu, via une recherche du champ guid dans le corps des articles déjà répartis à l’étape précédente. Les médias sans référence retrouvée dans aucun article (environ 6 Go sur les 45 Go initiaux) ont été dupliqués dans les deux sites plutôt que supprimés, par précaution, en attendant une vérification manuelle ultérieure par les équipes éditoriales elles-mêmes.
Étape 4 : relier les deux sites pour le sélecteur de langue
Sans plugin dédié comme MultilingualPress, la relation entre un article français et sa traduction anglaise n’existe plus nativement une fois les deux sites séparés dans le réseau. Une table de correspondance personnalisée a été créée, stockant l’ancien identifiant de traduction Polylang en regard du nouvel identifiant de post dans chacun des deux sites, permettant de reconstruire un sélecteur de langue fonctionnel malgré l’absence de plugin de liaison multisite :
CREATE TABLE wp_correspondance_traductions (
ancien_trid INT,
site_id INT,
post_id BIGINT,
langue VARCHAR(5)
);Étape 5 : migrer langue par langue, pas en une seule bascule
Plutôt qu’une bascule globale un jour donné, la migration s’est faite en deux temps espacés de trois semaines : la version anglaise en premier, moins fréquentée et donc moins risquée en cas de problème, puis la version française une fois la méthode validée sur le premier site. Cette approche progressive a permis de corriger, sur la version anglaise, plusieurs problèmes de redirection avant de les reproduire sur la version française, bien plus fréquentée et donc plus sensible à toute erreur de bascule.
Sur une migration structurelle de cette ampleur, migrer une langue à la fois coûte plus cher en temps de coordination qu’une bascule unique, mais réduit considérablement le risque d’une panne touchant l’intégralité du trafic du site en une seule fois.
En résumé
Cette migration a représenté près de six semaines de travail technique, très supérieur à ce qu’une simple mise à jour de plugin aurait demandé, mais elle a résolu durablement les deux limites structurelles de Polylang identifiées au départ : séparation claire des rôles éditoriaux par équipe, et bibliothèque de médias enfin organisée par langue. Le principal enseignement de ce projet, à documenter pour toute agence envisageant une migration comparable, est l’importance de traiter la répartition des médias comme une étape à part entière du projet, et non comme un simple détail technique annexe à la migration du contenu textuel.
