Sur un site associatif que j’ai accompagné, trois profils se connectaient au même formulaire : les bénévoles qui devaient atterrir sur un tableau de bord de missions, les adhérents qui voulaient simplement voir leurs factures, et les administrateurs qui, eux, avaient besoin du tableau de bord WordPress classique. Rediriger tout ce monde vers /wp-admin/ par défaut n’avait aucun sens pour les deux premiers profils.
Le filtre login_redirect permet de personnaliser cette destination selon le rôle, tout en respectant les cas où WordPress a déjà prévu une redirection explicite via le paramètre redirect_to.
Le filtre de base
Le filtre reçoit trois arguments : l’URL de redirection prévue, l’URL demandée initialement (redirect_to), et l’objet utilisateur connecté :
add_filter( 'login_redirect', function ( $redirection, $redirect_to, $user ) {
if ( ! isset( $user->roles ) || ! is_array( $user->roles ) ) {
return $redirection;
}
if ( in_array( 'benevole', $user->roles, true ) ) {
return home_url( '/espace-benevole/' );
}
if ( in_array( 'adherent', $user->roles, true ) ) {
return home_url( '/mon-compte/factures/' );
}
return $redirection;
}, 10, 3 );
Respecter le paramètre redirect_to
Un piège fréquent : écraser systématiquement la redirection sans tenir compte du fait qu’un lien avait explicitement demandé une destination via redirect_to, par exemple un lien « Connectez-vous pour laisser un avis » qui doit ramener l’utilisateur sur la fiche produit d’origine.
add_filter( 'login_redirect', function ( $redirection, $redirect_to, $user ) {
// Si une redirection explicite a été demandée, on la respecte
if ( ! empty( $redirect_to ) && $redirect_to !== admin_url() ) {
return $redirect_to;
}
if ( isset( $user->roles ) && in_array( 'benevole', $user->roles, true ) ) {
return home_url( '/espace-benevole/' );
}
return $redirection;
}, 10, 3 );

Le cas particulier de WooCommerce
WooCommerce gère son propre formulaire de connexion sur la page « Mon compte » et applique déjà une redirection par défaut vers cette même page. Si le filtre login_redirect est appliqué sans distinction, il peut entrer en conflit avec le comportement attendu par WooCommerce, notamment lors d’une connexion en cours de commande (checkout).
- Vérifier si la connexion a lieu depuis le tunnel de commande avec
is_checkout()avant de rediriger ailleurs. - Ne pas rediriger les clients WooCommerce identifiés par le rôle
customersi une commande est en cours, au risque de les faire sortir du tunnel d’achat. - Tester spécifiquement le parcours « connexion pendant le paiement » après toute modification de ce filtre.
add_filter( 'login_redirect', function ( $redirection, $redirect_to, $user ) {
if ( function_exists( 'is_checkout' ) && is_checkout() ) {
return $redirection; // Laisser WooCommerce gérer son propre parcours
}
if ( isset( $user->roles ) && in_array( 'customer', $user->roles, true ) ) {
return wc_get_page_permalink( 'myaccount' );
}
return $redirection;
}, 10, 3 );
Gérer plusieurs rôles sur un même compte
Un utilisateur peut techniquement cumuler plusieurs rôles. Dans ce cas, l’ordre des conditions dans le filtre détermine la priorité : je place toujours en premier le rôle qui doit l’emporter en cas de cumul, généralement administrator, pour ne jamais rediriger un administrateur vers un espace restreint par erreur.
Un filtre de redirection après connexion doit toujours être testé avec un compte de chaque rôle concerné, y compris les comptes qui cumulent plusieurs rôles : c’est souvent là que se cache l’oubli.
Prévention des boucles de redirection
Rediriger vers une page qui, elle-même, nécessite une connexion et redéclenche le processus crée une boucle infinie. Avant de déployer ce type de filtre, je vérifie systématiquement que la page de destination est accessible sans redéclencher auth_redirect() ou une vérification de capacité qui renverrait à nouveau vers l’écran de connexion.
En résumé
Le filtre login_redirect est simple dans son principe, mais demande de la rigueur dans son écriture : respecter redirect_to quand il existe, ne pas casser les parcours gérés par des extensions comme WooCommerce, et tester chaque rôle individuellement avant la mise en production.