« Si vous mettez à jour Elementor et Elementor Pro, nous recommandons de mettre à jour Elementor Pro en premier. » La phrase figure dans l’article d’aide officiel consacré aux mises à jour, qui la justifie ainsi : Elementor Pro est une extension d’Elementor, et les extensions se mettent en général à jour avant le cœur. Un autre article d’aide du même éditeur, consacré aux erreurs de mise à jour d’Elementor Pro, affirme l’inverse : toujours mettre à jour l’extension gratuite d’abord. Cette contradiction résume bien le sujet de ce dixième épisode de la série « Livrer un site Elementor en agence » : une mise à jour d’Elementor ne se pilote pas avec un réflexe, mais avec une méthode écrite, identique sur chaque site du parc. La migration de la version 3 vers la version 4 n’est pas traitée ici ; il s’agit des mises à jour courantes.
Lire avant de cliquer : notes de version et compatibilité
L’article d’aide d’Elementor sur les mises à jour liste quatre précautions avant toute mise à jour : faire une sauvegarde, lire la documentation liée à la version, vérifier la compatibilité des extensions tierces, tester sur une préproduction. Ce sont les bonnes, et elles ne sont pas décoratives.
Les notes de version d’Elementor se lisent dans l’onglet de développement de sa fiche WordPress.org, celles d’Elementor Pro sur la page de notes de version du site d’Elementor. Ce que nous y cherchons, dans l’ordre :
- les versions qui changent le deuxième nombre (de 3.34 à 3.35, par exemple), qui apportent des fonctions et parfois des changements de structure, à traiter avec la procédure complète ;
- les versions correctives (le troisième nombre), qui corrigent des anomalies et des failles, à appliquer vite mais toujours après la préproduction ;
- les fonctionnalités activées par défaut : lors du passage à la version 4.0, Elementor a précisé que les nouvelles installations démarraient avec les fonctions atomiques activées, tandis que les sites existants conservaient leur configuration. Ce genre de mention change ce que vous devez vérifier ;
- les exigences de version : WordPress, PHP, et la version minimale d’Elementor qu’exige une version d’Elementor Pro.
Côté extensions tierces, le risque principal ne vient pas d’Elementor lui-même mais des modules complémentaires qui s’appuient sur ses classes internes. Pour chaque site, tenez à jour la liste de ces modules et la date de leur dernière mise à jour : un module complémentaire qui n’a pas suivi les trois dernières versions d’Elementor est le premier suspect de toute régression.
Elementor et Elementor Pro : deux extensions, une seule décision
Elementor Pro dépend d’Elementor, et les deux avancent ensemble. Laisser durablement l’une à jour et l’autre en retard est la configuration la plus risquée, parce que la plus récente peut appeler du code que l’ancienne ne connaît pas. Notre règle tranche la contradiction de la documentation de façon pragmatique : nous suivons l’article d’aide principal, Elementor Pro puis Elementor, sauf quand les notes de version d’Elementor Pro exigent une version d’Elementor plus récente que celle installée, auquel cas Elementor passe en premier. Dans les deux cas, les deux mises à jour sont faites dans la même intervention, jamais à plusieurs jours d’écart.
Deux contraintes pèsent sur cette décision. D’abord, la mise à jour d’Elementor Pro exige une licence active : l’article d’aide sur les erreurs de mise à jour le rappelle explicitement. Un site dont la licence a expiré peut recevoir la mise à jour d’Elementor sans pouvoir suivre côté Pro, et c’est exactement le décalage à éviter ; le douzième épisode revient sur la responsabilité du renouvellement. Ensuite, Elementor relève régulièrement sa version minimale de PHP, et WordPress ne propose pas la mise à jour d’une extension dont la nouvelle version exige un PHP plus récent que celui du serveur : un site bloqué sur une ancienne version d’Elementor est souvent d’abord un problème d’hébergement.
La procédure sur un site : préproduction, mise à jour de la base, vérification
La préproduction, montée selon le troisième épisode, doit être une copie récente de la production : une préproduction vieille de six mois teste une mise à jour sur un site qui n’existe plus. Sur cette copie, la procédure est la suivante :
- noter les versions en place, pour savoir où revenir en cas de problème ;
- faire une sauvegarde de la base, même sur la préproduction ;
- mettre à jour Elementor Pro et Elementor dans l’ordre retenu ;
- lancer la mise à jour de la base de données d’Elementor, puis celle d’Elementor Pro ;
- régénérer les fichiers CSS ;
- vérifier la liste de pages de référence du site, l’éditeur et les formulaires.
Certaines versions d’Elementor modifient les données stockées, par exemple lors du passage aux kits ou du remplacement des anciens schémas de couleurs par les réglages globaux. L’administration propose alors de lancer cette mise à jour ; WP-CLI permet de la déclencher explicitement, comme le détaille la documentation de la commande Update DB. Elle ne fait rien si aucune mise à jour n’est nécessaire, ce qui permet de l’inclure systématiquement dans la procédure :
# 1. Versions en place, à consigner dans le journal d'intervention
VERSION_ELEMENTOR=$(wp plugin get elementor --field=version)
VERSION_PRO=$(wp plugin get elementor-pro --field=version)
echo "Elementor $VERSION_ELEMENTOR, Elementor Pro $VERSION_PRO"
# 2. Sauvegarde de la base
wp db export avant-maj-elementor.sql
# 3. Mises à jour, une commande par extension pour maîtriser l'ordre
wp plugin update elementor-pro
wp plugin update elementor
# 4. Mise à jour des données, si nécessaire
wp elementor-pro update db
wp elementor update db
# 5. Fichiers CSS recréés immédiatement
wp elementor flush-css --regenerate
L’option --dry-run de wp plugin update permet de voir, avant d’agir, quelles versions seraient installées. Si la préproduction ne révèle rien, la même séquence est rejouée en production, idéalement à un moment où le client ne modifie pas son site. La vérification visuelle automatisée après mise à jour mériterait un article à elle seule ; ici, une liste de cinq à dix pages de référence vérifiées à l’œil, toujours les mêmes, couvre l’essentiel sur un site vitrine.
Revenir en arrière : l’outil Version Control et ses limites
Elementor intègre un outil de retour à une version antérieure. Dans les outils d’Elementor, l’onglet Version Control propose par défaut la version précédente d’Elementor ou d’Elementor Pro ; une liste déroulante permet de remonter plus loin, puis le bouton de réinstallation et une confirmation font le reste. L’interface d’administration d’Elementor ayant évolué, l’article d’aide y accède aujourd’hui depuis Elementor, puis Editor et Home, panneau Tools. Pour Elementor seul, la version gratuite, une autre voie existe : télécharger la version voulue depuis la page avancée de sa fiche WordPress.org. Cette voie ne vaut pas pour Elementor Pro.
En ligne de commande, Elementor se réinstalle dans une version donnée depuis WordPress.org ; Elementor Pro, lui, se réinstalle depuis une archive que vous avez conservée, d’où l’intérêt de garder chaque version déployée dans le dossier de l’agence :
# Revenir à la version d'Elementor notée avant l'intervention
wp plugin install elementor --version="$VERSION_ELEMENTOR" --force
# Revenir à la version d'Elementor Pro archivée par l'agence
wp plugin install "/srv/archives/elementor-pro-$VERSION_PRO.zip" --force
Si la session a été fermée entre-temps, reprenez les numéros consignés dans le journal d’intervention à l’étape 1. Reste la limite essentielle : l’article d’aide sur le retour arrière recommande une sauvegarde préalable mais ne dit rien de la base de données. Si la mise à jour a lancé une migration de données, réinstaller l’ancien code ne défait pas cette migration. Notre règle est donc simple : si update db a effectivement modifié des données, le retour arrière passe par la restauration de la sauvegarde de l’étape 2, dont le neuvième épisode décrit le test, et non par la seule réinstallation de l’extension.
Un retour arrière qui ne restaure que le code laisse le site dans un état que personne n’a jamais testé.
Mises à jour automatiques et parc de sites avec WP-CLI
Faut-il activer les mises à jour automatiques d’Elementor ? Sur un site couvert par un contrat de maintenance, notre réponse est non : une mise à jour qui peut lancer une migration de données doit passer par la préproduction. Sur un site sans contrat, que personne ne surveille, la réponse s’inverse, car une faille non corrigée coûte plus cher qu’une régression de mise en page. Dans les deux cas, le choix est explicite et vérifiable :
wp plugin auto-updates status elementor elementor-pro
wp plugin auto-updates disable elementor elementor-pro
Sur un parc, les alias de WP-CLI évitent de se connecter site par site. Ils se déclarent dans le fichier wp-cli.yml de l’agence, avec des groupes qui correspondent à des vagues de mise à jour :
@client-a:
ssh: deploy@client-a.example.com/var/www/client-a
@client-b:
ssh: deploy@client-b.example.com/var/www/client-b
@client-c:
ssh: deploy@client-c.example.com/var/www/client-c
@vague1:
- @client-a
- @client-b
La commande wp @vague1 plugin list --name=elementor-pro --fields=name,version,update_version donne alors l’état de tous les sites du groupe. Nous organisons le parc en vagues : d’abord les sites les plus simples, sans module complémentaire tiers, puis, après un délai d’observation, les sites qui en utilisent. Un problème découvert dans la première vague arrête la seconde.
Pièges et cas où la méthode ne s’applique pas
- Mettre à jour en masse sans préproduction : WP-CLI rend l’opération rapide sur vingt sites, et donc la régression aussi.
- Oublier la mise à jour de la base : le site s’affiche, mais l’administration réclame une mise à jour que personne ne lance, et certaines données restent dans l’ancien format.
- Tester sur une préproduction sans les mêmes modules complémentaires que la production, ce qui vide le test de son sens.
- Revenir en arrière sans noter la cause : un retour arrière est une décision temporaire ; la version écartée doit être réévaluée à la version corrective suivante.
Cette méthode est trop lourde pour un site sans contenu sensible, sans formulaire et sans module complémentaire, où une mise à jour directe avec sauvegarde préalable suffit. À l’inverse, elle est insuffisante pour un site de commerce en ligne, où les parcours de commande exigent leurs propres tests après chaque mise à jour.
En résumé
Mettre à jour Elementor sans régression tient en peu de règles : lire les notes de version, traiter Elementor et Elementor Pro dans la même intervention, passer par la préproduction, lancer update db pour les deux extensions, régénérer le CSS, et prévoir un retour arrière qui restaure la base quand les données ont changé. Le onzième épisode quitte la technique pour une question tout aussi décisive : comment laisser le client modifier son site sans le casser.
