WordPress sur une vieille version de PHP : risque réel
PHP 7.0 ou 7.2 n'est plus une question de performance : les failles ne sont plus patchées. Après le nettoyage, monter PHP fait partie de la fermeture, pas d'un « on verra au prochain devis ».
PHP 7.0 ou 7.2 n'est plus une question de perf : les failles ne sont plus patchées. Après nettoyage, monter PHP fait partie de la fermeture, pas d'un « plus tard ».
Ce que « plus supporté » veut dire
Plus de correctifs de sécurité officiels. Les bots ont des années de CVE PHP. Un WordPress à jour sur un PHP mort reste une surface. Ce n'est pas du marketing de l'hébergeur.
Les versions mortes se voient dans phpinfo, le panel, ou `php -v`. Notez-la au constat. Un incident sur 7.2 n'étonne personne.
PHP 7.0 / 7.2 / 7.4 : plus de correctifs officiels. Les bots ont des années de CVE moteur. Un WordPress à jour sur un PHP mort reste une surface. Notez la version au constat (`php -v` ou le panel). Ne montez pas PHP le soir de l'infection : vous mélangez les 500 d'incompatibilité et les 500 du malware. D'abord site lisible et propre, puis la montée sur un créneau, avec copie. Un plugin pirate encodé pour 7.2 qui casse en 8.x : tant mieux, vous le voyez.
Notez aussi l'extensions chargées (`php -m`) : un vieux ionCube, un suhosin, un idn. Ils bloquent parfois la 8.x autant que le thème. L'hébergeur qui « laisse 7.2 » le fait pour ne pas casser les comptes ; ce n'est pas un avis de sécurité. Votre constat peut mentionner la version comme facteur de récidive.
Après le hack, pas pendant le bazar
Monter PHP le soir de l'infection mélange les 500 (incompatibilité) et les 500 (malware). D'abord site lisible et propre, puis la montée sur un créneau, avec copie. Supprimer malware.
Un plugin pirate peut « marcher » seulement en 7.2 (vieux ionCube). La montée le casse : tant mieux, vous le voyez.
Sur un mutualisé, le sélecteur PHP se change en un clic. Faites-le après le clean, en heures creuses, avec une copie. Prévenez si un checkout tourne. Un 500 post-montée se lit dans le journal PHP : le fichier cité est presque toujours un plugin, pas « Google qui punit ».
Monter PHP le soir de l'infection mélange les 500. D'abord site lisible et propre. Un plugin pirate qui ne tourne qu'en 7.2 : la montée le casse, tant mieux.
Plugins qui bloquent la montée
Anciens page builders, vieux modules Woo, thèmes 2016. Inventaire : lesquels déclarent PHP max 7.4. Remplacez avant, ou acceptez de les perdre. Garder PHP 7.2 « pour un plugin de slider » est le mauvais arbitrage.
Les nulled encodés : souvent bloqués. Autre raison de sortir. Thème nulled.
Inventoriez les plugins qui déclarent un PHP max dans leur readme. Ceux-là se remplacent avant la montée, pas après trois jours de site cassé. Les nulled ionCube sont les premiers à mourir : autre raison de les sortir, pas de rester en 7.2.
7.4, 8.1, 8.2 : viser le supporté
PHP 7.4 est déjà en fin de vie. Visez une 8.x que votre hébergeur patche encore. WordPress actuel tourne en 8.2/8.3. Testez en staging si vous en avez un — un staging oublié est une autre porte, à jour aussi.
Régressions à tester
Front, wp-admin, checkout, cron, formulaires. Les 500 dans le journal PHP après la montée : un plugin, pas « Google ». Rollback PHP possible le temps de patcher ce plugin — pas rollback vers 7.2 pour toujours.
Les 500 post-montée : ouvrez le journal avant de rollback. Le fichier cité (souvent un plugin) se met à jour ou sort. Rollback PHP une heure, pas un mois. Le checkout se teste avec une commande 1 € annulée, pas seulement la home.
L'hébergeur qui « laisse 7.2 »
Certains mutualisés gardent des sélecteurs anciens. Ce n'est pas une bénédiction. Changez le sélecteur. S'ils ne peuvent pas : c'est un critère de migration, après le clean, pas avant avec un site sale.
Si l'hébergeur ne propose plus que 7.3 « pour compatibilité », c'est un critère de migration — après le site propre. Copier un site sale sur un PHP 8.3 neuf recommence l'histoire avec une meilleure vitrine.
PHP et les scanners
Un Wordfence vert sur PHP 7.0 ne dit rien des failles du moteur. Autre couche. Wordfence limites.
Fermer la fenêtre
PHP supporté + WP à jour + moins de plugins = la fermeture. WP pas à jour.
Visez une 8.x que l'hébergeur patche encore. Tester front, admin, checkout, cron. Rollback PHP le temps de patcher un plugin, pas rollback vers 7.2 pour toujours. Garder 7.2 « pour un slider » est le mauvais arbitrage. WP pas à jour. Créer un espace.
ionCube, staging, et Safe Browsing
ionCube qui « empêche » la 8.2 : mettez à jour l'encodeur ou sortez du plugin. Ne restez pas en 7.2 pour ça. Un staging oublié sur PHP 7.2 est une autre porte — mettez-le à jour aussi, ou fermez-le. La montée PHP ne lève pas Safe Browsing : ça ferme des failles futures. Blacklist.
Multisite : un PHP pour tous. Testez Woo d'abord. Un thème « PHP 7.2 required » en 2026 est un abandon : changez de thème. Thème nulled si le zip n'est pas officiel.
Wordfence vert sur PHP 7.0 ne dit rien des failles du moteur. Wordfence limites. Créer un espace.
Fenêtre de montée : samedi matin, pas vendredi 18 h
Copie. Inventaire plugins bloquants. Staging si possible. Sélecteur 8.2/8.3. Test front, admin, checkout, cron, un formulaire. Journal PHP ouvert. Rollback d'une heure si un plugin casse, ticket à l'éditeur, pas rollback vers 7.2 « pour toujours ». Prévenez si la boutique ferme une heure.
Le thème « required 7.2 » sort. ionCube à jour ou dehors. Staging oublié : même PHP ou extinct. WP pas à jour. Créer un espace.