PHP Fatal error: Uncaught TypeError: Elementor\Modules\AtomicWidgets\.... Cette erreur, apparue sur une poignée de sites d’un même parc d’agence après une bascule groupée vers PHP 8.4, ne concernait ni le cœur de WordPress ni les extensions habituelles, mais la nouvelle génération d’éléments atomiques introduite par Elementor V4, alors en cours de déploiement progressif sur les sites du parc.
Cette version, qui introduit les classes globales et un système de rendu basé sur des composants atomiques, n’a pas été pensée en priorité pour PHP 8.4, sorti quelques mois plus tôt : les deux montées de version se sont chevauchées sur ce parc, révélant des incompatibilités précises qu’aucun changelog ne mentionnait clairement. Nous ne revenons pas ici sur la prise en main d’Elementor V4 elle-même, déjà couverte dans la catégorie dédiée à cet éditeur.
Symptôme : un rendu d’éléments incomplet, pas une erreur systématique
Sur douze sites du parc concerné, le symptôme n’était pas une page blanche immédiate mais un rendu partiel : certains éléments atomiques (particulièrement les composants utilisant des variables de style globales) s’affichaient sans leur style associé, tandis que d’autres éléments plus classiques du même parc continuaient à fonctionner normalement. Cette incohérence a rendu le diagnostic initial plus long que prévu.
- Rendu incomplet limité aux éléments atomiques utilisant des classes globales
- Aucune erreur visible côté navigateur, seulement en journal PHP serveur
- Comportement variable selon la configuration OPcache du serveur concerné
- Sites non affectés sur des serveurs avec une configuration OPcache plus généreuse
Diagnostic : le rôle inattendu d’OPcache
L’analyse a révélé que le nouveau système de rendu d’Elementor V4 génère un nombre de classes PHP dynamiques sensiblement supérieur à l’ancien système de widgets, pour gérer les combinaisons de styles atomiques. Sur un serveur où opcache.max_accelerated_files restait fixé à sa valeur historique, insuffisante pour ce nouveau volume de classes, certains fichiers cessaient d’être mis en cache d’opcode, provoquant un rendu incomplet dans des conditions de charge précises.
; Valeur insuffisante rencontrée sur les serveurs affectés
opcache.max_accelerated_files = 4000
; Valeur qui a résolu l'incident sur le parc concerné
opcache.max_accelerated_files = 10000
opcache.memory_consumption = 256
Correctif appliqué et validé sur le parc
Une fois la cause identifiée, le correctif a consisté à revoir la configuration OPcache sur l’ensemble du parc, pas seulement sur les sites déjà affectés, pour anticiper le même problème sur les sites encore en attente de migration vers Elementor V4. Un redémarrage du service PHP-FPM après modification était nécessaire pour que le nouveau paramétrage soit pris en compte.
systemctl restart php8.4-fpm
wp elementor flush_css --allow-root
Prévention : tester avant une bascule de parc groupée
La leçon principale de cet incident concerne la méthode de migration, plus que le correctif technique lui-même. Basculer un parc entier vers PHP 8.4 en même temps qu’un déploiement d’Elementor V4 multiplie les variables et complique le diagnostic en cas de problème. Une approche site par site, avec vérification systématique post-bascule, aurait permis de détecter l’incompatibilité sur un seul site avant qu’elle ne se répète sur onze autres.
Sur un parc géré par une agence, ne jamais faire coïncider deux montées de version majeures et indépendantes le même jour reste la règle la plus simple à appliquer, et la plus souvent oubliée sous la pression d’un planning serré.
Checklist avant toute bascule groupée future
- Vérifier la configuration OPcache sur chaque serveur avant d’activer Elementor V4
- Migrer un site pilote isolé avant d’étendre à l’ensemble du parc
- Surveiller les journaux PHP pendant au moins 48 heures après chaque bascule
- Ne jamais combiner une montée de version PHP majeure avec un déploiement d’extension majeur le même jour
Ce qui bloque encore aujourd’hui
Au-delà du réglage OPcache, certains environnements mutualisés très contraints en mémoire disponible pour PHP-FPM continuent de montrer des ralentissements sensibles sur les pages utilisant massivement les nouveaux éléments atomiques, sans qu’un simple ajustement de configuration suffise à les résorber totalement. Sur ces environnements, le passage à un VPS dédié reste, à ce stade, la seule solution durable identifiée par notre équipe.
