2026 : WordPress 7.0 relève son minimum requis à PHP 8.4, une version elle-même sortie en novembre 2024. La première question à trancher n’est pourtant pas technique mais contractuelle : quelle version de PHP l’hébergement du site propose-t-il réellement aujourd’hui, et sous quel délai peut-il basculer vers la version exigée ? Un thème qui tournait sans souci depuis des années sur PHP 8.0 ou 8.1 se retrouve soudain face à une échéance qui dépend d’abord de l’offre de l’hébergeur, avant même de dépendre du code du thème lui-même.
Ce classement des nouveautés se concentre volontairement sur ce qui concerne un thème resté classique, jamais migré vers un thème bloc, par choix ou par inertie : il laisse de côté tout ce qui relève des thèmes blocs, qui font l’objet d’un traitement séparé.
Impact critique : le relèvement du minimum PHP
Le passage à un minimum de PHP 8.4 touche indistinctement tous les thèmes actifs, classiques comme blocs. Pour un thème classique jamais audité sur ce point, le risque principal ne vient pas d’une incompatibilité brutale mais d’une accumulation de dépréciations silencieuses depuis PHP 8.0 : propriétés dynamiques non déclarées, passage de valeurs nulles à des paramètres non explicitement nullables, fonctions internes dont la signature a évolué d’une version à l’autre.
- Une agence qui n’a jamais testé son thème sur PHP 8.3 ou 8.4 découvre souvent plusieurs avertissements simultanément, pas un seul.
- Le code hérité de plusieurs développeurs successifs accumule ce type de dette sans qu’aucun symptôme visible n’ait jamais alerté l’équipe.
- Un hébergeur qui impose la montée de version avant la sortie officielle de WordPress 7.0 laisse peu de marge pour ce diagnostic.
D’abord vérifier ce que l’hébergement propose réellement
Avant tout audit de code, la question la plus rapide à trancher reste celle de l’offre d’hébergement elle-même : certains contrats mutualisés anciens plafonnent encore à PHP 8.1 ou 8.2, sans bascule automatique possible vers une version plus récente sans changement de formule ou d’hébergeur. La commande wp cli info, exécutée directement sur le serveur, indique la version de PHP réellement utilisée par l’installation, à comparer avec celle annoncée dans le panneau de gestion de l’hébergement.
La méthode de vérification avant l’échéance
Avant toute mise à niveau imposée, un audit ciblé sur PHP 8.4 permet d’anticiper les correctifs nécessaires, plutôt que de les découvrir en production :
wp cli info
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 wp-content/themes/mon-theme
Impact modéré : les correctifs transverses accompagnant WordPress 7.0
Comme chaque version majeure, WordPress 7.0 embarque des correctifs de sécurité et d’accessibilité qui s’appliquent quel que soit le thème actif. Un thème classique doit vérifier que son code personnalisé, notamment autour des capacités utilisateur et de la validation des formulaires, reste cohérent avec ces ajustements, sans que cela nécessite une réécriture complète.
| Nouveauté | Concerne un thème classique non migré ? |
|---|---|
| Minimum PHP 8.4 | Oui, impact critique |
| Correctifs de sécurité transverses | Oui, à vérifier |
| Nouveautés propres à l’éditeur de site | Non |
| Évolutions de theme.json | Non, thème resté classique |
Impact nul : tout ce qui concerne les thèmes blocs
La majeure partie du changelog de WordPress 7.0 concerne les gabarits, les styles de section et les réglages liés à theme.json. Pour un thème resté classique, ces nouveautés n’ont aucun effet, exactement comme sur les versions précédentes du cœur : l’absence de déclaration de support de l’édition complète du site suffit à écarter ces changements du périmètre de vérification.
Cette absence d’effet ne doit pas conduire une agence à ignorer entièrement le changelog : elle doit simplement le lire avec un filtre différent de celui d’un projet construit autour des blocs, en se concentrant sur les points qui touchent le cœur indépendamment du type de thème actif, comme cela a déjà été le cas sur les versions précédentes.
Un thème classique jamais migré vers les blocs ne devient pas obsolète du seul fait de son architecture : il devient risqué le jour où son code n’a jamais été confronté à la version de PHP qu’exige la version de WordPress installée.
Ce qu’il faut retenir
Face à WordPress 7.0, la priorité pour un thème classique non migré ne se situe pas du côté des blocs, qui restent hors sujet, mais du côté d’un audit de compatibilité PHP 8.4 mené avant toute mise à niveau forcée par l’hébergeur. Cette vérification, réalisable en quelques heures avec les bons outils, évite qu’une simple montée de version de cœur ne se transforme en incident de production sur un code jamais confronté à cette contrainte.
