Reprendre un site WordPress qu’on n’a pas conçu, c’est un peu comme emménager dans une maison meublée par quelqu’un d’autre. On ouvre les placards les uns après les autres, on découvre des choix qu’on n’aurait pas faits. On doit alors se demander pourquoi c’est rangé comme ça.
Cela m’arrive de temps en temps et encore récemment, de reprendre des sites que je n’ai pas conçus. Dans ce cas, le mieux que l’on puisse faire c’est de demander un accès au tableau de bord pour auditer le site. En regardant de plus près, il y a parfois des sites dans lesquels je ne mettrai jamais les mains, car cela me paraît trop risqué.
J’en ai donc repris un récemment, et dès l’ouverture du tableau de bord, quelque chose m’a interpellée : j’ai compté 17 extensions désactivées.
Je vous raconte cette l’expérience récente. Attention, cet article n’a aucunement vocation à faire la critique de l’ancien presta. C’est juste un partage d’expérience où je vous raconte comment j’ai procédé pour le reprendre en main.
Reprendre un site WordPress veut dire audit.
Donc, premier constat : 17 extensions étaient désactivées. Je ne saurai peut-être jamais la vraie raison. Ce sont peut-être des extensions qui ont été testées pendant la construction du site et qui ont été abandonnées. Ce sont peut-être des extensions qui entraient en conflit avec d’autres.
Le plus dur est de se mettre à la place de la personne qui a géré le site avant moi. Parfois on peut se mettre à juger cette personne. En ce qui me concerne j’essaye de garder les pieds sur terre. Car on ne connaît jamais tout le contexte dans lequel une décision a été prise : le budget disponible à l’époque, les délais serrés, les compétences de l’équipe en place, ou tout simplement une urgence à régler dans la journée.
Pour revenir aux 17 extensions, on peut imaginer plusieurs pistes possibles, comme je l’ai un peu dit plus haut. Un conflit repéré en urgence entre deux extensions et désactivées dans la précipitation puis jamais résolu. Une fonctionnalité testée, finalement abandonnée, mais jamais nettoyée derrière. Un changement de prestataire en cours de route, avec une passation qui ne s’est pas faite. Ou tout simplement la peur de supprimer quelque chose d’important, en se disant qu’on y reviendra plus tard (et ce « plus tard » qui n’arrive jamais, on connaît tous et toutes ça).
Aucun de ces scénarios n’est une faute en soi. Mais ensemble, ils dessinent une réalité assez fréquente : celle d’un site géré au fil de l’eau, sans le temps ni les moyens de faire un vrai ménage régulier.
Pourquoi garder des extensions inactives n’est pas une bonne idée
Une fois passée cette étape de compréhension, il faut quand même agir. Parce que garder des extensions désactivées, ce n’est jamais neutre.
D’abord, une extension désactivée reste installée sur le serveur. Les administrateurs ne vont pas forcément la mettre à jour, puisque elles n’est pas active. Une extension désactivée peut donner un faux sentiment de sécurité. « Elle est désactivée, donc elle ne pose pas de problème. » Sauf que ce n’est pas tout à fait vrai. Son code (et ses éventuelles failles de sécurité) est toujours présent et potentiellement exploitable, même si l’extension ne « tourne » pas au quotidien. Le simple fait qu’elle soit inactive ne la rend pas invisible pour quelqu’un qui chercherait une porte d’entrée.
Ensuite, ces extensions inactives alourdissent inutilement les sauvegardes, les migrations ou les restaurations. Celles-ci deviennent plus longues à cause de tous ces fichiers laissés là.
Ça peut aussi peser sur les performances du site. Plus il y a d’extensions installées, actives ou non, plus l’administration WordPress met de temps à charger : à chaque affichage de la liste des extensions, WordPress doit scanner chacune d’entre elles.
Pour moi, si une extension est désactivée et que le site continue de fonctionner, elle n’a aucune utilité, donc je la supprime.
Ici, j’ai donc supprimé les 17 extensions, mais j’ai pris aussi soin de documenter pourquoi je l’ai fait et je les ai toutes listées.
define( « WP_AUTO_UPDATE_CORE », false );
La première chose que constatée, c’est qu’Elementor Pro n’était pas à jour depuis un moment. Je savais qu’il y avait une mise à jour de sécurité quand j’étais sur le tableau de bord. Mais là, aucune mise à jour de proposée. Mon premier réflexe a été de vérifier si la licence était toujours valide et c’était bien le cas.
J’ai aussi constaté que les mises à jour de sécurité de WordPress ne fonctionnaient pas non plus.
Je suis donc aller explorer le fichier wp-config.php et j’ai trouvé la constante :
define( 'WP_AUTO_UPDATE_CORE', false );Si vous ne la connaissez pas, cette constante désactive les mises à jour automatiques du cœur de WordPress, y compris les mises à jour mineures de sécurité.
La personne qui a ajouté cette ligne voulait sans doute garder un contrôle total sur un site qu’elle jugeait sensible. Ou peut-être qu’une mise à jour automatique avait déjà cassé quelque chose par le passé, et que cette constante était une façon de se prémunir d’une mauvaise surprise. C’est une inquiétude que je comprends très bien.
Pourquoi ce n’est pas toujours une bonne idée de couper les mises à jour automatiques
Le problème, ce n’est pas tant cette constante en elle-même. C’est ce qui se passe (ou plutôt, ce qui ne se passe pas) après.
Sans supervision active, désactiver les mises à jour automatiques du cœur revient à se priver des correctifs de sécurité critiques. Et il est possible que personne ne s’en rende compte avant qu’il ne soit trop tard : pas de message d’erreur, pas d’alerte visible, juste un site qui accumule silencieusement du retard sur des failles pourtant corrigées depuis longtemps côté WordPress.
Ce choix peut être légitime dans certains contextes : un site à fort trafic, un process de validation obligatoire avant toute modification, une équipe technique qui préfère tout maîtriser. Mais dans ces cas-là, il doit s’accompagner d’un vrai suivi manuel, régulier, et pas d’un oubli. Le vrai problème, ce n’est donc pas de poser cette constante. C’est de la poser puis de ne plus jamais revenir vérifier les mises à jour de sécurité disponibles.
J’ai supprimé la constante. De toute façon WordPress propose dans le tableau de bord de choisir entre les mises à jour automatiques ou les mises à jour de sécurité.
Elementor, resté figé dans le temps
Comme je le disais, j’ai aussi trouvé une version d’Elementor un peu ancienne (avec donc plusieurs versions de retard).
Le problème dont je parlais, c’est que la mise à jour n’était pas proposée. Impossible de trouver la raison. Bizarrement, la mise à jour a fini par être proposée, au même moment où j’ai supprimé la constante. C’est toutefois quelque chose qui ne devrait pas arriver, car cela n’a rien à voir.
Quand on on trouve une mise à jour depuis une version assez ancienne à la version la plus récente, on peut avoir envie de cliquer sur la mise à jour. Mais sans test, comme ça, ce réflexe peut coûter cher.
Pourquoi ne pas mettre à jour sans tester avant
Ce que je vais dire pour Elementor est valable pour tout en fait.
Elementor c’est un page builder très utilisé, avec des mises à jour fréquentes, et parfois des changements de structure assez profonds. Plus l’écart de versions est grand, plus les changements s’accumulent, et plus le risque de casser l’affichage de certaines pages augmente. Une mise à jour en bloc, sans étape intermédiaire, c’est un peu comme sauter plusieurs marches d’escalier d’un coup : on peut y arriver, mais on peut aussi se rater.
La meilleur méthode est d’installer un environnement de test et ne pas travailler d’emblée directement en production et de tester les mises à jour. Ainsi on met à jour progressivement, en vérifiant l’affichage à chaque étape, plutôt que de sauter directement à la dernière version disponible.
C’est plus long, c’est vrai. Mais c’est tellement moins stressant que de découvrir une page cassée en production, un vendredi soir 😁
Ainsi les bonnes pratiques à mettre en place quand on reprend un site qu’on n’a pas conçu sont :
- faire un état des lieux complet avant de toucher à quoi que ce soit : extensions actives et inactives, thème utilisé, constantes présentes dans le wp-config.php, versions de PHP et de WordPress
- documenter ce que l’on trouve avant d’intervenir, même quand l’intervention semble rapide
- toujours travailler d’abord sur un environnement de test, jamais directement sur le site en production
- sauvegarder avant toute action, même celle qui paraît la plus anodine
- mettre à jour progressivement, en testant à chaque étape plutôt qu’en un seul bloc
- réactiver a minima les mises à jour de sécurité automatiques, si elles avaient été désactivées sans raison claire
- ne jamais juger les choix de la personne précédente : elle avait ses propres contraintes, qu’on ne connais pas toujours
Reprendre un site qu’on n’a pas conçu, c’est un peu mener une enquête. Chaque trouvaille, extension désactivée, constante oubliée, extension jamais mise à jour, est un indice sur l’histoire du site, pas une occasion de pointer du doigt qui que ce soit. Et cette enquête, aussi fastidieuse soit-elle parfois, c’est justement ce qui permet de repartir sur des bases saines.
Image à le Une : Margarida Afonso
Merci pour ce partage, l’analogie de la maison meublée par quelqu’un d’autre est très juste.
Sur le mystère de la mise à jour Elementor qui n’apparaissait pas : avant de suspecter WP_AUTO_UPDATE_CORE, ça vaut le coup de regarder trois autres constantes qui traînent souvent dans les wp-config.php repris. DISALLOW_FILE_MODS masque purement et simplement toutes les notifications de mise à jour dans l’admin. AUTOMATIC_UPDATER_DISABLED coupe l’ensemble du mécanisme, cœur, extensions et thèmes. Et WP_HTTP_BLOCK_EXTERNAL empêche WordPress de joindre les serveurs de licence, donc Elementor Pro ne peut tout simplement pas savoir qu’une version plus récente existe. Dernière piste : le transient _site_transient_update_plugins, qui peut rester figé si le cron WordPress est désactivé (DISABLE_WP_CRON sans tâche système en relais derrière). Un wp transient delete –all en CLI règle souvent la question en dix secondes.
Sur les 17 extensions : on fait pareil de notre côté, mais on garde une archive zip du dossier plugins avant suppression, avec la liste des versions. Sur les quelque 300 sites que nous maintenons ou avons maintenus depuis treize ans chez WeAreWP, ça n’a servi que trois ou quatre fois, mais ces trois ou quatre fois-là, ça a évité une soirée compliquée. Une extension inactive peut cacher une fonction appelée depuis le thème enfant.
Et un grand oui sur le non-jugement du prestataire précédent. C’est aussi la meilleure façon de ne pas passer à côté d’une contrainte métier qu’on n’a pas encore comprise.
Bonjour Thierry,
Merci beaucoup pour ce complément de pistes. Je vais les garder sous le coude et aussi aller encore vérifier dans le fichier wp-config, mais il me semble ne pas avoir vu ces autres constantes.
Complément à mon message précédent, où j’ai été imprécis : ces constantes ne vivent pas forcément dans le wp-config.php.
DISALLOW_FILE_MODS, AUTOMATIC_UPDATER_DISABLED ou DISABLE_WP_CRON sont lues à l’exécution, donc un mu-plugin, un drop-in ou le functions.php du thème peuvent les poser.
Merci pour la précision Thierry !