# wp_get_current_user en dehors d’un hook : le piège d’un appel trop précoce

> « Notice: undefined property » sur un objet utilisateur censé exister. Le coupable est presque toujours un appel placé avant que WordPress ait fini de charger l'utilisateur courant.

- Auteur : WordPress Développement
- Publié le : 2022-11-29
- Mis à jour le : 2022-11-29
- Catégorie : Astuces
- URL : https://www.wpmoderne.fr/tips/wp-get-current-user-hors-hook-piege-appel-precoce/

## L’essentiel

- L'utilisateur courant n'est pas encore disponible avant le hook init
- Un appel dans un fichier de configuration global retourne un objet vide
- Le hook plugins_loaded est déjà trop tôt pour cet usage précis

« Notice: Undefined property: WP_User::$ID » sur un code qui semble pourtant correct : `wp_get_current_user()->ID`, exactement comme dans la documentation. Le symptôme n'apparaît pas à chaque chargement de page, ce qui rend son diagnostic plus long que nécessaire — il dépend en réalité de l'endroit précis où cet appel est placé dans le cycle de chargement de WordPress, pas d'une erreur de syntaxe.

## Symptôme

Un appel à `wp_get_current_user()` retourne parfois un objet `WP_User` vide, avec un `ID` égal à zéro, alors qu'un utilisateur est bel et bien connecté. Le problème est intermittent en apparence : il se manifeste selon l'endroit du code où l'appel est effectué, pas selon une condition liée à l'utilisateur lui-même.

## Diagnostic

WordPress charge les informations de l'utilisateur courant à un moment précis de son cycle de démarrage, après l'exécution des extensions les plus précoces mais avant le rendu du contenu. Un appel à `wp_get_current_user()` effectué trop tôt — directement dans un fichier chargé au niveau global d'une extension, avant le hook `plugins_loaded`, ou même pendant `plugins_loaded` dans certains cas limites — intervient avant que cette information soit disponible.

> L'essentiel à retenir : L'utilisateur courant n'est pas encore disponible avant le hook init ; Un appel dans un fichier de configuration global retourne un objet vide ; Le hook plugins_loaded est déjà trop tôt pour cet usage précis

```
// Dans le fichier principal d'une extension, en dehors de tout hook :
$utilisateur = wp_get_current_user();
echo $utilisateur->ID; // 0, même si un utilisateur est connecté
```

Ce code s'exécute au moment où PHP charge le fichier, bien avant que WordPress ait fini d'initialiser l'objet représentant l'utilisateur courant à partir des cookies d'authentification.

## Correctif

```
add_action( 'init', 'ma_fonction_qui_lit_utilisateur' );

function ma_fonction_qui_lit_utilisateur() {
    $utilisateur = wp_get_current_user();

    if ( 0 === $utilisateur->ID ) {
        // Visiteur non connecté, cas normal à gérer séparément.
        return;
    }

    echo $utilisateur->ID;
}
```

Le hook `init` se déclenche après que WordPress a fini de résoudre l'utilisateur courant à partir de la session active, ce qui en fait le premier point d'entrée fiable pour ce genre d'appel. Un appel plus tardif, sur `wp` ou `template_redirect`, fonctionne également, mais `init` suffit pour la grande majorité des besoins.

## Prévention

- Aucun appel à `wp_get_current_user()`, `is_user_logged_in()` ou `current_user_can()` ne devrait figurer au niveau global d'un fichier PHP, hors de tout hook.
- Le hook `plugins_loaded` reste trop précoce pour ce besoin spécifique : il concerne le chargement des extensions elles-mêmes, pas la résolution de l'utilisateur courant.
- Une extension qui doit réagir différemment selon le rôle de l'utilisateur dès le chargement le plus précoce possible devrait plutôt reporter cette logique à l'intérieur du hook `init`, quitte à retarder légèrement son exécution.

### Un test rapide pour confirmer le diagnostic

Ajouter temporairement un `error_log( current_action() )` juste avant l'appel suspect permet de vérifier immédiatement à quel stade du chargement il se situe, et de comparer avec le hook `init` pour confirmer que le problème vient bien d'un appel trop précoce plutôt que d'une autre cause.

> Un repère simple à garder en tête : tant qu'un développeur n'a pas explicitement accroché son code à un hook, il ne sait pas réellement à quel moment du cycle de chargement il s'exécute. C'est particulièrement vrai pour tout ce qui touche à l'utilisateur courant.

## En résumé

Un objet utilisateur vide alors qu'une session est active pointe presque toujours vers un appel effectué trop tôt dans le cycle de chargement de WordPress. Déplacer cet appel à l'intérieur du hook `init` résout ce symptôme dans l'immense majorité des cas, sans qu'aucune autre modification du code ne soit nécessaire.