Le 31 décembre 2026, PHP 8.2 cessera de recevoir des correctifs de sécurité. Environ un site WordPress sur quatre tourne aujourd’hui sur cette version. Fin septembre 2026, WooCommerce a fixé sa propre échéance : à partir de février 2027, le plugin exigera PHP 8.1 au minimum, alors que WordPress se contente encore de PHP 7.4.
La version de PHP est le moteur sous le capot de chaque site WordPress. Personne ne la voit, et c’est précisément pour cela qu’elle vieillit en silence. Un site peut fonctionner des années sur une version que plus personne ne corrige, jusqu’au jour où une mise à jour de plugin refuse de s’installer.
La réponse courte tient en une ligne : en octobre 2026, visez PHP 8.3 ou 8.4. PHP 7.4 fonctionne encore avec WordPress, mais il ne reçoit plus aucun correctif depuis près de quatre ans.
Ce guide suit une méthode simple : connaître le calendrier, tester la compatibilité, puis basculer en passant par une copie de recette.
La réponse courte : quelle version de PHP en octobre 2026
Minimum, recommandation, et le 8.4 du manuel des hébergeurs
WordPress exige PHP 7.4 au minimum depuis la version 7.0, sortie le 20 mai 2026. La page officielle des prérequis recommande PHP 8.3 ou plus récent, et précise que WordPress fonctionne encore avec PHP 7.4.
Le manuel destiné aux hébergeurs, maintenu par l’équipe Hosting du projet, va plus loin : il recommande PHP 8.4 ou plus récent pour les environnements de production. Les deux recommandations coexistent et ne se contredisent pas vraiment. La première fixe un plancher confortable, la seconde vise la durée de vie la plus longue.
Pour un site que vous gérez vous-même, PHP 8.3 est un choix sûr, et PHP 8.4 un choix qui vous laisse tranquille plus longtemps. PHP 8.5 est désormais pleinement pris en charge par WordPress 6.9 et suivants.
Ce que « pris en charge » veut dire chez php.net
Chaque branche de PHP vit quatre ans. Pendant deux ans, elle reçoit toutes les corrections de bogues. Pendant deux années supplémentaires, elle ne reçoit plus que les correctifs de sécurité critiques. Puis elle s’arrête.
Depuis une décision de 2024, ces périodes se terminent toutes un 31 décembre, ce qui rend le calendrier facile à retenir. La même réforme a ajouté un an de correctifs de sécurité à toutes les branches encore vivantes, et PHP 8.1 en a profité jusqu’à fin 2025.
Une version arrêtée continue de fonctionner. Elle ne casse rien le 1er janvier. Mais toute faille découverte ensuite restera ouverte, sauf chez les hébergeurs qui proposent un support étendu.
Le calendrier de PHP à garder sous les yeux
Les branches encore vivantes
PHP 8.2 ne reçoit plus que des correctifs de sécurité, et ce jusqu’au 31 décembre 2026. C’est la prochaine branche à disparaître, dans trois mois.
PHP 8.3 est passé en sécurité seule le 31 décembre 2025, et le restera jusqu’au 31 décembre 2027. PHP 8.4 reçoit toutes les corrections jusqu’à fin 2026, puis les seuls correctifs de sécurité jusqu’à fin 2028. PHP 8.5, sorti en novembre 2025, est pleinement maintenu jusqu’à fin 2027, puis corrigé pour la sécurité jusqu’à fin 2029.
PHP 8.6 est en phase de versions candidates, avec une sortie prévue le 19 novembre 2026. Aucune annonce ne dit encore si WordPress 7.2, attendu début décembre, le documentera comme compatible.
Les branches arrêtées
PHP 8.1 ne reçoit plus rien depuis le 31 décembre 2025. PHP 8.0 s’est arrêté en novembre 2023, PHP 7.4 en novembre 2022. Un site sur PHP 7.4 tourne donc depuis près de quatre ans sur un moteur que ses auteurs ne corrigent plus.
L’API que WordPress interroge pour juger la version de PHP du site considère encore PHP 8.1 comme « sûre ». L’absence d’alerte rouge dans l’écran Santé du site ne prouve donc pas que votre version reçoit des correctifs : seul le calendrier de php.net fait foi.
Ce que le cœur de WordPress prend en charge
Le tableau de compatibilité
Le manuel du cœur publie un tableau de compatibilité, mis à jour en août 2026. WordPress 7.0 et 7.1 sont compatibles avec PHP 7.4 à 8.5. WordPress 6.9 accepte PHP 7.2 à 8.5. Les versions 6.7 et 6.8 s’arrêtent à PHP 8.4.
Jusqu’au printemps 2026, les versions récentes de PHP portaient une mention de prise en charge « bêta ». En mai 2026, l’équipe du cœur l’a supprimée, y compris pour les versions passées, parce qu’elle rendait certains propriétaires de sites et hébergeurs réticents à migrer. WordPress 6.9 et 7.0 sont désormais documentés comme pleinement compatibles avec PHP 8.5.
Les sites restés sur PHP 7.2 ou 7.3
Un site sur PHP 7.2 ou 7.3 ne peut pas installer WordPress 7.x. Il reste sur la branche 6.9, qui a reçu sa version 6.9.9 le 22 septembre 2026. Ces correctifs rétroportés restent une courtoisie : officiellement, seule la dernière branche est maintenue.
Depuis WordPress 7.0, l’avertissement du tableau de bord affiché aux sites sous PHP 7.4 ajoute que cette version ne sera bientôt plus prise en charge par WordPress, et un commentaire du code indique que le minimum passera au moins à PHP 8.0, sans date. Notre point sur les nouveautés de WordPress 7 revient sur ce changement de plancher.
Où en sont réellement les sites WordPress
Les statistiques de wordpress.org
WordPress.org publie la répartition des versions de PHP des sites qui interrogent ses serveurs de mises à jour. Le 1er octobre 2026, PHP 8.3 et PHP 8.2 se partagent chacun environ un quart des sites. PHP 7.4 en conserve environ un sixième, contre plus d’un cinquième en janvier.
Le constat d’ensemble est moins flatteur. Plus d’un site sur trois tourne sur une branche que php.net ne corrige plus, et à peine plus d’un sur trois atteint la version recommandée. Les branches encore pleinement maintenues, 8.4 et 8.5, ne dépassent pas un site sur huit.
Lors de la WordCamp US d’août 2026, des contributeurs du cœur ont reconnu que l’adoption piétinait, tout en rappelant que WordPress.com fonctionne déjà sous PHP 8.4.
La règle des 5 %
Le projet ne relève pas son minimum selon un calendrier fixe. Il attend, par tradition, qu’une version de PHP passe sous la barre de 5 % des sites avant de l’abandonner. C’est ce qui s’est produit pour PHP 7.2 et 7.3 au début de 2026.
Cette règle protège les petits sites, mais elle a un effet secondaire : le plancher de WordPress se règle sur les sites les plus en retard. Le minimum officiel indique ce qui fonctionne encore, et seul le calendrier de php.net indique ce qui reste corrigé.
Le cas réel : WooCommerce fixe PHP 8.1 pour février 2027
Pendant que WordPress attend ses 5 %, WooCommerce a pris les devants. L’histoire tient en trois semaines de septembre 2026, documentées par le blog des développeurs de WooCommerce, ses commentaires et son dépôt de code. Elle montre une chose que les tableaux de compatibilité ne disent pas : la version de PHP dont votre site a besoin est fixée par son composant le plus exigeant.
Un précédent en 2023
WooCommerce avait déjà franchi ce pas. En juin 2023, l’équipe annonçait que WooCommerce 8.2, prévu pour octobre, exigerait PHP 7.4. À l’époque, environ 97 % des boutiques récemment mises à jour tournaient déjà sur PHP 7.4 ou plus récent. Les autres pourraient garder WooCommerce 8.1, sans aller plus loin.
La proposition du 8 septembre
Le 8 septembre 2026, Brian Coords publie sur le blog des développeurs une proposition : exiger PHP 8.1 dès WooCommerce 11.5, en janvier 2027, et abandonner PHP 7.4 et 8.0. Les chiffres viennent des boutiques qui partagent volontairement leurs données : environ 7 % sur PHP 7.4, 2 % sur PHP 8.0, et une part en baisse constante.
Le billet détaille aussi ce qui arriverait à une boutique restée sur PHP 7.4. WooCommerce 11.5 déclarerait PHP 8.1 dans son en-tête, WordPress ne proposerait donc pas la mise à jour, et la boutique garderait sa version, avec les correctifs mineurs de sa branche. Rien ne serait désactivé.
Le débat dans les commentaires
Vingt-huit commentaires suivent. Certains demandent de garder PHP 7.4 aussi longtemps que WordPress, en rappelant que plus d’un site WordPress sur six l’utilise encore. Un commentateur qui maintient quelques sites sous PHP 7.4 explique que, lors de son dernier audit, quelques plugins payants pour WooCommerce ne géraient pas encore PHP 8.1. D’autres réclament au contraire un plancher à 8.3 ou 8.4, puisque PHP 8.1 n’est déjà plus maintenu.
Néstor Soriano, ingénieur chez Automattic, répond avec des données : PHP 7.4 et 8.0 réunis pèsent environ 9 % des boutiques suivies, et devraient approcher 5 % à la sortie. Seules 20 % environ des boutiques tournent sur PHP 8.4 ou 8.5. Quand PHP 8.1 approchera à son tour les 5 %, l’équipe envisagera de passer à 8.2.
Un autre commentateur, Clifton Griffin, demande un avertissement qui ne fasse pas peur : la plupart des marchands ignorent sans doute que changer de version de PHP prend quelques minutes dans le panneau de leur hébergeur.
La décision du 29 septembre
Le 29 septembre, la décision tombe, avec un ajustement. L’exigence passe à WooCommerce 11.6, prévu pour février 2027, afin de laisser aux boutiques le temps de tester et de migrer après la haute saison des ventes de fin d’année. Les boutiques sur PHP 7.4 ou 8.0 pourront continuer à mettre à jour jusqu’à la version 11.5.
Le lendemain, le code suit. Une demande de fusion ajoutant à WooCommerce 11.3 un avertissement, que l’administrateur peut masquer, est intégrée le 30 septembre. L’équipe a aussi analysé les 1 357 plugins vendus sur sa place de marché : 0,22 % présentaient des problèmes potentiels avec PHP 8.1, à vérifier à la main. Le billet prévient qu’une analyse de ce type ne garantit pas que chaque plugin ou code sur mesure fonctionnera.
Ce que WooCommerce demande aux marchands
La marche à suivre publiée est concrète. Vérifiez votre version dans WooCommerce, État, Environnement du serveur. Demandez à votre hébergeur PHP 8.3 ou plus récent : 8.1 suffit pour le minimum de WooCommerce 11.6, mais 8.3 est sa recommandation actuelle. Sauvegardez, testez sur une copie, puis basculez la production.
Les tests demandés vont bien au-delà de la page d’accueil : la commande et les moyens de paiement, la livraison et les taxes, la gestion des commandes, les tâches planifiées, le thème, les plugins et le code sur mesure.
Ce qu’il faut en retenir
Une boutique peut faire tourner WordPress 7.1 sous PHP 7.4 aujourd’hui, et se retrouver bloquée sur une ancienne version de WooCommerce en février 2027. Rester sur 11.5 n’est qu’une solution d’attente : la politique de sécurité de WooCommerce ne rétroporte vers les anciennes versions que les failles les plus graves, notées 9 ou plus sur 10.
L’issue finale reste inconnue à ce jour, même si la décision et son calendrier sont arrêtés. Mais la leçon vaut pour tous les sites. Repérez le composant le plus exigeant de votre installation, et prenez sa date comme échéance.
Tester la compatibilité avant de changer
PHPCompatibilityWP, avec la bonne version cible
L’outil de référence pour analyser le code est PHPCompatibility, une règle pour PHP_CodeSniffer, et sa variante PHPCompatibilityWP, qui évite les fausses alertes sur les fonctions que WordPress fournit lui-même. Le cœur de WordPress l’utilise dans ses propres tests.
Attention au piège de version : la dernière version stable de PHPCompatibility date de décembre 2019. La détection des nouveautés de PHP 8, jusqu’à 8.5, se trouve dans les préversions de la série 10.0. Le dépôt de PHPCompatibilityWP indique l’installation par Composer.
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@dev"
vendor/bin/phpcs -p wp-content/plugins/mon-plugin --standard=PHPCompatibilityWP --extensions=php --runtime-set testVersion 8.3-Le paramètre testVersion fixe la cible : 8.3- vérifie que le code fonctionne sous PHP 8.3 et au-delà. Sans lui, l’outil ne signale que les fonctionnalités de PHP obsolètes ou supprimées.
Ce que l’analyse statique ne voit pas
Une analyse sans alerte ne garantit rien. La documentation de WordPress VIP le dit clairement : certaines évolutions ne se manifestent qu’à l’exécution, et le scanner n’est pas conçu pour les repérer. VIP recommande d’y ajouter PHPStan ou Psalm, avec leurs extensions pour WordPress, pour attraper les erreurs de type.
Ces erreurs sont précisément celles que PHP 8 a rendues plus sévères. PHP 8.0 a supprimé create_function() et each(), et changé la comparaison entre chaînes et nombres. PHP 8.1 a rendu obsolète le passage de null aux fonctions natives qui ne l’acceptent pas. PHP 8.2 a fait de même pour les propriétés dynamiques. PHP 8.4 a rendu obsolètes les paramètres implicitement nullables, dont le type acceptant null devrait désormais s’écrire explicitement.
Méfiez-vous aussi du plugin PHP Compatibility Checker, de WP Engine, que la page d’aide de wordpress.org conseille encore. Sa propre fiche annonce qu’il n’est plus maintenu, qu’il ne vérifie la compatibilité que jusqu’à PHP 8.0, et qu’il ignore le code non hébergé sur wordpress.org.
Les journaux et Query Monitor sur la copie de recette
Le test le plus fiable reste l’exécution. Sur la copie de recette, activez le journal de débogage de WordPress, comme le recommande sa documentation, en écrivant les erreurs dans un fichier sans les afficher aux visiteurs.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Les erreurs arrivent alors dans wp-content/debug.log. Le plugin gratuit Query Monitor les affiche aussi page par page, avec les avertissements d’obsolescence, et indique quel plugin ou thème les déclenche. La documentation précise que ces réglages sont destinés à un environnement local ou de recette, pas à la production.
Si vous travaillez en ligne de commande, rappelez-vous que la version de PHP de WP-CLI peut différer de celle qui sert le site. La commande wp cli info affiche la version utilisée par la ligne de commande, et l’onglet Infos de l’écran Santé du site celle du serveur web. Notre sélection de commandes WP-CLI essentielles détaille cet outil.
La procédure de migration, étape par étape
Sauvegarder, cloner, marquer la copie
Commencez par une sauvegarde complète, fichiers et base de données, que vous savez restaurer. Puis créez une copie de recette : la plupart des hébergeurs gérés en proposent une, et des plugins comme WP STAGING ou Duplicator savent cloner un site. Notre comparatif des meilleurs plugins de sauvegarde vous aide à choisir.
Sur la copie, déclarez le type d’environnement. Depuis WordPress 5.5, cette constante permet aux plugins de savoir qu’ils ne sont pas en production, par exemple pour suspendre les envois de courriels ou les paiements réels.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Basculer la copie, tester, puis la production
Changez la version de PHP de la copie seule, dans le panneau de l’hébergeur. Parcourez les parcours qui comptent : connexion, formulaires, recherche, et pour une boutique la commande complète avec un moyen de paiement de test. Lisez ensuite le journal de débogage, puis corrigez ou remplacez ce qui casse.
Quand la copie est propre, basculez la production, de préférence à une heure creuse. Refaites les parcours critiques, consultez l’écran Santé du site, et gardez l’ancienne version de PHP sous la main : la plupart des panneaux permettent de revenir en arrière en quelques clics.
Un dernier conseil : ne changez pas tout le même jour. Une mise à jour de PHP, de WordPress et de dix plugins en une seule fois rend tout incident impossible à attribuer.
Comment un hébergeur procède à grande échelle
SiteGround a raconté en 2024 sa propre migration de PHP 7.4 vers PHP 8.2. Chaque site a d’abord été testé isolément pour vérifier qu’il se chargeait sous PHP 8.2. Les sites sans problème ont été prévenus une semaine avant la bascule.
Le déploiement a commencé par cinq serveurs, puis cinquante, deux cent cinquante, et enfin cinq cents serveurs mutualisés par semaine. Au bout de 88 jours, près de 93 % des sites avaient passé le contrôle sans problème. Les quelque 7 % restants ont été laissés sur PHP 7.4, et leurs propriétaires contactés. La méthode, test isolé puis montée en charge progressive, est la même que pour un seul site.
Changer de version dans le panneau de l’hébergeur
cPanel, Plesk, OVHcloud et hPanel
Dans cPanel, l’outil MultiPHP Manager liste vos domaines : cochez le domaine, choisissez la version dans le menu, puis appliquez. Sous Plesk, la version se règle dans l’onglet PHP de chaque domaine, avec un avertissement qui rappelle que les versions de PHP ne sont pas entièrement compatibles entre elles.
Chez OVHcloud, sur un hébergement mutualisé, le fichier php.ini n’est pas modifiable : la version se choisit dans l’espace client, ou dans le fichier .ovhconfig à la racine de l’hébergement, par la clé app.engine.version. Chez Hostinger, le réglage se trouve dans la configuration PHP du tableau de bord du site, et les nouveaux sites démarrent en PHP 8.3.
Les hébergeurs qui mettent à jour à votre place
Certains hébergeurs gérés changent la version pour vous. Chez Kinsta, les mises à jour automatiques de PHP sont activées par défaut, et un site sur une version arrêtée passe à la dernière version prise en charge. SiteGround applique le même principe avec son option PHP géré, active par défaut, tant que vous n’avez pas choisi une version à la main.
WordPress VIP impose une mise à jour annuelle à ses clients : la production passera à PHP 8.3 le 7 décembre 2026, avant la fin de PHP 8.2. Si votre hébergeur pratique ces bascules, demandez-lui la date et testez votre site avant celle-ci.
Le support étendu, payant
Garder une vieille version a désormais un prix. Au moment où nous écrivons, en octobre 2026, DreamHost facture son support étendu de PHP à partir de 5 dollars par mois pour un site, en précisant qu’il n’améliore pas les performances. IONOS affiche 15,62 dollars par mois pour PHP 7.4 ou 8.0 sur sa page américaine. Chez cPanel et Plesk, les versions arrêtées passent par une licence de support payante de TuxCare. Ces offres achètent du temps, sans régler le problème.
OPcache et JIT : ce qui accélère vraiment PHP
OPcache, le cache qui compte
À chaque requête, PHP doit lire et compiler les fichiers de WordPress. OPcache garde ce code compilé en mémoire et évite ce travail. Il se distingue du cache d’objets, comme Redis, qui garde le résultat des requêtes à la base de données : notre guide du cache d’objets Redis explique la différence.
Depuis WordPress 7.0, l’écran Santé du site vérifie qu’OPcache est actif et le signale s’il ne l’est pas. Depuis PHP 8.5, OPcache fait partie de PHP lui-même, toujours chargé, et il suffit de ne pas le désactiver.
Le manuel des hébergeurs conseille d’en ajuster la mémoire et le nombre de fichiers, et de vider le cache à chaque déploiement si la vérification de date des fichiers est coupée. WordPress invalide lui-même les fichiers qu’il met à jour, depuis la version 5.5.
JIT, une option rarement utile pour WordPress
Le compilateur JIT, apparu avec PHP 8.0, transforme une partie du code en instructions machine. La page de sortie de PHP 8.0 indiquait elle-même que les applications courantes n’en tirent pas de gain notable face à PHP 7.4 : JIT sert surtout les calculs intensifs et les processus longs. Il n’a jamais été actif par défaut : avant PHP 8.4, sa mémoire réservée valait zéro, et depuis PHP 8.4 le réglage opcache.jit vaut « disable ».
Ce que rapporte une version récente
Les gains de vitesse existent, mais ils sont modestes. Kinsta a mesuré une installation WordPress par défaut : environ 6,6 % de requêtes en plus par seconde entre PHP 7.4 et PHP 8.5. Sur une page de produits WooCommerce, PHP 8.2 servait environ 23 % de requêtes en plus que PHP 7.4.
Le même test montre un bond bien plus fort sous PHP 8.5, mais avec une page environ 38 % plus légère (53,5 Ko contre 86,8 Ko), que Kinsta attribue à des changements de structure de la réponse. Ce chiffre ne mesure donc pas le moteur. Changer de version de PHP sert d’abord à rester corrigé, et la vitesse vient en prime.
Tableau récapitulatif
| Version de PHP | Statut chez php.net | WordPress 7.1 | WooCommerce 11.6 | Verdict |
|---|---|---|---|---|
| 7.4 et 8.0 | Arrêtées | Compatible | Non | À quitter sans attendre |
| 8.1 | Arrêtée fin 2025 | Compatible | Minimum | À quitter |
| 8.2 | Sécurité jusqu’à fin 2026 | Compatible | Oui | Migration à planifier |
| 8.3 | Sécurité jusqu’à fin 2027 | Recommandée | Recommandée | Choix sûr |
| 8.4 | Active, sécurité jusqu’à fin 2028 | Recommandée | Oui | Meilleur choix de production |
| 8.5 | Active, sécurité jusqu’à fin 2029 | Recommandée | Oui | Possible, après test des plugins |
Questions fréquentes
Puis-je rester sur PHP 7.4 ?
WordPress 7.1 l’accepte encore, mais PHP 7.4 ne reçoit plus de correctifs depuis novembre 2022, WordPress prévient déjà qu’il ne la prendra bientôt plus en charge, et WooCommerce l’abandonne en février 2027. Rester sur 7.4 revient à repousser une migration qui deviendra plus difficile.
PHP 8.5 est-il sûr pour WordPress ?
Le cœur le prend pleinement en charge depuis WordPress 6.9, et la mention bêta a disparu en mai 2026. Le risque vient des plugins et thèmes : testez-les sur une copie avant de basculer.
Passer à PHP 8 accélère-t-il mon site ?
Un peu. Les mesures publiées montrent quelques pour cent sur une installation standard, davantage sur certaines pages WooCommerce. Pour la vitesse, vérifiez d’abord OPcache, le cache de pages et le cache d’objets.
Mon hébergeur peut-il changer de version sans me demander ?
Oui, chez certains hébergeurs gérés, dont Kinsta et SiteGround, quand l’option est active. SiteGround et WordPress VIP ont annoncé leurs bascules à l’avance. Demandez leur politique, et testez votre site avant la date annoncée.
Que faire si un plugin casse après le changement ?
Revenez à l’ancienne version de PHP dans le panneau, lisez le journal de débogage pour identifier le plugin, puis cherchez une mise à jour ou un remplaçant. Vérifiez aussi la date de sa dernière mise à jour : un plugin qui ne suit plus les versions de PHP mérite d’être remplacé.
Faut-il activer JIT ?
Pour un site WordPress, rarement. JIT aide les calculs intensifs, pas les pages web ordinaires, et il n’est pas actif par défaut. Vérifiez plutôt qu’OPcache est actif et bien dimensionné.
Conclusion
La bonne version de PHP est la plus récente que vos plugins supportent, dans la limite du calendrier de php.net, bien au-dessus du minimum de WordPress. En octobre 2026, cela veut dire PHP 8.3 au moins, PHP 8.4 de préférence, et une migration planifiée avant la fin de PHP 8.2.
La méthode ne change pas d’une version à l’autre : repérer le composant le plus exigeant, tester sur une copie avec les parcours qui comptent, basculer, surveiller. Inscrivez la vérification de PHP dans votre checklist de maintenance WordPress, une fois par an au moins.
Sources
- WordPress.org (7 mai 2026). Requirements
- Make WordPress Core Handbook (août 2026). PHP Compatibility and WordPress Versions
- PHP Group. Supported Versions
- PHP Group. Unsupported Branches
- WordPress.org. Stats
- Make WordPress Core, John Blackbourn (9 janvier 2026). Dropping support for PHP 7.2 and 7.3
- Make WordPress Core (22 mai 2026). PHP support clarification, spring 2026 edition
- Make WordPress Core (3 septembre 2026). WordCamp US 2026: PHP conversation
- Make WordPress Hosting Handbook (septembre 2026). Server Environment
- Make WordPress Hosting Handbook (septembre 2026). Performance
- WordPress.org. Get a faster, more secure website: update your PHP today
- GitHub, WordPress (11 février 2026). Site Health: Add test and debug data for Opcode Cache
- PHP Wiki, Jakub Zelenka et Derick Rethans (2024). RFC: Release cycle update
- PHP Wiki. PHP 8.6 release timetable
- PHP Group (novembre 2025). PHP 8.5 Release
- PHP Group (novembre 2020). PHP 8.0 Release
- PHP Manual. OPcache runtime configuration
- PHP Manual. Migrating to PHP 8.5: backward incompatible changes
- GitHub, PHPCompatibility. PHPCompatibilityWP
- WordPress.org Plugins. PHP Compatibility Checker
- WordPress VIP Documentation. PHPCS scans for PHP version compatibility
- WordPress VIP Documentation. Static analysis
- WordPress Developer Resources. Debugging in WordPress
- WP-CLI. wp cli info
- WordPress.org Plugins. Query Monitor
- WooCommerce Developer Blog (5 juin 2023). New Requirement for WooCommerce 8.2: PHP 7.4+
- WooCommerce Developer Blog, Brian Coords (8 septembre 2026). Proposed change: Requiring PHP 8.1 or newer for WooCommerce 11.5 and beyond
- WooCommerce Developer Blog, Brian Coords (29 septembre 2026). New Requirement for WooCommerce 11.6: PHP 8.1+
- GitHub, WooCommerce (30 septembre 2026). Add an admin notice about the upcoming change in PHP requirements (PHP 8.1)
- WooCommerce Developer Docs. Security Patch Support Policy
- SiteGround, Daniel Kanchev (5 novembre 2024). Seamless Update for Millions of Sites to PHP 8.2
- SiteGround Knowledge Base. What Is Managed PHP Service and How to Enable It?
- WordPress VIP, Amanda Podgorny (21 janvier 2026). Planning your 2026 PHP 8.3 Update
- cPanel Documentation. MultiPHP Manager for cPanel
- Plesk Obsidian Documentation. PHP Settings
- OVHcloud (juillet 2026). Hébergement web – Environnement, version PHP, « .ovhconfig »
- Hostinger Help Center. How to change the PHP version of your Hostinger hosting plan
- Kinsta Docs. MyKinsta Tools
- DreamHost. PHP Extended Support
- IONOS. PHP Extended Support
- Kinsta, Joel Olawanle (décembre 2025). PHP 8.5 benchmarks
- cPanel Documentation. MultiPHP Manager for WHM
- Plesk Obsidian Documentation. Securing Outdated PHP Versions
- WordPress.org. Releases
- Make WordPress Core (18 septembre 2026). Roadmap to 7.2
- WordPress Developer Resources. wp_get_environment_type()
- WordPress Developer Resources. wp_opcache_invalidate()
- PHP Manual. Migrating to PHP 8.0: backward incompatible changes
- PHP Manual. Migrating to PHP 8.1: deprecated features
- PHP Manual. Migrating to PHP 8.2: deprecated features
- PHP Manual. Migrating to PHP 8.4: deprecated features
LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.