Title: URL Hide Login Last modified: May 5, 2026 --- # URL Hide Login * Resolved [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 23 hours ago](https://wordpress.org/support/topic/url-hide-login/) * Bonjour, * Déjà bravo pour ce plugin, super travail et merci de le rendre gratuit ! J’ai une question sur quelque chose qui revient fréquemment avec les plugins qui changent l’url de connexion.Je suis en headless avec wordpress comme backoffice, en multisite. Les pages de connexion de mes sites sont sous cette forme :admin.monsupersite. com (correspond à siteurl)et le front de mes sites sous cette forme :monsupersite. com (correspond à homeurl)Dans les réglages hidelogin, c’est toujours l’url homeurl/ slug qui est utilisée plutôt que siteurl. Donc je ne peux pas garder une homeurl cohérente avec mon site et activer hidelogin puisqu’il ne se base pas sur siteurl! Avez-vous des conseils, ou est-il possible simplement d’utiliser siteurl plutôt que homeurl, ce qui serait plus logique ?Merci d’avance Viewing 11 replies - 1 through 11 (of 11 total) * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 19 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899498) * Bonjour graphandco, * Merci pour ce retour très précis : c’est exactement le cas limite qu’on ne voit qu’avec un setup headless réel. * Vous avez raison sur toute la ligne. Login Armor utilisait `home_url()` pour générer l’URL de login alors que WordPress core lui-même utilise `site_url()` dans sa fonction `wp_login_url()`. C’est un héritage du fork d’origine du module Hide Login, et ça casse silencieusement dès que `siteurl` ≠ `home` (multisite headless, WordPress dans un sous-dossier `/wp/`, reverse-proxy avec `WP_HOME` ≠ `WP_SITEURL`). Sur les installs standard les deux valeurs sont identiques donc personne ne s’en rend compte. * **C’est corrigé en 2.1.9, publiée à l’instant sur WP.org.** Tout le flux Hide Login bascule sur `site_url()` (URL login, redirections, password-reset cookie scope, lostpassword, register, logout, lockout page, prévisualisation Settings). Côté multisite Network Admin, les liens “Dashboard” utilisaient déjà `get_site_url( $blog_id, $slug)`, ce qui était correct, donc rien à toucher de ce côté. * J’ai aussi ajouté un filtre `login_armor_login_url_base` au cas où vous auriez encore un setup plus exotique (3e hostname behind reverse-proxy, plugin de subdomain mapping qui réécrit l’admin URL) : * ```wp-block-code add_filter( 'login_armor_login_url_base', function( $url, $path, $scheme, $slug ) { // $url contient site_url($path, $scheme) par défaut return 'https://votre-hostname-custom.com' . $path; }, 10, 4 ); ``` * Mettez à jour depuis Extensions > Mises à jour et l’URL de login devrait pointer sur `admin.monsupersite.com//` comme attendu. Je suis preneur d’un retour si quelque chose cloche. * Merci d’avoir signalé : c’est notre premier retour terrain sur du multisite headless avec Login Armor, et ça aurait pu rester silencieux longtemps. * Thread Starter [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 19 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899518) * Merci pour votre réactivité et la modification. Néanmoins, `admin.monsupersite. com//` redirige bien vers `admin.monsupersite.com/wp-admin/` , mais la page tombe désormais en 404. * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 18 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899634) * Bonjour graphandco, Bonne nouvelle, j’ai aussi shippé V2.1.10 entre temps — un fix cosmétique sur la page 404 servie quand un anonyme tape `/wp-admin/` (le 404 affichait à tort le menu du site dupliqué + sticky header). Ça touchait votre cas aussi puisque vous êtes en redirect vers `/wp-admin/`. * Pour le 404 sur `admin.monsupersite.com/wp-admin/` après login, j’ai investigué en reproduisant votre setup en local (siteurl admin.X.local, home X.local). Conclusion:** le code Login Armor V2.1.9/V2.1.10 fonctionne correctement** — quand le navigateur envoie ses cookies d’auth (`wordpress_logged_in_*` + `wordpress_sec_*`) sur ` admin.monsupersite.com/wp-admin/`, Login Armor laisse passer la requête, WordPress charge l’admin normalement. * Le 404 que vous voyez signifie donc que **vos cookies d’auth ne sont pas envoyés à `admin.monsupersite.com`** par votre navigateur. C’est typique d’une config multisite headless où `COOKIE_DOMAIN` n’est pas défini avec le wildcard sous- domaine. Sans cette définition, WordPress crée le cookie scopé sur le hostname exact où vous vous êtes connecté, et il n’est plus envoyé sur les autres sous- domaines. * Solution à tester : ajoutez dans votre `wp-config.php` (avant la ligne `/* That's all, stop editing! */`) : * ```wp-block-code define( 'COOKIE_DOMAIN', '.monsupersite.com' ); // remplacez par votre domaine, le point initial est important ``` * Le `.` initial autorise le cookie sur tous les sous-domaines (`admin.monsupersite. com`, `monsupersite.com`, et tout autre `*.monsupersite.com`). Reconnectez-vous via `admin.monsupersite.com//` après ce changement, le redirect vers`/ wp-admin/` devrait passer. * Si ça ne suffit pas (par exemple si un plugin tiers force un autre `COOKIE_DOMAIN`), je peux aussi vous fournir un mu-plugin de debug qui dump l’état des cookies au moment de la requête sur `/wp-admin/`. Dites-moi. * Merci encore pour le retour, ça a directement déclenché V2.1.9 + V2.1.10 sur WP.org. * Thread Starter [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 17 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899699) * Tout fonctionne bien sur le site avec le domaine principal (ID 1) admin.monsupersite. com/ affiche la page de login sans redirection. Une fois les identifiants saisis, la connexion est effectuée et la page /wp-admin s’affiche.Je n’avais pas précisé, mon multisite n’est pas en sous-domaines avec site1.monsupersite. com, site2.monsupersite.com… Mais en sous-répertoires.J’ai donc des domaines externes qui n’ont rien à voir avec le domaine principal, et là ça ne fonctionne plus, normal vu que le domaine du cookie ne correspond plus au site. * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 17 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899721) * Bonjour graphandco, Merci d’avoir confirmé que V2.1.9/V2.1.10 résolvent votre cas principal. Pour vos sous-sites mappés sur des domaines externes : de notre côté on s’arrête là sur Login Armor, pour la raison que vous avez identifiée vous-même : un cookie d’auth ne peut pas traverser deux domaines DNS distincts(` monsupersite.com` ≠ `domaineexterne1.com`). C’est une limite cookie HTTP, pas quelque chose qu’un plugin peut contourner sans monter un système SSO complet( avec tokens + redirects), ce qui sort du périmètre de Login Armor. * Deux pistes pour vous selon ce que vous voulez : * **1. Auth séparée par domaine externe (le plus simple)** * Chaque sous-site garde son propre flow login. Vos admins se connectent directement sur `domaineexterne1.com//`, le cookie est posé sur `domaineexterne1. com`, le redirect post-login va sur `domaineexterne1.com/wp-admin/`. Login Armor stocke le slug en `blog_option` (per-site) et V2.1.9+ génère l’URL de login depuis` site_url()` — donc si vos sous-sites ont leur `siteurl` correctement mappé sur le domaine externe (cas standard du domain mapping), ça fonctionne sans rien faire de plus. * Si pour une raison X vous voulez forcer un hostname différent de `site_url()`( par exemple `siteurl` reste sur le réseau d’origine mais vous voulez que la page de login soit servie sur le domaine externe), le filtre `login_armor_login_url_base` introduit en V2.1.9 permet de l’overrider per-site. Snippet générique à laisser ici pour quiconque tombe sur ce thread avec un cas similaire — à déposer dans` wp-content/mu-plugins/la-multisite-login-domain.php` : * ```wp-block-code hostname (avec scheme) 2 => 'https://domaineexterne1.com', 3 => 'https://domaineexterne2.com', // une ligne par sous-site à customiser ]; $blog_id = get_current_blog_id(); if ( isset( $custom_hosts[ $blog_id ] ) ) { return $custom_hosts[ $blog_id ] . $path; } return $url; // default site_url() pour les autres }, 10, 4 ); ``` * **2. SSO centralisé** sur `admin.monsupersite.com` * Tous les admins se connectent au même endroit puis sont redirigés vers leur sous- site via tokens. Le plugin **WP MU Domain Mapping** (gratuit, mature) propose exactement ça avec son option “Login Mapping”. C’est la voie standard pour ce cas, hors périmètre Login Armor. * Votre retour a directement déclenché V2.1.9 + V2.1.10 sur WP.org, encore merci. Bonne route ! * Thread Starter [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 17 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899746) * Je suis content si vous avez pu procéder aux mises à jour suite à mon retour. Pour mon problème, j’avais essayé d’autres plugins, mais ils n’étaient pas aboutis comme peut l’être Login Armor. Ils fonctionnaient avec mon installation, à part qu’ils utilisaient aussi home_url et non pas site_url. Mais d’avoir des domaines différents sur les sites ne posait pas de problème.Je n’ai pas fouillé sous leur capot, peut-être qu’il y avait un système SSO. Mes compétences backend php s’arrêtent là ! * En tous cas, bravo pour votre travail et merci pour la réactivité, je recommanderai votre plugin, longue vie au dev made in France et à Login Armor ! * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 16 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899781) * Merci infiniment pour ce retour, ça fait vraiment plaisir. * L’info sur les autres plugins qui gèrent les domaines externes est précieuse — c’est probablement effectivement un mécanisme de SSO style WP MU Domain Mapping( token signé en URL pour transiter d’un domaine à l’autre, qui se traduit en cookie auth de l’autre côté). On l’a noté dans notre backlog roadmap pour V2.2+, si la demande remonte d’autres utilisateurs en multisite domain-mapping on regardera comment l’intégrer proprement dans Login Armor sans casser le périmètre actuel“ Hide / Block / Watch”. * Et merci pour le bouche-à-oreille, c’est exactement ça qui fait vivre les plugins gratuits et indépendants. Bonne continuation sur votre projet multisite, et n’hésitez pas à revenir sur le forum si vous croisez d’autres edge cases. * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 16 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899789) * Re-bonjour graphandco, Petit complément après inspection du code de Defender ( que je suspecte être l’autre plugin qui fonctionnait pour vous) : Defender ne fait pas de SSO cross-domain, il fait simplement du multisite-aware site_url() avec switch_to_blog(). C’est exactement ce que Login Armor V2.1.9 fait depuis ce matin. * Donc en pratique, votre setup multisite + domain mapping devrait marcher avec Login Armor 2.1.10 si vous accédez directement à domaineexterne1.com// au lieu de passer par admin.monsupersite.com. Chaque sous-site a son propre flow login indépendant sur son domaine, cookie posé sur le bon hostname, redirect /wp-admin sur ce hostname, no cross-domain issue. * N’hésitez pas à tester si c’est ce que vous cherchez. Bonne soirée. * Thread Starter [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 16 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899806) * Merci pour ce feedback ! * Le plugin en question que je ne voulais pas citer est en fait WPS Hide Login. Avec Login Armor, le comportement évoqué sur le domaine principal fonctionne. monsiteprincipal.com/connexion => page de login sans redirection => saisie des identifiants => accès au dashboard avec l’url changée en /wp-admin * Sur monautredomaine.com/connexion => redirection immédiate sur wp/admin avant même d’accéder à la page de login => 404 direct * Donc là la valeur du cookie n’a rien à voir. * Thread Starter [graphandco](https://wordpress.org/support/users/graphandco/) * (@graphandco) * [6 days, 15 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899858) * Update après quelques recherches. En fait je n’avais que des sites avec des domaines externes. Après ajout d’un nouveau site, j’avais un loop de 302 sur mondomaineprincipal. com/monnouveausite/wp-adminMême avec Login Armor désactivé du multisite. * Étant sur docker et caddy, je n’avais pas de .htaccess. Après création et mise en place des RewriteRule, Login Armor fonctionne sur ce nouveau site, mais sur les domaines externes j’ai toujours une 404 immédiate. - This reply was modified 6 days, 14 hours ago by [graphandco](https://wordpress.org/support/users/graphandco/). * Plugin Author [wpformation](https://wordpress.org/support/users/wpformation/) * (@wpformation) * [6 days, 13 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899947) * Bravo pour le diagnostic ! Effectivement, pas de .htaccess sur Docker + Caddy = pas de RewriteRule WordPress = boucle 302 sur /wp-admin/ indépendamment de Login Armor. Confirmé par votre test avec LA désactivé. * Pour info, V2.1.11 a quand même été publiée entre temps (HideLogin::build_login_url() host-aware + dual-base matching dans intercept_request) => c’est une amélioration robuste pour les setups multisite + domain mapping en général, même si dans votre cas spécifique c’était la config web server qui posait souci. Donc rien à perdre à mettre à jour, et ça vous protège contre des cas similaires futurs. * Merci d’avoir creusé jusqu’à la cause root et de l’avoir partagé ici — votre stack Docker + Caddy n’est pas la plus courante côté WordPress, et votre retour aidera d’autres utilisateurs qui tombent sur le même symptôme. Bonne continuation! Viewing 11 replies - 1 through 11 (of 11 total) You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Furl-hide-login%2F%3Foutput_format%3Dmd&locale=en_US) to reply to this topic. * ![](https://ps.w.org/login-armor/assets/icon-256x256.png?rev=3517031) * [Login Armor](https://wordpress.org/plugins/login-armor/) * [Frequently Asked Questions](https://wordpress.org/plugins/login-armor/#faq) * [Support Threads](https://wordpress.org/support/plugin/login-armor/) * [Active Topics](https://wordpress.org/support/plugin/login-armor/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/login-armor/unresolved/) * [Reviews](https://wordpress.org/support/plugin/login-armor/reviews/) * 11 replies * 2 participants * Last reply from: [wpformation](https://wordpress.org/support/users/wpformation/) * Last activity: [6 days, 13 hours ago](https://wordpress.org/support/topic/url-hide-login/#post-18899947) * Status: resolved