WordPress : corriger « expected to be a reference, value given »

Lors d’une migration WordPress vers une version plus récente de PHP, vous pouvez rencontrer ce warning :

Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given

Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value givenLangage du code : HTTP (http)

On le voyait souvent lors des migrations de PHP 5.6 vers PHP 7.1 ou PHP 7.2, notamment avec d’anciennes versions de WordPress. Le site peut continuer à fonctionner, mais les warnings polluent l’affichage, les logs, et parfois les performances. Ce n’est pas dramatique. Mais ce n’est pas propre non plus.

La mauvaise solution consiste à modifier directement les fichiers du cœur WordPress. La bonne solution consiste à identifier la cause : version WordPress trop ancienne, thème obsolète, plugin incompatible, extension PHP particulière, ou environnement d’hébergement qui force des comportements non standards.

Que signifie “expected to be a reference, value given” ?

En PHP, une fonction peut demander un argument passé par référence. Cela signifie qu’elle attend une variable modifiable, pas une simple valeur copiée.

Un exemple simplifié :

<?php

function skyminds_increment_number( int &$number ): void {
	$number++;
}

$value = 10;

skyminds_increment_number( $value );Langage du code : HTML, XML (xml)

Ici, $value est bien une variable. PHP peut donc la passer par référence. En revanche, si une fonction attend une référence mais reçoit une valeur construite dynamiquement, PHP peut déclencher un warning.

Dans WordPress, ce genre de message apparaît souvent dans une pile d’exécution liée aux hooks, car WordPress appelle énormément de fonctions via do_action(), apply_filters(), call_user_func() et call_user_func_array().

Le cas wp_default_styles() et wp_default_scripts()

Les messages les plus connus ressemblent à ceci :

Parameter 1 to wp_default_styles() expected to be a reference, value given in /wp-includes/class-wp-hook.php on line 286

Parameter 1 to wp_default_scripts() expected to be a reference, value given in /wp-includes/class-wp-hook.php on line 286Langage du code : JavaScript (javascript)

La ligne mentionnée dans class-wp-hook.php n’est généralement pas la vraie cause. Elle indique seulement que WordPress exécute une fonction attachée à un hook. Le problème vient de la fonction appelée, de sa signature, ou de la manière dont l’environnement PHP gère le passage par référence.

Dans les anciennes versions de WordPress, le problème pouvait toucher wp_default_styles() et wp_default_scripts(). Un ancien contournement consistait à modifier wp-includes/script-loader.php pour retirer le caractère & dans les paramètres de ces fonctions. Aujourd’hui, évitez ce correctif : une mise à jour WordPress écrasera votre modification, et vous aurez masqué le vrai problème.

Première correction : mettre WordPress à jour

Si vous voyez encore cette erreur sur un site WordPress ancien, commencez par vérifier la version du cœur :

wp core version

Ensuite, vérifiez la version PHP :

php -v

Si le site tourne avec un vieux WordPress sur une version PHP moderne, vous avez déjà votre suspect principal. WordPress doit être mis à jour avant de diagnostiquer plus loin.

Sur un site client ou une boutique WooCommerce, procédez toujours sur staging :

wp core update
wp plugin update --all
wp theme update --all

Pour un site WooCommerce, testez ensuite les pages critiques : panier, commande, compte client, paiement, emails transactionnels, webhooks Stripe ou PayPal, et tâches planifiées.

Si vous tombez sur une autre erreur filesystem pendant les mises à jour, consultez aussi l’article sur l’erreur ftp_nlist() expects parameter 1 to be resource. Elle apparaît souvent quand WordPress tente de mettre à jour des fichiers sans droits corrects.

Ne modifiez pas les fichiers du cœur WordPress

Modifier un fichier comme wp-includes/script-loader.php peut donner l’impression de régler le problème. En réalité, vous créez une dette technique fragile.

• La correction disparaîtra à la prochaine mise à jour WordPress.
• Vous risquez de diverger du comportement officiel du cœur.
• Vous compliquez les audits de sécurité.
• Vous masquez potentiellement un problème d’environnement PHP.
• Vous rendez le debugging plus pénible pour le prochain développeur, donc probablement vous-même dans trois mois.

La règle est simple : on corrige WordPress avec une mise à jour, un mu-plugin, un plugin, un thème enfant, ou une configuration serveur. On ne patche pas le core à la main.

Vérifier si l’extension PHP UOPZ est chargée

Dans certains cas historiques, cette erreur était liée à l’extension PHP UOPZ. Cette extension permet de modifier le comportement interne de PHP, notamment pour des usages de test ou de surcharge avancée. Elle n’a généralement rien à faire sur un hébergement WordPress classique.

Pour vérifier si UOPZ est chargée :

php -m | grep -i uopz

Vous pouvez aussi vérifier via WP-CLI :

wp eval 'var_dump( extension_loaded( "uopz" ) );'Langage du code : JavaScript (javascript)

Si la commande retourne bool(true), désactivez UOPZ pour ce site, sauf besoin très spécifique. Sur un serveur Ubuntu, le nom exact du fichier peut varier selon la version PHP :

php --ini
php -i | grep -i uopz

Ensuite, désactivez l’extension dans la configuration PHP-FPM concernée, puis rechargez PHP-FPM :

sudo phpdismod uopz
sudo systemctl reload php8.3-fpmLangage du code : CSS (css)

Adaptez évidemment php8.3-fpm à la version PHP utilisée par le site.

Identifier le plugin ou le thème responsable

Si WordPress est à jour et que UOPZ n’est pas chargé, le problème vient probablement d’un plugin, d’un thème, ou d’un snippet ancien qui déclare une fonction avec un passage par référence inutile.

Activez le debug log sans afficher les warnings aux visiteurs :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );Langage du code : JavaScript (javascript)

Ensuite, reproduisez l’erreur, puis lisez le journal :

tail -n 100 wp-content/debug.log

La première ligne visible dans wp-includes/class-wp-hook.php n’est pas toujours suffisante. Il faut remonter la pile d’appel pour trouver le plugin, le thème, ou le fichier custom qui attache la mauvaise fonction au hook.

Chercher les passages par référence suspects

Dans un thème ou un plugin ancien, cherchez les fonctions qui déclarent un paramètre avec &$variable. Toutes ne sont pas mauvaises. Mais elles méritent une lecture attentive si le warning apparaît pendant l’exécution d’un hook WordPress.

grep -R "function .*&\$" wp-content/themes wp-content/pluginsLangage du code : JavaScript (javascript)

Vous pouvez aussi chercher spécifiquement les fonctions liées aux scripts et styles :

grep -R "wp_default_styles\|wp_default_scripts\|wp_default_packages" wp-content/themes wp-content/pluginsLangage du code : JavaScript (javascript)

Si un plugin ou un thème surcharge de vieux hooks WordPress avec des signatures obsolètes, mettez-le à jour. Si le projet n’est plus maintenu, remplacez-le ou corrigez le code dans un fork propre.

Exemple de correction dans un thème ancien

Imaginons un vieux thème qui déclare une fonction comme ceci :

<?php

function old_theme_filter_styles( &$styles ) {
	$styles->add( 'old-theme-style', get_stylesheet_uri() );
}Langage du code : HTML, XML (xml)

Si le passage par référence n’est pas indispensable, retirez le & :

<?php
/**
 * Register theme styles.
 *
 * @param WP_Styles $styles WordPress styles registry.
 *
 * @return void
 */
function skyminds_filter_styles( WP_Styles $styles ): void {
	$styles->add( 'skyminds-style', get_stylesheet_uri() );
}Langage du code : HTML, XML (xml)

En PHP moderne, les objets sont déjà manipulés via un identifiant d’objet. Dans beaucoup de cas, ajouter & devant un objet n’apporte rien, sauf des warnings bien croustillants quand le code passe par un système de callbacks.

Tester avec un thème par défaut

Pour isoler le problème sans casser la production, utilisez un staging. Ensuite, testez avec un thème natif WordPress :

wp theme list
wp theme activate twentytwentyfiveLangage du code : PHP (php)

Rechargez ensuite une page qui déclenche le warning. Si le message disparaît, le thème est probablement responsable. S’il reste, passez aux plugins.

Tester les plugins un par un avec WP-CLI

Sur staging, vous pouvez désactiver tous les plugins :

wp plugin deactivate --all

Puis les réactiver progressivement :

wp plugin activate nom-du-plugin

Après chaque activation, rechargez la page ou relancez la commande qui déclenche le warning. Dès que le message revient, vous avez probablement trouvé le plugin concerné.

Pour les boutiques WooCommerce, évitez les tests sauvages en production. Une désactivation de plugin peut couper les paiements, les abonnements, les remises ou les webhooks. Et personne n’aime débugger Stripe avec un café froid.

Cas WPEngine et hébergements managés

Cette erreur a souvent été croisée lors de migrations PHP imposées par des hébergeurs managés. Dans ce cas, le bon réflexe consiste à tester sur staging, mettre WordPress et les extensions à jour, puis demander à l’hébergeur s’il charge une extension PHP inhabituelle ou une configuration interne qui modifie les hooks WordPress.

Si vous migrez un site client vers une version PHP récente, gardez une checklist stricte : version WordPress, thème, plugins, mu-plugins, logs PHP, logs serveur, cache objet, cache page, puis tests fonctionnels.

Pour aller plus loin sur les problèmes liés aux permissions serveur, vous pouvez aussi lire l’article sur les images WordPress qui renvoient une erreur 403. Les causes diffèrent, mais la méthode de diagnostic reste proche : partir du symptôme, lire les logs, puis corriger la vraie source.

Masquer l’erreur n’est pas corriger l’erreur

Sur un site en production, vous ne devez pas afficher les warnings PHP aux visiteurs. Cela dit, les masquer ne suffit pas. Configurez au minimum le debug ainsi :

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );Langage du code : JavaScript (javascript)

Sur staging, activez les logs pour corriger proprement :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );Langage du code : JavaScript (javascript)

L’objectif est simple : rien ne doit s’afficher côté visiteur, mais tout doit rester visible côté développeur.

Checklist de correction

• Vérifier la version de WordPress avec wp core version.
• Vérifier la version PHP avec php -v.
• Mettre à jour WordPress, les plugins et le thème sur staging.
• Ne pas modifier wp-includes/script-loader.php.
• Vérifier si l’extension PHP uopz est chargée.
• Activer WP_DEBUG_LOG sur staging.
• Lire la pile d’appel dans wp-content/debug.log.
• Tester avec un thème WordPress par défaut.
• Désactiver les plugins progressivement pour isoler le coupable.
• Corriger les signatures PHP obsolètes dans le thème enfant, un plugin custom ou un fork maintenu.

Conclusion

L’erreur Parameter 1 expected to be a reference, value given indique un conflit entre une fonction qui attend un argument par référence et la manière dont elle est appelée. Dans WordPress, elle apparaît souvent via le système de hooks, ce qui rend le message plus confus qu’il ne devrait.

La solution moderne n’est pas de patcher le cœur WordPress. Mettez WordPress à jour, vérifiez PHP, inspectez les extensions chargées, puis isolez le thème ou le plugin responsable. Une fois la vraie cause corrigée, le warning disparaît sans bricolage fragile dans wp-includes.

Et si votre site utilise encore une vieille version de WordPress parce que “tout marche très bien comme ça”, ce warning vient peut-être de vous répondre. Avec un mégaphone.

Sources

• WordPress Trac — Parameter 1 to wp_default_styles() expected to be a reference, value given
• WordPress Trac — Not working wp_default_styles on PHP 7.1.0
• WordPress Trac — Parameter 1 to wp_handle_upload_error() expected to be a reference, value given
• PHP Manual — call_user_func()
• PHP Manual — call_user_func_array()
• PHP Manual — Objects and references

Report a typo