wp search-replace 'https://www.exemple.fr' 'https://staging.exemple.fr' --skip-columns=guid se termine sans erreur, annonce des remplacements dans plusieurs tables, et pourtant les pages Elementor de la préproduction continuent de charger des images d’arrière-plan depuis la production. Ce n’est pas un défaut de WP-CLI : c’est la façon dont Elementor stocke ses données. Ce troisième épisode de la série « Livrer un site Elementor en agence » monte une préproduction propre, explique pourquoi le remplacement d’adresses demande deux passes, et fixe le sens dans lequel le site circule entre local, préproduction et production. La bascule du jour J, elle, fera l’objet du septième épisode.
Trois environnements, un sens de circulation
La règle qui évite la plupart des accidents tient en une phrase : le code et la mise en page montent, les contenus descendent. Le thème enfant, les extensions, les gabarits et le design system partent du poste local, passent par la préproduction et arrivent en production. Les contenus réels, les comptes, les soumissions de formulaires et les commandes naissent en production et ne font que descendre, par copie, vers la préproduction et le poste local.
La conséquence est directe : une fois le site en ligne, on ne pousse plus jamais une base de données complète de la préproduction vers la production. Entre la copie et la remontée, la production a vécu ; écraser sa base efface tout ce qui s’y est passé. Avant la première mise en ligne, la question ne se pose pas encore, puisque la production n’existe pas : c’est précisément le sujet du septième épisode.
La préproduction a donc deux usages bien distincts : valider une évolution sur une copie fidèle de la production, et faire valider le client sans exposer un chantier au public. Les deux exigent qu’elle soit régulièrement rafraîchie depuis la production.
Monter la préproduction : domaine, licence et discrétion
Le choix du nom de domaine n’est pas cosmétique. La page d’aide d’Elementor sur l’activation de licence sur les sites de préproduction rappelle que chaque installation demande normalement une activation, sauf pour une liste de domaines reconnus. Y figurent notamment les sous-domaines dev.*, local.*, test.*, staging.*, stage.* et staging suivi d’un chiffre, les extensions .dev, .local, .test et .lh pour le poste local, ainsi que les domaines de préproduction de plusieurs hébergeurs. Le nom doit correspondre exactement à l’un de ces formats. staging.exemple.fr ne consomme donc pas d’activation ; preprod.exemple.fr, si.
Une préproduction doit ensuite rester invisible. Trois mesures, de la plus faible à la plus sûre :
- Le réglage de visibilité de WordPress, c’est-à-dire l’option
blog_publicà 0. Utile, mais ce n’est qu’une demande adressée aux moteurs, et elle est écrasée à chaque copie de la base de production. - Le type d’environnement, déclaré dans
wp-config.phpavecdefine( 'WP_ENVIRONMENT_TYPE', 'staging' );, qui permet au code de savoir où il tourne. - Une authentification HTTP sur tout le sous-domaine. C’est la seule mesure qui empêche réellement l’indexation et les visites accidentelles.
Sur un serveur Apache, l’authentification tient en quatre lignes dans le .htaccess de la préproduction, le fichier de mots de passe étant créé avec l’utilitaire htpasswd hors de la racine web :
AuthType Basic
AuthName "Preproduction"
AuthUserFile /home/compte/.htpasswd-preprod
Require valid-userDernier réglage, souvent oublié : couper les courriels sortants. Une copie de production contient les adresses de notification des formulaires ; un test en préproduction ne doit pas atterrir dans la boîte du client. Une extension à chargement automatique suffit, grâce au filtre pre_wp_mail qui court-circuite wp_mail() :
<?php
// wp-content/mu-plugins/preprod-sans-courriel.php
if ( 'staging' === wp_get_environment_type() ) {
add_filter( 'pre_wp_mail', '__return_false' );
}Copier la production vers la préproduction
La copie se fait en trois temps : la base, les fichiers téléversés, puis les adresses. Pour les fichiers, inutile de copier le dossier uploads/elementor/css/ : la documentation développeur d’Elementor précise que les styles sont enregistrés en base et que ce dossier ne contient que les fichiers CSS générés à partir d’eux. On les régénérera sur place.
# sur la production
wp db export /home/compte/sauvegardes/prod.sql
# sur la préproduction (« prod » est l'alias SSH du serveur de production)
rsync -az prod:/home/compte/sauvegardes/prod.sql ./prod.sql
rsync -az --delete --exclude 'elementor/css/' \
prod:/home/compte/www/wp-content/uploads/ wp-content/uploads/
wp db import prod.sql
wp option update blog_public 0La dernière ligne est volontaire : la base importée porte le réglage de visibilité de la production, et il faut le remettre à 0 après chaque copie. Le code, lui, ne se copie pas depuis la production : il arrive par votre circuit de déploiement habituel, depuis le dépôt.
Remplacer les URL : pourquoi deux passes
La structure de chaque page Elementor est enregistrée dans la métadonnée _elementor_data, sous forme de JSON. Dans ce JSON, les barres obliques sont échappées : l’adresse d’une image d’arrière-plan y figure sous la forme https:\/\/www.exemple.fr\/wp-content\/.... Une recherche de https://www.exemple.fr ne la trouve donc pas.
Le code de l’outil de remplacement d’URL d’Elementor, consultable dans includes/utils.php, montre ce qu’il fait réellement : il échappe lui-même les barres obliques des deux adresses, remplace uniquement dans les lignes de wp_postmeta dont la clé est _elementor_data, puis vide le cache de fichiers d’Elementor. Il ne touche ni aux options, ni aux réglages sérialisés, ni aux tables des autres extensions. À l’inverse, wp search-replace sait traiter les données PHP sérialisées dans toutes les tables enregistrées, mais ignore les adresses échappées. Il faut donc les deux :
wp search-replace 'https://www.exemple.fr' 'https://staging.exemple.fr' --skip-columns=guid --dry-run
wp search-replace 'https://www.exemple.fr' 'https://staging.exemple.fr' --skip-columns=guid
wp elementor replace-urls https://www.exemple.fr https://staging.exemple.fr
wp elementor flush-css --regenerate
wp cache flushLa première passe, à blanc grâce à --dry-run, affiche le nombre de remplacements par table sans rien modifier : c’est votre témoin. La commande wp elementor replace-urls exécute l’outil d’Elementor, qui exige deux adresses valides et différentes ; écrivez-les sans barre oblique finale, de la même façon des deux côtés. wp elementor flush-css --regenerate supprime puis recrée les fichiers CSS. Le vidage interne d’Elementor efface au passage les métadonnées de cache des pages, dont le cache d’éléments (_elementor_element_cache), ce qui évite de servir un rendu calculé avec les anciennes adresses.
Si d’autres extensions stockent elles aussi du JSON échappé, une passe supplémentaire avec la forme échappée couvre toutes les tables. Vérifiez toujours son effet à blanc d’abord : les guillemets simples empêchent l’interpréteur de commandes de toucher aux barres obliques inverses.
wp search-replace 'https:\/\/www.exemple.fr' 'https:\/\/staging.exemple.fr' --skip-columns=guid --dry-runRemonter le travail sans écraser la production
Une fois la production en ligne, ce qui a été construit en préproduction remonte par morceaux, jamais par la base entière. Pour la mise en page, Elementor propose l’export de kit, que ses notes de version appellent désormais modèle de site, qui regroupe contenus, gabarits et réglages du site. Depuis la version 4.0.0, ces modèles de site transportent aussi les classes et les variables de l’éditeur atomique. L’option --include permet de ne prendre que ce qui doit monter :
# sur la préproduction
wp elementor kit export /home/compte/transfert/gabarits.zip --include=templates,site-settings
# sur la production, après sauvegarde
wp elementor kit import /home/compte/transfert/gabarits.zip --include=templates,site-settingsDeux mises en garde. L’import de site-settings remplace les réglages globaux de la production : si quelqu’un a modifié une couleur en production entre-temps, elle sera écrasée. Et l’import de gabarits peut entrer en concurrence avec les conditions d’affichage existantes ; la commande accepte une option --overrideConditions qui prend les identifiants des gabarits concernés, à utiliser en connaissance de cause. Pour un simple ajustement du design system, l’import et l’export de variables et de classes depuis le panneau Design System, ajoutés en version 4.1.0, sont plus ciblés.
Une préproduction n’est fiable que si l’on sait, à tout moment, dans quel sens chaque donnée a le droit de circuler.
Pièges fréquents et cas où la méthode est de trop
- Adresses écrites dans le code : une URL saisie en dur dans un fichier du thème enfant n’est vue par aucune des deux passes. Utilisez
home_url()dans le code. - Méthode d’impression du CSS : avec des fichiers externes, les images d’arrière-plan figurent en adresse absolue dans des fichiers CSS ; la page d’aide d’Elementor sur les problèmes de migration le signale. Sans régénération, ces fichiers pointent vers l’ancien domaine.
- Caches en amont : un cache de page ou un réseau de diffusion peut continuer à servir des pages référençant d’anciens fichiers CSS. Le sixième épisode traitera la purge.
- Multisite :
wp search-replacene traite que le site courant sans--network, etflush-cssa besoin de--networkpour tout le réseau. - Données personnelles : une copie de production contient les soumissions et les comptes. Restreignez l’accès à la préproduction en conséquence, ou anonymisez.
Cette mécanique complète n’est pas toujours nécessaire. Si votre hébergeur fournit un outil de préproduction qui copie, remplace les adresses et repousse sélectivement, servez-vous-en, mais vérifiez une fois, sur une page avec image d’arrière-plan, qu’il traite bien les adresses échappées d’Elementor. Et pour un site de quelques pages modifié deux fois par an, une préproduction permanente coûte plus qu’elle ne rapporte : une copie ponctuelle, montée pour une évolution puis supprimée, suffit.
Conclusion
Une préproduction Elementor saine repose sur quatre habitudes : un nom de domaine reconnu par Elementor, une protection par mot de passe et des courriels coupés, deux passes de remplacement suivies d’une régénération du CSS, et une remontée par kit plutôt que par base de données. Avec cela, le site circule entre les environnements sans perdre ses images ni ses données. Le quatrième épisode remonte d’un cran : quel serveur pour accueillir ce site, et au nom de qui.
