Warning: Trying to access array offset on value of type null : ce message, apparu avec PHP 8.0 et son niveau de rigueur accru sur les accès à des variables non définies, s’invite dans les logs de nombreuses extensions WordPress dès leur première activation sur un site où aucune option n’a encore été enregistrée. Le symptôme est trompeur, car le code fonctionnait sans avertissement sur PHP 7 : ce n’est pas une régression du code, c’est PHP qui signale enfin, à raison, une hypothèse implicite jamais vérifiée.
Symptôme : la notice qui envahit les logs
Le scénario type ressemble à ceci : un écran de réglages lit une option sérialisée, puis tente d’accéder directement à l’une de ses clés sans vérifier au préalable que l’option existe :
$reglages = get_option( 'mon_ext_options' );
$duree_cache = $reglages['duree_cache']; // Notice ici si $reglages est false
Tant que l’option mon_ext_options n’a jamais été enregistrée (avant la première sauvegarde de l’écran de réglages, ou après une désinstallation incomplète), get_option() retourne false par défaut. Indexer false comme s’il s’agissait d’un tableau déclenche la notice, autrefois silencieuse sur PHP 7.4, désormais visible sur PHP 8.
Diagnostic : remonter à la source de la valeur nulle
Le réflexe le plus courant, et le moins recommandable, consiste à ajouter un opérateur @ devant l’expression fautive pour faire taire la notice. Cette approche masque le symptôme sans corriger la cause : la variable $duree_cache reste indéfinie, et toute logique qui en dépend plus loin dans le code continuera à se comporter de façon imprévisible, potentiellement avec une nouvelle notice quelques lignes plus loin.
Le diagnostic correct consiste à identifier chaque point du code où une option, une entrée de tableau $_POST, ou un résultat de requête peut légitimement être absent, et à traiter explicitement ce cas plutôt que de supposer sa présence :
get_option()retournefalsesi l’option n’existe pas — jamais un tableau vide par défaut, sauf si on le précise en second argument.$_POST['champ']n’existe simplement pas si le champ n’a pas été soumis (case à cocher non cochée, par exemple).- Une jointure SQL qui ne trouve aucune correspondance renvoie
null, pas un tableau vide.
Correctif : wp_parse_args et l’opérateur de coalescence
La correction la plus robuste combine deux outils complémentaires. D’abord, définir des valeurs par défaut explicites avec wp_parse_args(), qui fusionne proprement un tableau de valeurs par défaut avec les valeurs réellement enregistrées :
$reglages = wp_parse_args( get_option( 'mon_ext_options', [] ), [
'duree_cache' => 3600,
'mode_debug' => false,
'cle_api' => '',
] );
$duree_cache = $reglages['duree_cache']; // Toujours défini, jamais de notice.
Le second argument de get_option() garantit un tableau vide plutôt que false si l’option n’existe pas, et wp_parse_args() complète ensuite les clés manquantes avec les valeurs par défaut. Cette combinaison élimine la notice à la racine, sans jamais recourir à l’opérateur @.
L’opérateur de coalescence nulle pour les cas ponctuels
Pour un accès isolé, sans passer par un tableau complet de valeurs par défaut, l’opérateur ?? introduit en PHP 7 reste la solution la plus lisible :
$duree_cache = $reglages['duree_cache'] ?? 3600;
Cette syntaxe vérifie l’existence de la clé avant d’y accéder, sans déclencher de notice même si $reglages vaut false ou null, contrairement à un accès direct par crochets.
Prévention : ne jamais supposer qu’une option existe
La prévention durable passe par une règle systématique dans le code des extensions : chaque appel à get_option() destiné à être indexé comme un tableau doit être accompagné soit d’un second argument par défaut cohérent (typiquement un tableau vide), soit d’un passage explicite par wp_parse_args() avant toute utilisation. Cette règle, appliquée dès l’écriture initiale du code de réglages, évite la notice a priori plutôt que de la corriger après coup dans les logs de production.
Vérifier l’activation initiale de l’extension
Un bon réflexe complémentaire consiste à initialiser l’option avec ses valeurs par défaut dès le hook d’activation de l’extension, via register_activation_hook(), plutôt que de laisser cette responsabilité à la première visite de l’écran de réglages :
register_activation_hook( __FILE__, function () {
add_option( 'mon_ext_options', [
'duree_cache' => 3600,
'mode_debug' => false,
'cle_api' => '',
] );
} );
add_option() n’écrase jamais une option déjà existante, ce qui rend cet appel parfaitement sûr même en cas de réactivation de l’extension après une désactivation temporaire.
Une notice PHP 8 n’est jamais du bruit à faire taire : c’est PHP qui documente, gratuitement, l’endroit exact où le code fait une hypothèse jamais vérifiée sur la présence d’une donnée.
En résumé
La notice « Trying to access array offset on value of type null » signale systématiquement un accès à une option ou une clé de tableau dont l’existence n’a pas été vérifiée au préalable. Corriger à la source avec wp_parse_args() et des valeurs par défaut cohérentes, complété par l’opérateur ?? pour les accès ponctuels, règle durablement le problème — bien plus efficacement qu’un opérateur @ qui ne fait que déplacer le symptôme plus loin dans l’exécution.
