PHP Deprecated: implode(): Passing glue string after array is deprecated — cette ligne, répétée des dizaines de fois dans debug.log, est le premier signe qu’un thème bloc expérimental n’a pas été écrit avec la même rigueur que les thèmes classiques les plus matures. Le site continue de fonctionner, l’éditeur de site s’affiche, mais les logs gonflent à vue d’œil, et personne dans l’équipe ne sait dire lesquelles de ces notices viennent réellement du thème testé.
Sur ce projet, un thème bloc récupéré depuis un dépôt public a été installé pour évaluer le fonctionnement du plugin Gutenberg en mode site complet. PHP 7.4 vient d’arriver sur l’hébergement mutualisé du client, et avec lui son lot de dépréciations plus strictes que 7.3. Le thème, jamais testé sur cette version, en révèle immédiatement les limites.
Repérer la notice exacte plutôt que deviner
La première erreur, sur ce genre de diagnostic, est de corriger « à l’instinct » en modifiant le premier fichier suspect venu. Avant toute intervention, il faut activer WP_DEBUG_LOG et laisser tourner le site quelques minutes en naviguant dans l’éditeur de site, puis lire le fichier wp-content/debug.log ligne par ligne.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Chaque notice PHP 7.4 précise le fichier et la ligne d’origine. Sur ce thème, trois familles de dépréciations sont ressorties : l’inversion des arguments de implode(), l’appel à create_function() pour générer un callback dynamique dans un filtre de template, et l’utilisation de each() dans une boucle héritée d’un ancien thème classique dont le développeur s’était partiellement inspiré.
Distinguer ce qui vient du cœur, du thème et des extensions
Toutes les notices ne se valent pas. Certaines proviennent de fonctions du cœur de WordPress lui-même, pas encore adaptées à PHP 7.4 à cette date ; d’autres viennent d’extensions activées en parallèle pour tester le thème ; le reste, la majorité ici, vient du thème bloc lui-même.
- Grep le chemin du fichier fautif dans la notice :
wp-content/themes/signale le thème,wp-content/plugins/une extension,wp-includes/ouwp-admin/le cœur. - Désactiver temporairement les extensions non indispensables pour réduire le bruit et isoler les notices propres au thème.
- Vérifier le numéro de version du thème sur son dépôt d’origine : un correctif PHP 8 existe parfois déjà, même si la compatibilité annoncée ne mentionne que PHP 7.
Corriger sans casser l’expérimentation en cours
L’objectif n’est pas de réécrire le thème bloc de fond en comble : à ce stade, il sert avant tout à évaluer le fonctionnement du Site Editor, pas à être mis en production. Les correctifs appliqués restent donc chirurgicaux.
Remplacer create_function() par une fermeture
Le remplacement le plus simple concerne create_function(), retirée définitivement en PHP 8 et déjà dépréciée en 7.2 : une fermeture anonyme classique fait exactement le même travail, sans notice.
// Avant
$callback = create_function( '$title', 'return strtoupper( $title );' );
// Après
$callback = function ( $title ) {
return strtoupper( $title );
};
Inverser les arguments d’implode()
La signature historique implode( $array, $glue ) reste tolérée mais génère désormais une notice ; il suffit d’inverser l’ordre des arguments pour la faire taire, sans changer le comportement.
Prévenir la prochaine régression de version
Une fois les notices silencées, la vraie question devient : comment éviter de retomber dans le même piège au prochain saut de version PHP, alors que WordPress annonce déjà travailler sur la compatibilité PHP 8 pour la fin d’année ? La réponse tient en une habitude simple : activer WP_DEBUG_LOG sur chaque environnement de test dès l’installation d’un thème expérimental, et ne jamais attendre qu’un client signale un problème de logs qui saturent l’espace disque.
Sur les hébergements mutualisés, une notice répétée des milliers de fois par jour finit par remplir le quota de logs et peut, dans certains cas, ralentir les écritures disque. Ce n’est pas qu’une question d’esthétique de code.
Notre verdict
Un thème bloc expérimental hérite souvent de pratiques anciennes, recopiées d’un thème classique sans être révisées pour les versions récentes de PHP. Avant d’évaluer les qualités du Site Editor lui-même, il vaut mieux passer vingt minutes à nettoyer les logs : cela évite de confondre un bug du thème avec une limite du plugin Gutenberg, et cela donne une base saine pour la suite des tests.
