wp db export - | gzip > client.sql.gz : la commande tient sur une ligne, et c’est précisément ce qui rend les sauvegardes trompeuses. Elle produit un fichier, ce fichier rassure, et personne ne vérifie qu’il permet de reconstruire le site tel qu’il était. Sur un site Elementor, la question est plus aiguë qu’ailleurs, parce que la mise en page ne vit pas dans les fichiers du thème mais dans la base, sous forme de JSON, et que l’affichage dépend de fichiers CSS générés à partir de ce JSON. Ce neuvième épisode de la série « Livrer un site Elementor en agence » détaille ce qu’il faut sauvegarder, à quel rythme, puis la procédure qui compte vraiment : restaurer sur un environnement isolé et vérifier ce qu’Elementor attend.
Ce qu’un site Elementor range dans la base et sur le disque
Elementor enregistre la mise en page de chaque page en JSON dans les métadonnées de l’article, c’est-à-dire dans la table wp_postmeta, sous forme de champ personnalisé privé. La documentation développeur le dit sans détour, et le code source d’Elementor nomme les clés : _elementor_data pour la structure et les réglages des éléments, _elementor_edit_mode pour signaler qu’une page est construite avec Elementor, _elementor_page_settings pour les réglages de page, _elementor_template_type pour le type de modèle, _elementor_version pour la version qui a enregistré la page, et _elementor_element_cache pour le cache d’éléments. Une sauvegarde de fichiers sans base ne contient donc aucune page Elementor exploitable.
Le kit, qui porte les couleurs, typographies et réglages globaux du site, est lui aussi un contenu : un article du type elementor_library, désigné comme kit actif par l’option elementor_active_kit. Les modèles du Theme Builder (en-tête, pied de page, gabarits d’articles) et leurs conditions d’affichage sont également en base. Enfin, si le site utilise le widget Form d’Elementor Pro avec l’enregistrement des soumissions, celles-ci sont stockées dans la base du site, dans des tables dédiées : votre sauvegarde contient alors des données personnelles.
Côté disque, le périmètre est le suivant :
- wp-content/uploads : les médias, et par défaut le sous-dossier
uploads/elementor, où Elementor écrit ses fichiers CSS générés. Ces fichiers se régénèrent, mais les sauvegarder évite un site sans styles dans les minutes qui suivent une restauration ; - wp-content/plugins : surtout Elementor Pro, qui n’est pas téléchargeable sur WordPress.org. Sans l’archive de la version exacte en place, vous restaurez une base écrite par une version que vous ne savez plus réinstaller ;
- wp-content/themes : le thème et son thème enfant, avec le code ajouté au fil du projet ;
- wp-config.php : à conserver à part, chiffré, car il contient les identifiants de la base et les clés de sécurité ;
- la fiche de licences : pas un fichier du site, mais un document du dossier client qui indique qui détient la licence Elementor Pro et sur quel compte, sujet du deuxième épisode.
Fréquence, rétention et stockage hors serveur
La bonne fréquence se déduit d’une question simple : combien de modifications le client accepte-t-il de perdre ? Un site vitrine modifié une fois par mois se contente d’une sauvegarde quotidienne de la base et d’une sauvegarde hebdomadaire des fichiers. Un site dont les formulaires enregistrent des demandes chaque jour exige au minimum une sauvegarde quotidienne de la base, puisque chaque soumission perdue est une demande commerciale perdue. À cela s’ajoute une sauvegarde manuelle juste avant chaque mise à jour d’Elementor ou d’Elementor Pro, que le dixième épisode intègre à la procédure de mise à jour.
La rétention, elle, dépend du délai de détection. Une régression visuelle sur une page peu consultée peut passer inaperçue pendant trois semaines ; si vous ne gardez que sept jours de sauvegardes, toutes contiennent déjà la page abîmée. Gardez donc plusieurs profondeurs : des sauvegardes quotidiennes sur quelques jours, hebdomadaires sur quelques semaines, mensuelles sur quelques mois. Mais la rétention a une limite légale : si la base contient des soumissions de formulaires, la durée de conservation des sauvegardes doit être compatible avec celle annoncée dans la politique de confidentialité du client. C’est une tension réelle, à arbitrer par écrit avec lui.
Le stockage, enfin, doit être hors du serveur et hors du compte d’hébergement. Une sauvegarde rangée dans le même espace que le site disparaît avec lui si le compte est suspendu, compromis ou supprimé. Chiffrez les archives avant leur envoi, et conservez la clé ailleurs que les archives.
Monter un environnement de restauration isolé
Le test de restauration se fait sur une machine qui ne peut ni être indexée, ni envoyer de courriels réels, ni exécuter les tâches planifiées du client. Deux options existent pour l’adresse. La première consiste à restaurer sous la même adresse que la production, en la faisant pointer vers la machine de test via le fichier hosts du poste qui vérifie : la base reste strictement identique à l’archive, ce qui teste la sauvegarde elle-même. La seconde consiste à restaurer sous une autre adresse, ce qui impose un remplacement d’URL, dont les pièges propres à Elementor ont été détaillés dans le troisième épisode. Pour un test de restauration, nous préférons la première : moins vous transformez l’archive, plus le test est fidèle.
Avant même d’importer la base, placez une extension obligatoire qui intercepte les courriels. Le filtre pre_wp_mail, disponible depuis WordPress 5.7, court-circuite wp_mail() dès qu’il renvoie une valeur non nulle :
<?php
// wp-content/mu-plugins/restauration-sans-courriel.php
add_filter( 'pre_wp_mail', function ( $retour, $atts ) {
$destinataires = is_array( $atts['to'] ) ? implode( ', ', $atts['to'] ) : $atts['to'];
error_log( 'Courriel intercepté pour ' . $destinataires . ' : ' . $atts['subject'] );
return true; // wp_mail() renvoie true sans rien envoyer.
}, 10, 2 );
Renvoyer true plutôt que false est volontaire : pour le code appelant, wp_mail() signale alors un envoi réussi, ce qui évite de tester un parcours d’échec qui n’existe pas en production, tandis que le journal d’erreurs garde la trace du courriel qui serait parti. Une fois les fichiers décompressés et wp-config.php adapté à la base de test, la restauration elle-même tient en quelques commandes :
# Couper les tâches planifiées avant le premier chargement
wp config set DISABLE_WP_CRON true --raw
# Importer la base
gunzip -c client.sql.gz | wp db import -
# Interdire l'indexation de la copie
wp option update blog_public 0
# Recréer les fichiers CSS d'Elementor à partir de la base
wp elementor flush-css --regenerate
La commande wp elementor flush-css supprime les fichiers CSS en cache ; l’option --regenerate les recrée immédiatement au lieu d’attendre la prochaine visite de chaque page, comme le précise la documentation de la commande Flush CSS. Depuis l’administration, l’équivalent est l’outil Clear Files & Data d’Elementor.
Les vérifications propres à Elementor après restauration
Un site qui s’affiche n’est pas un site restauré. Voici la liste que nous déroulons, dans cet ordre, en comparant chaque résultat avec la production :
- Le nombre de pages Elementor, qui doit être identique de part et d’autre ;
- Le kit actif : l’option
elementor_active_kitdoit désigner un article existant, sans quoi le site s’affiche avec les styles par défaut ; - Les modèles du Theme Builder : en-tête, pied de page et gabarits d’articles doivent apparaître là où leurs conditions le prévoient ;
- Les formulaires : une soumission de test doit apparaître dans les soumissions d’Elementor Pro et laisser une ligne dans le journal des courriels interceptés ;
- Les liens et médias : aucun ne doit pointer vers une adresse de préproduction oubliée ;
- Les versions : Elementor et Elementor Pro doivent être exactement celles de la production.
Les premières vérifications se scriptent :
# Nombre de pages et modèles construits avec Elementor
wp db query "SELECT COUNT(*) FROM $(wp db prefix)postmeta WHERE meta_key = '_elementor_data'"
# Kit actif : identifiant, puis type de l'article correspondant
wp option get elementor_active_kit
wp post get $(wp option get elementor_active_kit) --field=post_type
# Versions en place
wp plugin list --name=elementor --fields=name,version
wp plugin list --name=elementor-pro --fields=name,version
# Tables de soumissions de formulaires, si le site en utilise
wp db query "SHOW TABLES LIKE '%submissions%'"
La commande sur le kit doit renvoyer elementor_library. Le reste se vérifie à l’œil, sur une liste de pages fixée une fois pour toutes : l’accueil, une page de contenu, un article, la page du formulaire principal, et toute page qui utilise une boucle ou un contenu dynamique.
Un exercice chronométré, consigné dans le dossier client
Prenons un site vitrine livré au printemps, avec un formulaire de demande de devis et une vingtaine de pages. Chaque trimestre, l’archive de la veille est restaurée sur une machine de test, sous la même adresse grâce au fichier hosts. La fiche de l’exercice note la date de l’archive, l’heure de début et de fin, chaque anomalie et sa correction. Lors du premier exercice, deux problèmes sont apparus : l’archive des extensions ne contenait pas Elementor Pro, exclu par erreur d’un filtre de sauvegarde, et la restauration a pris plus du double du temps estimé, faute de procédure écrite. Aucun des deux n’aurait été découvert avant un véritable incident.
Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse sur une sauvegarde.
Le temps mesuré a une seconde utilité : il donne une base réelle au chiffrage du contrat de maintenance, sujet du douzième épisode.
Les pièges qui reviennent
- Activer la licence Elementor Pro sur la copie : chaque offre limite le nombre de sites activés. Ne connectez pas la licence sur l’environnement de test : la copie n’en a pas besoin pour être vérifiée, et vous consommeriez une activation pour rien.
- Laisser les tâches planifiées s’exécuter : une copie qui relance des envois programmés ou des synchronisations vers un outil externe pollue les données réelles du client.
- Remplacer les URL avec une simple recherche :
_elementor_datastocke les adresses dans un JSON où les barres obliques sont échappées ; un remplacement naïf en oublie une partie. - Restaurer sur une version de PHP différente : un écart entre la machine de test et la production peut masquer ou provoquer une erreur qui n’a rien à voir avec la sauvegarde.
- Croire qu’un export de kit suffit :
wp elementor kit exportproduit un fichier utile pour réutiliser un design, pas une sauvegarde : il n’emporte ni le code des extensions, ni les soumissions de formulaires, ni les réglages WordPress étrangers à Elementor.
Quand cette procédure est disproportionnée
Pour un site éphémère, une page d’événement en ligne quelques semaines par exemple, un test de restauration trimestriel n’a pas de sens : une sauvegarde complète à la livraison et une avant chaque modification suffisent. De même, si l’hébergeur fournit des sauvegardes avec une restauration à l’identique documentée et que vous l’avez déjà testée une fois sur ce site, l’exercice peut s’espacer, à condition de garder une copie hors de son infrastructure. Et si le client gère lui-même son hébergement et ses sauvegardes, votre rôle est de lui remettre la liste des vérifications Elementor ci-dessus, pas de les exécuter sans contrat.
En résumé
Sur un site Elementor, la sauvegarde critique est la base de données, parce qu’elle contient la mise en page, le kit, les modèles et les soumissions. Les fichiers comptent aussi, Elementor Pro en tête. Mais seule une restauration testée, sur un environnement isolé et avec une liste de vérifications écrite, transforme ces archives en garantie. Le dixième épisode s’appuie sur ces sauvegardes pour mettre à jour Elementor et Elementor Pro sans régression.
