Afficher un menu différent selon qu’on est visiteur anonyme ou membre connecté, réserver un contenu aux abonnés, personnaliser un message d’accueil avec un prénom : la quasi-totalité des logiques de personnalisation d’un site part de cette même question, posée à chaque chargement de page.
Un objet global reconstruit à chaque requête
WordPress détermine l’identité de la personne connectée en lisant les cookies d’authentification, puis expose le résultat via l’objet retourné par wp_get_current_user(), une instance de WP_User. La fonction booléenne is_user_logged_in() permet une vérification rapide sans manipuler cet objet, et current_user_can( 'capacite' ) reste la manière recommandée de contrôler des permissions plutôt que de comparer des rôles directement.
Exemple
<?php
if ( is_user_logged_in() ) {
$utilisateur = wp_get_current_user();
echo 'Bonjour ' . esc_html( $utilisateur->display_name );
} else {
echo 'Connectez-vous pour accéder à ce contenu.';
}
Bon à savoir
- Cet objet n’est fiable qu’à partir du hook
init: l’appeler trop tôt dans le cycle de chargement, par exemple directement dansfunctions.phphors de tout hook, renvoie un utilisateur non identifié. - Dans le contexte de l’API REST, la notion d’utilisateur courant reste identique côté PHP, mais l’authentification passe généralement par les cookies du navigateur associés à un nonce, ou par une application password pour un accès externe.
- Toujours préférer une vérification par capacité (
edit_posts,manage_options…) à une vérification par nom de rôle, car les capacités restent cohérentes même si les rôles sont personnalisés.