Note d’ingénierie

Site WordPress cassé après une mise à jour : que vérifier en premier ?

Une séquence pratique de diagnostic après une mise à jour du cœur, d’un plugin, d’un thème ou de PHP.

Quand un site WordPress casse juste après une mise à jour, préservez l’état de panne, établissez un point de retour et identifiez d’abord la couche qui a changé.

Si le site continue à recevoir des commandes, formulaires ou connexions, protégez les données récentes avant toute restauration d’une ancienne base.

1. Identifier précisément ce qui a changé

Notez la mise à jour du cœur, plugin, thème, PHP, base, cache ou hébergement survenue avant la panne. Si plusieurs changements ont eu lieu ensemble, isolez les dépendances une par une.

2. Lire l’erreur au bon niveau

Erreur fatale PHP, HTTP 500, page blanche et mise en page cassée n’indiquent pas la même couche. Les logs serveur et PHP sont souvent plus utiles que des actualisations répétées.

3. Tester les frontières plugin et thème avec méthode

Ne changez qu’une frontière à la fois et conservez l’état initial. Désactiver beaucoup de composants simultanément détruit souvent les indices utiles.

4. Traiter une mise à jour PHP comme un changement applicatif

Du vieux code peut devenir fatal sous une version PHP plus récente. Si la panne a commencé avec PHP, testez directement la stack contre cette modification.

5. Vider uniquement le cache que vous comprenez

Cache navigateur, cache de page, CDN, opcode et cache objet Redis sont des systèmes distincts. Tout vider peut simplement masquer le symptôme.

6. Restaurer seulement ce qui est nécessaire

Un retour de fichiers peut suffire pour un plugin ou un thème. Restaurer toute la base peut écraser de nouvelles commandes, comptes ou contenus.