Plugin WordPress exige une version PHP plus récente : que faire quand l’hébergement est obsolète

Vous cliquez sur « Mettre à jour » pour un plugin et votre site vous récompense par un écran blanc, une erreur fatale, ou le classique « Ce plugin nécessite PHP 8.1, vous êtes en 7.4. » L’auteur du plugin n’est pas dramatique ; il pratique l’hygiène minimale. Votre hébergement, en revanche, vit dans le passé comme s’il avait un téléphone à clapet et de fortes opinions sur les CD.

C’est un de ces problèmes qui semblent être du « stuff WordPress » mais qui relèvent en réalité de l’ingénierie système : compatibilité d’exécution, cadence des correctifs, rayon d’impact, retour arrière, et ce que vous faites quand vous ne contrôlez pas l’environnement. Traitez-le comme de la production, pas comme un site hobby.

Méthode de diagnostic rapide

Si vous êtes pressé et que le site est down (ou que vous en êtes à un clic près), ne « fouillez » pas sans méthode. Faites ceci dans l’ordre. Cela trouve rapidement le goulot d’étranglement et évite des temps d’arrêt auto-infligés.

1) Confirmez quelle version de PHP est réellement exécutée (pas ce que prétend le panneau de contrôle)

• Vérifiez dans l’administration WordPress : Outils → Santé du site → Infos → Serveur.
• Ou exécutez une vérification en CLI sur l’hôte. Voir la section commandes ci-dessous.

Décision : Si PHP est inférieur au minimum du plugin, arrêtez-vous et planifiez une mise à niveau. N’installez pas le plugin de force « quand même ». C’est comme ça qu’on apprend les erreurs fatales.

2) Identifiez d’où provient PHP (Apache mod_php vs PHP-FPM vs handler)

• Hébergement mutualisé : souvent un « sélecteur PHP » par site, mais parfois il y a une valeur par défaut globale.
• VPS : vous pouvez avoir plusieurs pools PHP-FPM, chacun sur des versions différentes.

Décision : Si vous pouvez exécuter plusieurs versions côte à côte, vous pouvez mettre à jour WordPress d’abord sans casser les autres applications sur la machine.

3) Déterminez le rayon d’impact : s’agit-il d’un seul site ou d’une flotte ?

• Combien de vhosts pointent vers le même runtime PHP ?
• D’autres sites sont-ils legacy et verrouillés sur PHP 7.4 ?

Décision : Les mises à jour à l’échelle de la flotte nécessitent un staging et un déploiement phasé. Les mises à jour d’un seul site peuvent être plus rapides — mais nécessitent tout de même un retour arrière.

4) Capturez l’erreur réelle (logs, pas impressions)

• Journal de débogage WordPress pour les erreurs PHP.
• Journaux du serveur web et de PHP-FPM pour les problèmes de démarrage/configuration.

Décision : Si l’erreur indique « requires PHP X », la mise à niveau est obligatoire. Si l’erreur est « fonction indéfinie » ou « propriété typée », cela signifie généralement un décalage de version.

5) Choisissez la correction la moins risquée qui satisfait l’exigence

• Meilleur : mettre à niveau PHP (version supportée) avec staging et retour arrière.
• Second meilleur : isoler le site dans un conteneur ou une VM séparée.
• Dernier recours : bloquer sur une ancienne version du plugin (court terme) et planifier une migration.

Ce que l’erreur signifie vraiment (et ce qu’elle ne signifie pas)

Quand un plugin indique qu’il requiert PHP 8.1+ (ou 8.0+, etc.), ce n’est rarement « parce que l’auteur vous en veut ». C’est généralement l’une de ces raisons :

• Fonctionnalités du langage : le plugin utilise une syntaxe absente des anciennes versions de PHP (types union, attributs, expressions match, enums, propriétés readonly).
• Fonctions cœur et extensions : il dépend de fonctions plus récentes ou de versions modernes d’extensions comme cURL, OpenSSL, JSON, mbstring ou intl.
• Posture de sécurité : ils ne veulent pas supporter des versions EOL de PHP avec des vulnérabilités connues.
• Réalisme de la matrice de tests : maintenir la compatibilité jusqu’à PHP 7.4 (ou plus ancien) multiplie le coût des tests. Ils coupent la queue.

Ce que cela ne signifie pas : que la mise à niveau de PHP cassera automatiquement WordPress. WordPress lui-même est conservateur, mais l’écosystème ne l’est pas. Les ruptures de compatibilité viennent généralement de :

• Thèmes/plugins anciens qui s’appuyaient sur des comportements dépréciés.
• Hypothèses codées en dur sur les conversions chaîne/tableau.
• Anciennes bibliothèques embarquées dans des plugins (dossiers vendor) qui entrent en collision avec les attentes du PHP moderne.

Et oui, parfois vous pouvez « le faire marcher » sur un vieux PHP en éditant un plugin. C’est aussi comme ça qu’on devient le nouveau mainteneur d’un plugin que vous ne vouliez pas maintenir. Félicitations, vous venez d’adopter un petit animal numérique qui mord.

Faits intéressants et un peu d’histoire (pour comprendre le bazar)

Comprendre pourquoi vous êtes coincé sur un PHP ancien vous aide à décider s’il faut lutter contre votre hébergeur ou le quitter.

1. PHP 7.0 (2015) a été un énorme saut de performance par rapport à PHP 5.x, ce qui explique pourquoi beaucoup d’hébergeurs « ont enfin mis à jour » puis se sont de nouveau installés.
2. WordPress a historiquement supporté des PHP très anciens pour maintenir la longue traîne du web en vie. C’est noble, mais ça transfère la pression sur les auteurs de plugins.
3. PHP 8.0 (2020) a introduit le JIT (compilation just-in-time). Le JIT transforme rarement les charges de WordPress typiques, mais il signale que PHP n’est pas « stagnant ».
4. Les propriétés typées et le comportement de typage plus strict dans PHP 7.4/8.x ont fait disparaître du code approximatif. Beaucoup de plugins « qui fonctionnaient depuis des années » sont morts au contact du PHP moderne.
5. Certaines offres mutualisées figent les versions de PHP parce qu’un module ancien de panneau de contrôle, une intégration de facturation, ou un handler Apache personnalisé en dépend. C’est un choix business, pas une loi technique.
6. Les mises à jour automatiques de WordPress ont changé les attentes : le core et les plugins peuvent bouger vite maintenant, donc le décalage des runtimes fait plus mal qu’il y a dix ans.
7. Composer (gestionnaire de dépendances PHP) est devenu courant, et beaucoup de plugins dépendent maintenant de bibliothèques modernes qui abandonnent explicitement les anciennes versions de PHP.
8. CloudLinux + CageFS sont devenus courants sur l’hébergement mutualisé pour isoler les utilisateurs, et ils incluent souvent un « PHP Selector » qui peut exécuter plusieurs versions. Si votre hébergeur n’a pas ça, c’est un indice sur sa maturité.
9. Les audits PCI et sécurité signalent de plus en plus les runtimes EOL indépendamment de votre ressenti. La conformité ne s’occupe pas des impressions.

Arbre de décision : mettre à jour, isoler ou migrer

Voici la vérité franche : si votre hébergement ne peut pas exécuter des versions PHP supportées, vous payez pour une machine à remonter le temps. Parfois c’est acceptable pour un site d’archives. Ce n’est pas acceptable pour tout ce qui traite des paiements, stocke des données personnelles ou a besoin de mises à jour de plugins.

Option A (préférée) : Mettre à niveau PHP là où il est

Faites cela lorsque :

• Vous contrôlez le serveur (VPS/dédié/cloud).
• Votre hébergeur mutualisé propose un sélecteur de version PHP par site.
• Vous pouvez mettre en scène et revenir en arrière.

Une bonne mise à niveau est ennuyeuse. L’ennui est l’objectif.

Option B : Isoler le site (conteneur/VM) sans changer l’hébergeur

Faites cela lorsque :

• Votre hébergeur est dépassé mais vous ne pouvez pas bouger immédiatement (contrats, bureaucratie, ou « la personne avec les identifiants est en vacances »).
• Vous pouvez placer le site derrière un reverse proxy et exécuter un PHP moderne ailleurs.

Cela ajoute des composants, mais peut acheter du temps en toute sécurité.

Option C : Migrer vers un hébergeur qui n’est pas resté en 2019

Faites cela lorsque :

• L’hébergeur ne peut pas fournir PHP 8.1/8.2/8.3 aujourd’hui.
• Vous ne pouvez pas exécuter plusieurs versions.
• Le support vous conseille « d’utiliser une ancienne version du plugin ».

Si la plateforme ne peut pas patcher, elle ne peut pas être fiable pour la production. Ce n’est pas dur ; c’est la réalité opérationnelle.

Petite blague #1 : Exécuter un PHP en fin de vie en production, c’est comme stocker des sauvegardes sur le même disque — techniquement ça existe, spirituellement non.

Tâches pratiques avec commandes (et comment décider selon la sortie)

Ci-dessous des tâches concrètes que vous pouvez exécuter sur un VPS ou tout hôte où vous avez un shell. Chaque tâche inclut : commande, sortie exemple, ce que ça signifie et la décision suivante. Si vous êtes en mutualisé sans SSH, vous ferez l’équivalent via un panneau de contrôle ou un ticket support, mais la logique est identique.

Task 1: Check the PHP version used by CLI (baseline sanity)

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov 16 2023 12:01:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

What it means: Your CLI default is PHP 7.4. This may or may not match what the web server uses.

Decision: If the plugin requires 8.1+, you need a newer PHP installed and configured for the web stack, not just CLI.

Task 2: Check what PHP version the web server is serving (the one that matters)

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/7.4.33

What it means: The HTTP response advertises PHP 7.4. Some sites hide this header, but if it’s present it’s a strong hint.

Decision: If this is old, proceed to identify handler (FPM vs mod_php) and upgrade path.

Task 3: If you have WP-CLI, ask WordPress what it sees

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp --info
OS:     Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php7.4
PHP version:    7.4.33
wp-cli version: 2.10.0

What it means: WP-CLI is running under PHP 7.4. That’s useful for troubleshooting, but again: web PHP might differ.

Decision: Treat this as confirmation that your system is old. Now check the web server’s PHP handler.

Task 4: Find whether Apache is using mod_php (common legacy trap)

cr0x@server:~$ apache2ctl -M | grep -E 'php|proxy_fcgi'
 php7_module (shared)

What it means: Apache has mod_php loaded (here as php7_module). That usually ties Apache to a single PHP version.

Decision: Consider migrating to PHP-FPM. It’s the clean way to run multiple versions and reduce coupling.

Task 5: Check PHP-FPM services installed (multi-version readiness)

cr0x@server:~$ systemctl list-units --type=service | grep php | grep fpm
php7.4-fpm.service loaded active running The PHP 7.4 FastCGI Process Manager
php8.2-fpm.service loaded active running The PHP 8.2 FastCGI Process Manager

What it means: You already have PHP 8.2 FPM installed and running. Great—now you just need to point the site at it.

Decision: Prefer switching the vhost to php8.2-fpm for this site. Keep 7.4 temporarily for other sites until migrated.

Task 6: Inspect which FPM socket the site uses (real source of truth)

cr0x@server:~$ grep -R "proxy:unix" -n /etc/apache2/sites-enabled/example.com.conf
42:    SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost/"

What it means: This site is pinned to PHP 7.4 FPM.

Decision: Change it to the 8.2 socket (or 8.1/8.3 as required), reload Apache, and test.

Task 7: Verify installed PHP versions and modules (plugins care about extensions)

cr0x@server:~$ php8.2 -m | egrep 'curl|mbstring|intl|openssl|imagick'
curl
intl
mbstring
openssl

What it means: These extensions are available for PHP 8.2. If a plugin needs imagick and it’s missing, you’ll still break after the version upgrade.

Decision: Install missing extensions before switching production traffic, or switch and accept functional degradation until fixed (usually not acceptable for media-heavy sites).

Task 8: Check for end-of-life PHP packages lingering on Debian/Ubuntu

cr0x@server:~$ apt-cache policy php
php:
  Installed: 2:8.2+93
  Candidate: 2:8.2+93
  Version table:
 *** 2:8.2+93 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

What it means: The meta package is aligned with PHP 8.2. That’s good, but doesn’t guarantee your vhost uses it.

Decision: Confirm the FPM pool and web server config. Package state is necessary, not sufficient.

Task 9: Switch an Apache site from PHP 7.4 FPM to PHP 8.2 FPM (surgical change)

cr0x@server:~$ sudo sed -i 's#/run/php/php7.4-fpm.sock#/run/php/php8.2-fpm.sock#g' /etc/apache2/sites-available/example.com.conf
cr0x@server:~$ sudo apache2ctl configtest
Syntax OK
cr0x@server:~$ sudo systemctl reload apache2

What it means: The config is syntactically valid and Apache reloaded without error.

Decision: Immediately run a health check: front page load, wp-admin access, and a PHP info probe (see next tasks). If anything fails, revert quickly.

Task 10: Confirm the site is now served by the new PHP version

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/8.2.15

What it means: Requests now run on PHP 8.2.

Decision: Proceed to functional checks: login, checkout (if ecommerce), cron, and plugin update.

Task 11: Turn on WordPress debugging safely (log, don’t display)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/example.com/public/wp-config.php | head"
87:// define('WP_DEBUG', false);

What it means: Debug is not explicitly set (or is commented). You can enable logging without exposing errors to visitors.

Decision: Enable WP_DEBUG_LOG and keep WP_DEBUG_DISPLAY off. Then reproduce the failure and read logs.

Task 12: Watch PHP-FPM and web logs during a test request (best signal)

cr0x@server:~$ sudo tail -f /var/log/php8.2-fpm.log /var/log/apache2/error.log
[27-Dec-2025 10:11:07] NOTICE: ready to handle connections
[Sat Dec 27 10:11:14.282910 2025] [proxy_fcgi:error] [pid 21234] [client 203.0.113.10:53122] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /var/www/example.com/public/wp-content/plugins/legacy-db/legacy.php:41'

What it means: A legacy plugin uses mysql_connect(), removed long ago. This is not a “PHP 8 bug.” It’s a plugin that should’ve been retired.

Decision: Disable or replace the plugin. If it’s critical, you may need to keep this site on older PHP temporarily—then schedule remediation or migration. Do not keep payments on this setup.

Task 13: Disable a broken plugin without wp-admin (safest emergency lever)

cr0x@server:~$ cd /var/www/example.com/public/wp-content
cr0x@server:/var/www/example.com/public/wp-content$ sudo mv plugins/legacy-db plugins/legacy-db.disabled

What it means: WordPress will stop loading that plugin because it’s no longer in the expected directory.

Decision: If the site recovers, you’ve confirmed root cause. Replace the plugin or refactor functionality. If the site doesn’t recover, keep checking logs; multiple failures can stack.

Task 14: Check database connectivity and version quickly (some hosts break this during migrations)

cr0x@server:~$ mysql --version
mysql  Ver 8.0.36 for Linux on x86_64 (MySQL Community Server - GPL)

What it means: You’re on MySQL 8.0, which is generally fine. If you were on very old MySQL, some plugins might also complain.

Decision: If PHP is upgraded but errors persist, confirm database driver extensions (mysqli, pdo_mysql) and credentials.

Task 15: Validate WordPress cron behavior after PHP change (silent failure mode)

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp cron event list --fields=hook,next_run --allow-root | head
action_scheduler_run_queue  2025-12-27 10:15:00
wp_version_check            2025-12-27 12:00:00
wp_update_plugins           2025-12-27 12:00:00

What it means: Cron events exist. That doesn’t prove execution, but it’s the first check.

Decision: If scheduled tasks stop running after an upgrade (common when switching to a different PHP binary), configure a real system cron calling the right PHP/WP-CLI, or fix the web cron endpoint access.

Task 16: Snapshot before major changes (filesystem snapshot on modern storage)

cr0x@server:~$ sudo zfs snapshot tank/www@example.com@pre-php82
cr0x@server:~$ sudo zfs list -t snapshot | grep pre-php82
tank/www@example.com@pre-php82  0B  -  240G  -

What it means: You have an instantaneous snapshot. Rollback is now a command, not a prayer.

Decision: Proceed with the upgrade. If it goes sideways, you can revert fast. If you don’t have snapshots, emulate them with backups and a staging clone.

Petite blague #2 : Si vous mettez à jour PHP un vendredi après-midi, le week-end aussi sera mis à jour — en week-end de travail.

Voies de mise à niveau selon le type d’hébergement

Hébergement mutualisé (cPanel, Plesk, « panneau personnalisé »)

C’est le champ de bataille le plus courant pour « le plugin exige un PHP plus récent ». Vous avez souvent un contrôle limité, mais pas nul.

• Recherchez un sélecteur PHP par domaine. Si vous pouvez choisir PHP 8.1/8.2 par site, votre problème est résolu en 10 minutes. Faites-le d’abord en staging si l’hébergeur le propose.
• Si la version la plus récente disponible est toujours ancienne, escaladez. Demandez au support quel est leur calendrier pour PHP 8.2/8.3, et s’ils peuvent l’activer pour votre compte. Leur réponse vous dira s’il faut migrer.
• Méfiez-vous des déclarations « nous avons PHP 8.x » qui ne concernent que le CLI. Certains hébergeurs fournissent plusieurs CLI mais verrouillent le handler web sur une version.

Avis : si votre hébergeur ne peut pas offrir une version PHP supportée aujourd’hui, commencez à planifier un déménagement. Ne discutez pas pendant des mois en ignorant les mises à jour de sécurité.

Hébergement WordPress managé

Les plateformes managées effectuent typiquement des déploiements phasés et fournissent un sélecteur de version PHP. Votre travail :

• Utilisez leur environnement de staging, pas la production, pour le premier changement.
• Confirmez qu’ils conservent les anciennes versions PHP seulement temporairement ; vous ne voulez pas d’une plateforme qui traite l’EOL comme optionnel.
• Vérifiez s’ils contrôlent aussi le caching d’objets, le caching de pages et les règles WAF — cela peut changer le comportement lors de la mise à niveau de PHP.

VPS / serveur dédié (vous possédez le bazar, et aussi la solution)

Bonne nouvelle : vous pouvez résoudre correctement le problème. Mauvaise nouvelle : vous pouvez aussi résoudre incorrectement, et vous serez celui qui reçoit les alertes.

• Préférez PHP-FPM plutôt que mod_php. Il découple le serveur web et permet des pools par site.
• Installez plusieurs versions si vous hébergez plusieurs sites, puis migrez site par site.
• Verrouillez les changements de configuration sur un seul vhost d’abord. Ne faites pas un « apt upgrade » global en espérant que tout ira bien.

Déploiements conteneurisés / Kubernetes

Si vous déployez déjà WordPress en conteneurs, le runtime n’est qu’un tag d’image. Ça a l’air simple — et ça l’est — jusqu’à ce que le stockage persistant et les workflows de mise à jour de plugins entrent en jeu.

• Construisez ou récupérez une image avec la version PHP requise.
• Déployez en staging avec le même dump de base de données et un snapshot des uploads.
• Assurez-vous que votre volume persistant supporte des snapshots atomiques (ou des backups cohérents). Sinon, le rollback est pénible.

Trois mini-récits du monde corporate

Mini-récit #1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait un site WordPress qui semblait simple : un site marketing avec blog, quelques pages et une intégration de formulaire. Il était hébergé sur un VPS « que personne ne touchait », ce qui en langage corporate signifie « personne n’en est propriétaire ».

Un développeur a mis à jour un plugin de formulaires pour corriger une vulnérabilité. Le plugin a commencé à exiger PHP 8.1. Le serveur était en PHP 7.4. L’hypothèse était : « L’OS étant à jour, PHP doit l’être aussi. » L’OS était à jour. PHP ne l’était pas. Apache était toujours lié à l’ancien socket FPM, et les nouveaux paquets avaient été installés mais non utilisés.

Le site est entré dans une boucle d’erreurs fatales, mais seulement sur certaines pages — celles qui chargeaient le nouveau chemin de code du plugin. Cela a retardé le diagnostic parce que la page d’accueil fonctionnait encore et que tout le monde a discuté du caractère « intermittent ».

Le SRE d’astreinte a fait la chose qui a fait gagner du temps : il a arrêté les débats et taillé les logs en reproduisant la requête. Le message d’erreur était embarrassant de précision : le plugin refusait de s’exécuter sur PHP 7.4.

La correction n’a pas été héroïque : basculer le vhost sur PHP 8.2 FPM, désactiver un plugin ancien qui utilisait des fonctions mysql supprimées, puis réactiver les fonctionnalités une par une. Le postmortem a porté sur la propriété : la version du runtime est une dépendance, et les dépendances ont besoin d’un propriétaire. « Personne ne le touchait » n’est pas une stratégie.

Mini-récit #2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait moins de composants mobiles. Ils avaient Apache avec mod_php parce que « c’est plus rapide » et « on n’a pas besoin de daemons supplémentaires ». Quelqu’un a lu un vieux benchmark et a décidé que PHP-FPM était une complexité inutile. Ils ont aussi consolidé plusieurs sites WordPress sur une même machine pour réduire les coûts.

Puis un site a eu besoin d’une extension WooCommerce moderne nécessitant PHP 8.2. Un autre site avait un thème legacy qui cassait sur PHP 8.x à cause d’avertissements stricts de typage promus en exceptions par un handler d’erreur personnalisé.

Avec mod_php, ils avaient exactement une version PHP pour tout le monde. Leur « optimisation » a supprimé la possibilité de migrer de façon incrémentale. Ils ont été forcés à une mise à jour en big-bang : basculer PHP pour tous les sites d’un coup ou tout garder ancien. Ils ont choisi de basculer.

La moitié des sites ont cassé de façons subtiles : les formulaires de contact ont cessé d’envoyer, le traitement d’images a échoué parce qu’Imagick n’était pas compilé pour le nouveau PHP, et les tâches planifiées mouraient silencieusement. Les tickets support ont afflué, et l’équipe a passé une semaine en triage d’urgence au lieu d’une migration planifiée.

Ils sont finalement passés à PHP-FPM, pools par site, et un déploiement canari basique. La leçon n’était pas « ne jamais optimiser ». C’était « n’éliminez pas l’isolation ». En production, l’isolation est de la performance. C’est la performance des humains sous pression.

Mini-récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée utilisait WordPress pour un portail de documentation. Pas glamour, mais public et audité. Leur équipe infra avait une politique ennuyeuse : chaque changement passe par le staging, et le staging reflète la production autant que possible. Même version PHP, même config serveur web, mêmes règles de caching. Ils prenaient aussi des snapshots filesystem et base de données avant les changements runtime.

Quand une mise à jour de plugin a commencé à exiger PHP 8.1, ils n’ont pas paniqué. Ils ont cloné la production sur staging depuis le snapshot de la nuit précédente, basculé le staging sur PHP 8.2, et exécuté un plan de test scripté : login, recherche, rendu de page, upload de fichier, et workflows spécifiques au plugin.

Ils ont trouvé un problème : un mu-plugin personnalisé utilisait des fonctions dépréciées qui étaient maintenant des warnings. En production, les warnings étaient promus en erreurs par un handler strict. Cela aurait provoqué une outage sévère si découvert en live.

Ils ont corrigé le mu-plugin, relancé les tests et programmé la bascule en production. Lors du cutover réel, ils ont surveillé logs et métriques, et avaient un plan de rollback basé sur revert de snapshot et le switch des sockets FPM. Ils n’ont jamais utilisé le rollback, ce qui est le but.

Ce qui les a sauvés n’était pas du génie. C’était de l’ennui : un workflow reproductible, des snapshots, et refuser de traiter la production comme un bac à sable. Si vous voulez moins d’incidents, il vous faut plus d’ennui.

Erreurs courantes : symptôme → cause racine → correction

C’est là que la plupart des équipes perdent du temps. Les symptômes ressemblent à du drame WordPress, mais les causes racines sont presque toujours prévisibles.

1) Symptom: “Plugin requires PHP 8.1” message in wp-admin

• Cause racine : Le runtime du site est plus ancien que la version minimale du plugin.
• Correction : Mettre à jour le runtime PHP utilisé par le serveur web. Confirmer via headers/logs. Ne mettez pas à jour seulement le PHP CLI.

2) Symptom: White screen or “There has been a critical error” after plugin update

• Cause racine : Erreur fatale due à une incompatibilité de version PHP ou à une extension manquante.
• Correction : Vérifier les logs web et PHP-FPM. Désactiver le plugin en renommant son dossier, puis mettre à niveau PHP ou installer l’extension manquante.

3) Symptom: Site works for visitors but wp-admin is broken (or vice versa)

• Cause racine : Différents chemins de code, chargement de plugins différent, ou cache masquant les échecs.
• Correction : Contourner le cache et reproduire en tailant les logs. Tester front-end et admin après le changement de PHP.

4) Symptom: After upgrading PHP, media uploads fail or thumbnails stop generating

• Cause racine : Bibliothèques d’image manquantes (GD/Imagick) pour la nouvelle version PHP, ou problèmes de permissions sur uploads.
• Correction : Installer l’extension pour le nouveau PHP et redémarrer FPM. Vérifier avec php -m sous la bonne version.

5) Symptom: Random 502/504 errors after switching to PHP-FPM

• Cause racine : Mauvaise configuration du pool FPM, permissions du socket, pm.max_children trop bas, ou timeouts.
• Correction : Vérifier les logs d’erreur pour « connect() to unix socket failed » vs « upstream timed out ». Corriger les permissions ou ajuster les limites du pool selon le trafic réel.

6) Symptom: “Call to undefined function” after upgrade

• Cause racine : Plugin/thème utilisant des fonctions supprimées/dépréciées ; ou l’extension PHP requise n’est pas activée.
• Correction : Identifier la fonction : si c’est une fonction d’extension, installer/activer l’extension. Si c’est un comportement noyau supprimé, remplacer le plugin/thème.

7) Symptom: wp-cron stops, scheduled posts don’t publish, ecommerce jobs stall

• Cause racine : Cron dépend des requêtes web ; après les changements, les requêtes loopback échouent, ou le cron système appelle le mauvais binaire PHP.
• Correction : Configurer un cron système appelant WP-CLI avec la bonne version PHP ; vérifier la connectivité loopback et les règles de pare-feu.

8) Symptom: You upgraded PHP but the plugin still claims it’s old

• Cause racine : Vous avez mis à jour un PHP (CLI) mais le handler web pointe toujours vers l’ancien ; ou plusieurs runtimes PHP existent et le site est verrouillé.
• Correction : Localiser le handler (socket FPM, module Apache, fastcgi_pass Nginx) et le basculer. Confirmer avec les headers et phpinfo.

Listes de contrôle / plan étape par étape

Ceci est le plan que je lancerais en tant que SRE supportant WordPress : drame minimal, réversibilité maximale.

Checklist A: Before you touch production

1. Lisez l’exigence du plugin. Version PHP minimale, extensions requises, et notes sur la version de WordPress.
2. Faites l’inventaire de votre runtime. Quelle version PHP est utilisée par le web ? Quel est le CLI ? Sont-ils différents ?
3. Listez les flux critiques. Login, checkout, formulaires de contact, upload média, édition admin, purge de cache, tâches cron.
4. Rendez le rollback réel. Snapshot du filesystem + base de données, ou au moins une sauvegarde que vous avez testée en restauration.
5. Construisez un clone de staging. Même style de handler PHP, même couche de cache, même approche de configuration.

Checklist B: Staging upgrade flow (recommended even for “small” sites)

1. Cloner la production vers le staging (fichiers + base).
2. Basculer le staging vers la version PHP cible (8.1/8.2/8.3).
3. Installer les extensions PHP requises sur le staging.
4. Effectuer la mise à jour du plugin en staging d’abord.
5. Exercer les flux critiques et tailler les logs.
6. Corriger ou remplacer tout plugin/thème incompatible.
7. Noter précisément les modifications effectuées (diffs de config, paquets installés).

Checklist C: Production cutover with minimal downtime

1. Choisissez une fenêtre calme. Même les changements « sans downtime » comportent un risque, et le risque est plus faible quand le trafic est bas.
2. Appliquez les mêmes changements runtime que sur le staging. Ne improvisez pas.
3. Reload plutôt que restart, quand c’est possible. Recharger la config du serveur web réduit la disruption.
4. Exécutez des checks de santé immédiatement. Page d’accueil, wp-admin, et un workflow spécifique au plugin.
5. Surveillez les logs pendant 15–30 minutes. Beaucoup d’échecs n’apparaissent qu’après le démarrage des jobs en arrière-plan.
6. Ensuite seulement, mettez à jour le plugin en production (si vous ne l’avez pas déjà fait et si la politique l’autorise).

Checklist D: If you cannot upgrade PHP on the host

1. Arrêtez la mise à jour du plugin. Gardez la version actuelle si elle n’est pas vulnérable.
2. Évaluez le risque : si la mise à jour visait une correction de sécurité, considérez que vous êtes désormais sous contrainte temporelle.
3. Choisissez une stratégie de confinement :
   • Déplacez le site vers un nouvel hébergeur qui supporte PHP moderne.
   • Montez un nouveau VPS et migrez le DNS.
   • Placez un reverse proxy en frontal et exécutez WordPress ailleurs.
4. Rendez la migration ennuyeuse. Fichiers, base, configurations, et un plan de cutover avec rollback (TTL DNS, snapshot, mode maintenance).

Comment penser la sécurité : compatibilité, sécurité et rollback

Le pire état d’esprit est « mettre à jour PHP fait peur ». Le second pire est « mettre à jour PHP ne change rien ». Traitez-le comme toute mise à jour de runtime : cela change le comportement, la gestion des erreurs, les caractéristiques de performance, et parfois la disponibilité de bibliothèques.

Voici le cadrage opérationnel qui fonctionne :

• Le risque de compatibilité concerne surtout les plugins/thèmes anciens. Inventoriez-les et retirez-les. Si quelque chose n’a pas été mis à jour depuis des années, ce n’est pas « stable », c’est abandonné.
• Le risque de sécurité augmente avec le temps. Une version PHP ancienne n’est pas seulement plus lente ou moins jolie ; c’est une responsabilité. Les hébergeurs backportent parfois des correctifs, mais exigez de la clarté : quoi est patché, et à quelle vitesse ?
• Le rollback doit être mécanique. Si le rollback c’est « on tentera d’annuler », ce n’est pas un rollback. C’est de l’improvisation.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : vous construisez des systèmes fiables en vous attendant aux pannes et en concevant la récupération, pas en espérant que rien ne casse.

Ce qu’il faut éviter (opinions tranchées, acquises à la dure)

• Ne modifiez pas le code vendor/plugin pour « le rendre compatible ». Vous l’oublierez, les mises à jour automatiques l’écraseront, et le prochain incident sera de votre faute.
• Ne faites pas de changements en production sans logs. Si vous ne voyez pas les erreurs PHP-FPM et serveur web, vous déboguez les yeux bandés.
• Ne gardez pas l’e-commerce sur un runtime EOL. Si de l’argent change de mains, la cadence de patch fait partie du produit.
• Ne supposez pas « l’hébergeur s’en chargera ». Certains le feront. Beaucoup ne le feront pas. Vérifiez.
• Ne confondez pas « WordPress le supporte » avec « les plugins le supportent ». Votre vraie plateforme est l’écosystème que vous avez installé.

FAQ

1) Puis-je simplement installer une ancienne version du plugin ?

Vous pouvez, parfois. C’est une solution temporaire, pas une correction. Si le plugin a abandonné les anciennes versions de PHP pour des raisons de sécurité ou de dépendances, bloquer une ancienne version peut vous laisser exposé. N’utilisez ceci que pour gagner du temps pendant que vous mettez à jour PHP ou migrez.

2) Si je mets à jour PHP, le core WordPress va-t-il casser ?

WordPress moderne fonctionne généralement bien sur PHP 8.1/8.2/8.3. Les cassures proviennent le plus souvent de thèmes/plugins anciens ou de code personnalisé. C’est pourquoi le staging est important : il vous indique quelle dépendance pose problème avant que les utilisateurs ne le remarquent.

3) Mon hébergeur dit « nous supportons PHP 8 », mais le plugin se plaint encore. Pourquoi ?

Parce que « supporter » peut signifier « disponible pour certains comptes », « disponible pour le CLI », ou « disponible si vous changez un sélecteur par site ». Confirmez le runtime utilisé par le serveur web, pas seulement ce qui est installé.

4) Quelle version PHP devrais-je cibler maintenant ?

Ciblez une version PHP actuellement supportée proposée par votre distribution/hébergeur — typiquement PHP 8.2 ou 8.3. Si le plugin exige 8.1, ne vous arrêtez pas à 8.1 sans raison ; vous devrez répéter l’exercice bientôt.

5) Comment mettre à jour PHP sans downtime ?

Exécutez plusieurs versions PHP-FPM, changez le socket upstream du site, et rechargez le serveur web. C’est généralement un changement quasi instantané. Le vrai risque de downtime vient de l’incompatibilité applicative, que le staging et les snapshots atténuent.

6) Et si un autre site sur le même serveur a besoin d’un PHP ancien ?

Alors vous voulez PHP-FPM avec plusieurs pools/versions et une configuration par vhost. Si vous êtes coincé sur mod_php, vous vous êtes enfermé. Migrez les sites legacy ou isolez-les dans une VM/conteneur séparé.

7) Mettre à jour PHP suffit-il, ou faut-il aussi mettre à jour MySQL/MariaDB ?

Généralement, PHP est le blocage pour l’erreur de plugin. Mais tant que vous y êtes, vérifiez les versions de base de données et les extensions. Certains plugins modernes supposent un MySQL/MariaDB plus récent, notamment sur les jeux de caractères et les modes SQL stricts.

8) Le site fonctionne après la mise à jour PHP, mais les performances se sont dégradées. Que s’est-il passé ?

Causes courantes : OPcache non activé/configuré pour le nouveau PHP, limites de pool FPM trop basses, ou couches de cache se comportant différemment. Vérifiez l’état d’OPcache et tunez FPM plutôt que de blâmer aveuglément la version PHP.

9) Je n’ai pas d’accès SSH. Que puis-je faire ?

Utilisez le panneau de contrôle d’hébergement pour changer la version PHP si disponible, et utilisez Santé du site WordPress pour confirmer le changement. Si l’hébergeur ne peut pas fournir un runtime PHP moderne, migrez. L’absence de SSH n’est pas fatale ; l’absence de runtimes supportés l’est.

Étapes suivantes que vous pouvez entreprendre aujourd’hui

Voici une séquence pratique qui fonctionne dans le monde réel :

1. Confirmez la version PHP réelle utilisée par le serveur web. Ne faites pas confiance au tableau de bord marketing ; faites confiance aux headers et aux logs.
2. Choisissez la voie la plus propre : mettre à jour sur place si possible, isoler si nécessaire, migrer si recommandé.
3. Faites du staging. Clonez, changez PHP, mettez à jour le plugin, testez les flux monétaires et admin.
4. Rendez le rollback mécanique. Snapshots ou backups testés. Pas de « on se souviendra de ce qu’on a changé ».
5. Coupez et surveillez. Logs, cron et taux d’erreur pendant au moins 15–30 minutes.
6. Puis nettoyez. Supprimez les plugins abandonnés, documentez le handler PHP, et planifiez des revues périodiques des runtimes pour éviter d’être surpris à nouveau.

Si votre hébergeur ne peut pas fournir des versions PHP supportées, ne négociez pas avec la physique. Déménagez. Les systèmes de production ne s’améliorent pas par voeu pieux ; ils s’améliorent par propriété et changements reproductibles.