WordPress 7.0 et Elementor V4 : PHP 8.4 minimum, ce qu’un kit doit corriger

WordPress 7.0 relève le seuil minimal de compatibilité à PHP 8.4, une version disponible depuis novembre 2024 mais encore loin d’être systématiquement adoptée sur les hébergements qui font tourner des Kits Elementor construits plusieurs années auparavant. Avant toute montée de version du cœur WordPress, un audit du code PHP personnalisé du Kit s’impose, sous peine d’écrans blancs en production le jour de la mise à jour.

Cette checklist recense les motifs de code les plus fréquemment rencontrés dans des Kits Elementor hérités, incompatibles avec PHP 8.4, sans entrer dans le détail des nouveautés éditoriales de WordPress 7.0 lui-même ni dans la migration des extensions tierces, qui suivent leur propre calendrier de compatibilité.

1. Repérer les propriétés dynamiques non déclarées

Depuis PHP 8.2 déjà, l’assignation d’une propriété dynamique non déclarée dans une classe lève une dépréciation ; avec PHP 8.4, ce type de code continue de fonctionner mais son usage doit être traité en priorité tant les journaux d’erreurs s’en trouvent pollués sur les Kits volumineux. Ce motif est fréquent dans les widgets Elementor personnalisés qui stockent des données de configuration directement sur l’instance :

class Ancien_Widget extends \Elementor\Widget_Base {
    public function render() {
        $this->config_cache = $this->get_settings(); // propriété non déclarée
    }
}

Le correctif consiste à déclarer explicitement la propriété dans la classe, ou à implémenter l’attribut #[\AllowDynamicProperties] si la refonte complète n’est pas envisageable à court terme.

2. Vérifier les fonctions de manipulation de chaînes dépréciées

Plusieurs fonctions historiques de manipulation de chaînes, déjà signalées comme dépréciées dans des versions antérieures de PHP, voient leur usage devenir strictement incompatible sur certaines configurations strictes de PHP 8.4. Un audit statique du code du Kit doit rechercher systématiquement les appels à each(), déjà supprimée depuis PHP 8.0 mais parfois oubliée dans du code très ancien copié-collé d’un projet à l’autre, ainsi que les appels implicites à des fonctions de chaînes avec des arguments null non explicitement castés.

3. Passer en revue les appels de fonctions avec arguments nommés

PHP 8.4 renforce certaines règles autour des arguments nommés et de l’ordre des paramètres optionnels. Un widget personnalisé qui appelle une fonction interne d’Elementor en supposant un ordre de paramètres qui a changé entre versions peut lever une erreur fatale plutôt qu’un simple avertissement, contrairement au comportement plus permissif des versions précédentes de PHP.

4. Contrôler la compatibilité des dépendances Composer, le cas échéant

Un Kit qui embarque des dépendances via Composer (bibliothèques de génération de PDF, de traitement d’image) doit vérifier que chacune de ces dépendances déclare une compatibilité explicite avec PHP 8.4 dans son fichier composer.json. La commande suivante permet d’obtenir rapidement un premier diagnostic :

composer why-not php:8.4

5. Tester le comportement des tableaux et objets sérialisés

Les Kits qui stockent des configurations complexes sous forme sérialisée en base de données (pratique ancienne mais encore courante sur certains widgets personnalisés) doivent être testés spécifiquement, car un changement de structure de classe entre deux versions peut rendre une donnée sérialisée illisible après désérialisation sous PHP 8.4, avec un risque de perte silencieuse de configuration.

6. Mettre en place un environnement de test dédié avant la bascule

• Cloner l’environnement de production sur un serveur de recette configuré en PHP 8.4
• Activer WP_DEBUG et WP_DEBUG_LOG pour capturer tout avertissement silencieux
• Parcourir systématiquement chaque gabarit du Kit, pas seulement la page d’accueil
• Vérifier les journaux serveur PHP-FPM en complément du journal WordPress

Notre règle avant toute montée de version majeure de PHP sur un Kit hérité : ne jamais se fier uniquement à l’absence d’erreur visible à l’écran, les avertissements silencieux dans les journaux racontent souvent une autre histoire.

En résumé

Le seuil de PHP 8.4 exigé par WordPress 7.0 remet en lumière des motifs de code PHP anciens, tolérés depuis des années par des versions plus permissives de PHP. Un Kit Elementor hérité doit faire l’objet d’un audit ciblé sur les propriétés dynamiques non déclarées, les fonctions dépréciées, les dépendances Composer et les données sérialisées, avant toute bascule en production, sous peine de découvrir ces incompatibilités le jour même de la mise à jour du cœur WordPress.