Reconnaître une panne de connexion liée au domaine
Le sous-site s’affiche sur son nouveau domaine, mais son formulaire revient sans cesse à la connexion, affiche un avertissement sur les cookies ou renvoie vers l’ancienne adresse. Le résultat recherché est une session qui reste ouverte sur le bon sous-site, sans casser l’accès au site principal. Une page publique accessible ne suffit pas à valider cette session.
Ce guide concerne un WordPress autohébergé en multisite dont un sous-site reçoit un domaine indépendant, par exemple une boutique auparavant située sur boutique.reseau.example. Les domaines d’exemple sont fictifs. Le rattachement est natif depuis WordPress 4.5. Un ancien tutoriel exigeant systématiquement une extension de domain mapping ne décrit donc pas nécessairement votre installation actuelle.
Relevez la version de WordPress, le type de réseau et le moment du changement. Si le domaine reste introuvable, utilisez le diagnostic du sous-domaine multisite. Si la connexion réussit et qu’une action est refusée, faites vérifier les droits du compte. Lorsque le formulaire répond mais que la session ne tient pas, conservez le premier symptôme observé avant de poursuivre.
Préparer un retour arrière sans perdre l’accès au réseau
L’administrateur d’un sous-site ne possède pas forcément les accès nécessaires pour corriger son rattachement. Prévoyez un super administrateur pour les réglages réseau et un responsable disposant de SFTP ou du gestionnaire de fichiers pour une éventuelle correction de configuration. La session fonctionnelle de ce responsable doit rester dans son navigateur habituel. Réservez un profil séparé aux essais.
Avant toute modification, consignez l’identifiant du sous-site, son ancienne adresse, la nouvelle adresse attendue et les redirections déjà mises en place. Une copie du fichier wp-config.php doit rester hors du répertoire public. Si vous changez des données du réseau, gardez aussi une sauvegarde cohérente de sa base. Ne remplacez pas une sauvegarde complète par une capture de l’écran Sites.
Définissez une seule hypothèse par intervention. Corriger une faute dans l’adresse puis réessayer permet de mesurer son effet. Si vous changez le domaine, les cookies et le proxy à la fois, vous ne saurez pas quel réglage a eu un effet. Convenez aussi de la condition de retour arrière : perte d’accès au réseau, régression sur un autre sous-site ou absence d’amélioration du symptôme ciblé. Le retour arrière rétablit la valeur sauvegardée, pas une valeur trouvée dans un autre tutoriel.
Contrôler le certificat et le bon sous-site avant de saisir un mot de passe
Faites pointer les deux hôtes de recette vers la même copie WordPress. Le serveur doit pouvoir présenter un certificat valable pour chaque nom utilisé. Ouvrez d’abord la page publique en HTTPS, puis consultez les détails du certificat dans le navigateur. Vérifiez le nom dans la liste des noms alternatifs, la période de validité et la confiance dans le certificat. En recette, utilisez le certificat approuvé pour ce seul environnement. Un certificat qui couvre le domaine du réseau ne couvre pas automatiquement un domaine indépendant.
En cas d’avertissement TLS, arrêtez avant l’identification. Vérifiez le nom exact, la destination Web et le certificat avec le mainteneur. Si un proxy reçoit les connexions, confirmez que le certificat présenté au navigateur couvre le nom de la page demandée et que WordPress détecte correctement HTTPS derrière ce proxy. Gardez les protections du navigateur actives. Le guide sur les certificats qui ne couvrent pas le domaine détaille ce diagnostic.
Quand TLS est correct, vérifiez le titre ou un texte fictif propre au sous-site puis contrôlez le site principal depuis un autre profil. Le titre confirme le site choisi par WordPress. L’adresse du certificat confirme le nom présenté par le serveur. Consignez ces deux observations avant de tester la session. Si plusieurs sous-sites changent en même temps de forme d’adresse, suivez le guide de bascule du réseau.
Vérifier l’adresse réellement enregistrée pour le sous-site
Ce premier parcours convient lorsque l’échec est apparu juste après la saisie du domaine. Avec le compte super administrateur, ouvrez Mes sites, Administration du réseau, Sites, puis Modifier sous le sous-site concerné. Dans l’onglet des informations, examinez Adresse du site (URL). Le libellé peut varier avec la traduction, mais l’identifiant du site doit correspondre à votre relevé.
Comparez le protocole, le nom d’hôte et le chemin. https://exemple.example et https://www.exemple.example sont deux hôtes distincts. Une ancienne portion /boutique/ conservée sans raison peut également envoyer l’administration au mauvais endroit. Utilisez l’adresse prévue par l’architecture de ce sous-site, en conservant le chemin requis par un réseau installé dans un sous-répertoire.
Si la valeur est incorrecte, recopiez d’abord l’original, saisissez l’adresse complète correcte puis enregistrez. Ouvrez ensuite cette adresse dans le profil d’essai. La page publique et le formulaire doivent rester sur l’hôte attendu. Si le domaine atteint un autre site, revenez au diagnostic de rattachement serveur avant de poursuivre. En cas de régression, rétablissez l’adresse originale depuis la session réseau conservée. Ne changez ni le domaine principal du réseau ni SUBDOMAIN_INSTALL pour corriger une seule fiche.
Essayer la connexion directement sur l’adresse canonique
Un favori ancien ou un lien contenant une destination de retour peut donner l’impression que l’identification échoue. Dans le profil réservé aux essais, saisissez directement l’URL HTTPS canonique du sous-site suivie de /wp-login.php, en conservant son éventuel chemin d’installation. N’utilisez pas, pour ce contrôle, un lien reçu avant le rattachement du domaine.
Connectez-vous une fois avec votre propre compte autorisé, puis ouvrez son tableau de bord et rechargez la page. Notez l’adresse avant l’envoi, l’adresse finale et le message exact. Si la connexion directe fonctionne mais que le favori échoue, corrigez le lien d’accès ou la redirection concernée. Ce résultat ne justifie aucune modification globale des cookies.
Un domaine indépendant ne peut pas recevoir automatiquement un cookie destiné à un autre domaine indépendant. Le même compte réseau peut donc demander une nouvelle identification sur chacun. Ce comportement ne signifie pas que le mot de passe a changé. Une connexion unique entre domaines relève d’un mécanisme supplémentaire déjà conçu pour cela. Ne tentez pas de la créer en donnant au cookie une liste de domaines : cet attribut n’accepte pas une telle liste. Si le formulaire boucle également en accès direct, observez maintenant la session plutôt que de répéter les mots de passe.
Observer les cookies sans exposer leur contenu
Les outils du navigateur permettent de voir si le serveur propose un cookie que le navigateur refuse ou ne renvoie pas. Dans Chrome, ouvrez les outils de développement, puis Application, Storage, Cookies et l’origine du sous-site. Les traductions peuvent afficher Stockage. Gardez cette inspection dans le profil d’essai, afin de préserver les connexions de secours.
Relevez seulement le nom, le domaine, le chemin, l’expiration et les indicateurs de sécurité des cookies WordPress. Leur valeur est un secret de session. Gardez-la hors des tickets et des captures. Le panneau Network, en sélectionnant la requête de connexion puis Cookies, aide aussi à lire un motif de blocage. Notez ce motif avec l’URL, sans exporter toute la session.
Le domaine annoncé doit être compatible avec l’hôte qui émet la réponse. Un cookie proposé pour l’ancien domaine du réseau depuis un nouveau domaine indépendant sera refusé. Le chemin doit couvrir l’URL suivante et un cookie Secure nécessite HTTPS pour être renvoyé. Ne modifiez pas manuellement ces attributs dans le navigateur : une édition locale masquerait temporairement la configuration du serveur. Si une capture est nécessaire, masquez les valeurs avant de la transmettre et conservez uniquement les colonnes utiles à l’hypothèse examinée.
Distinguer cookie refusé et redirection vers l’ancien domaine
L’absence d’une session persistante ne prouve pas à elle seule que le domaine du cookie est incorrect. Dans le panneau Network du profil d’essai, observez la réponse au formulaire et les requêtes qui suivent. Les en-têtes de réponse indiquent notamment une éventuelle destination Location et les cookies proposés. Un retour vers l’ancien domaine peut précéder toute utilisation du nouveau cookie.
Si le nouvel hôte émet déjà des cookies compatibles mais que la navigation repart ailleurs, examinez la règle de redirection ajoutée lors du rattachement. Elle peut se trouver dans le panneau de l’hébergeur, le serveur Web ou une extension existante. Le responsable de cette couche compare sa règle avec la destination voulue, puis corrige seulement la règle identifiée. Une suppression générale des redirections du réseau n’est pas un diagnostic.
Le résultat attendu est un parcours stable : formulaire, tableau de bord, rechargement, toujours sur l’adresse canonique. Le retour arrière rétablit la règle sauvegardée si d’autres URL sont affectées. Si le navigateur signale au contraire explicitement un domaine de cookie incompatible, gardez cette observation et passez au parcours de configuration. Évitez d’envoyer un fichier HAR brut : il peut contenir des paramètres, en-têtes et données d’authentification sans utilité pour le premier échange.
Corriger une portée de domaine confirmée dans wp-config.php
Ce parcours est réservé au mainteneur du réseau lorsque l’inspection montre que le nouveau domaine indépendant reçoit un cookie destiné à l’ancien domaine. Dans un réseau en sous-domaines, le cœur peut définir une portée commune à partir du domaine réseau. Une constante personnalisée ajoutée autrefois peut aussi imposer cette ancienne portée.
Avec SFTP ou le gestionnaire de fichiers autorisé, ouvrez le fichier wp-config.php effectivement chargé par cette installation. Recherchez COOKIE_DOMAIN, sans afficher le fichier complet dans un ticket : il contient aussi des identifiants de base et des secrets. Une constante existante doit être examinée et remplacée à son emplacement, pas redéfinie une deuxième fois. Une configuration gérée par l’hébergeur doit être corrigée dans sa source de gestion.
Pour un réseau dont l’architecture accepte des connexions séparées par hôte, le mainteneur peut retenir un domaine vide afin que les cookies restent propres à l’hôte émetteur. Cette variante découle du fonctionnement des constantes et de l’émission PHP. Réservez-la aux réseaux qui acceptent des sessions indépendantes. Elle change également le comportement de connexion entre les sous-domaines ordinaires. La documentation de rattachement propose une autre variante liée à l’hôte de la requête. Conservez une seule politique de portée. Choisissez une politique unique après avoir recensé les accès que le réseau doit conserver.
Appliquer la variante par hôte avec une seule définition
L’exemple suivant convient uniquement au cas confirmé ci-dessus, après essai sur une copie représentative du réseau et validation du mainteneur. Il ne corrige ni un mauvais chemin de cookie ni une redirection externe. Il faut pouvoir restaurer immédiatement le fichier depuis SFTP si l’administration devient inaccessible.
Placez cette définition dans wp-config.php, après les réglages de création du réseau et avant le chargement de wp-settings.php. Si COOKIE_DOMAIN est déjà défini, modifiez sa définition existante et gardez une seule occurrence active. Pour cette variante, laissez le domaine vide. N’ajoutez pas de nouveau bloc PHP à l’intérieur du fichier.
Après enregistrement, utilisez le profil d’essai pour produire une nouvelle connexion et vérifiez que la réponse ne propose plus l’ancien attribut Domain. Les cookies anciens ne sont pas automatiquement réécrits : repartez d’un profil propre ou effacez uniquement les cookies de l’hôte testé dans ce profil. Vérifiez ensuite le site principal et un sous-site non remappé. Si l’objectif exige une session partagée entre ces hôtes, cette variante peut être inadaptée. Restaurez alors la définition précédente et faites concevoir la politique multidomaine, sans supprimer les clés de sécurité du réseau.
define( 'COOKIE_DOMAIN', '' );Examiner le chemin des cookies sans généraliser la racine
Un cookie peut être accepté pour le bon domaine et rester absent d’une requête parce que son chemin ne couvre pas l’adresse visitée. Comparez la colonne Path avec l’URL du tableau de bord. Par exemple, un cookie limité à une ancienne portion /boutique/ ne couvrira pas nécessairement une administration désormais servie directement sous /wp-admin/.
Le mainteneur recherche alors les définitions personnalisées de COOKIEPATH, SITECOOKIEPATH et ADMIN_COOKIE_PATH dans la configuration et les composants spécifiques au réseau. Le cœur calcule aussi certaines valeurs à partir du chemin réseau et de l’installation. Il faut donc comparer l’architecture réelle, les éventuelles constantes imposées et les en-têtes observés avant de modifier un chemin.
N’appliquez pas systématiquement la valeur / à toutes ces constantes. Un WordPress installé sous un chemin particulier ou une architecture de domaines avec proxy peut nécessiter une autre portée. La correction consiste à supprimer ou ajuster une ancienne personnalisation dont l’incompatibilité est démontrée, dans sa source de configuration et après sauvegarde. Le résultat doit être un cookie renvoyé à l’URL exacte de l’administration, puis une session stable. Si le chemin était déjà correct, conservez-le : la prochaine investigation doit porter sur HTTPS ou sur le composant d’authentification, sans accumuler de modifications préventives.
Vérifier HTTPS et le composant d’authentification existant
Un proxy inverse peut recevoir HTTPS depuis le visiteur et communiquer autrement avec PHP. Si WordPress interprète mal cette chaîne, des URL ou des cookies peuvent devenir incohérents. Comparez le protocole visible, les redirections et la configuration HTTPS documentée par l’hébergeur. Ne retirez pas Secure et ne désactivez pas HTTPS pour faire passer la connexion.
Ce cas demande au responsable serveur de vérifier les informations transmises par le proxy de confiance et leur traitement côté PHP. Copier une condition qui fait confiance à n’importe quel en-tête X-Forwarded-Proto reçu ne constitue pas une correction sûre. La relation de confiance doit être définie sur l’infrastructure. Activer FORCE_SSL_ADMIN ne répare pas à lui seul une détection erronée et peut entretenir une boucle.
Si le réseau emploie déjà une connexion externe, une double authentification ou un système de connexion unique, relevez son nom et sa version. Examinez dans sa documentation officielle les domaines de retour autorisés et le rattachement des sous-sites. Corrigez seulement le paramètre identifié et conservez sa valeur précédente. Ne désactivez pas la protection de tout le réseau pour vérifier une hypothèse. Le résultat attendu est un aller-retour complet vers le fournisseur puis vers le bon sous-site, sans assouplissement global des règles du navigateur.
Valider la session et séparer le problème des droits
La validation doit couvrir davantage qu’un écran de connexion réussi. Dans le profil d’essai, ouvrez le tableau de bord du domaine personnalisé, rechargez-le puis consultez une page de gestion autorisée à votre compte. Revenez ensuite sur le site public et contrôlez que son adresse reste cohérente. Une nouvelle demande d’identification sur un autre domaine indépendant peut être conforme à la politique choisie.
Répétez un contrôle avec le compte super administrateur sur le site principal et avec un utilisateur ordinaire autorisé sur un sous-site non remappé. Cette vérification compare les usages réellement concernés par une constante commune. Elle n’implique ni publication, ni paiement, ni changement de mot de passe. Si une seule de ces connexions régresse après la modification, appliquez le retour arrière prévu avant d’élargir les essais.
Si l’utilisateur est reconnu mais voit un refus d’accès, faites vérifier sa présence et son rôle dans Sites, Modifier, Utilisateurs pour le sous-site concerné. Un compte existe au niveau du réseau sans posséder nécessairement un rôle sur chaque site. Ajouter correctement ce rôle, avec l’autorisation du responsable, répond à un autre besoin que l’émission du cookie. Ne donnez pas le statut de super administrateur pour contourner une simple affectation manquante.
Rejouer le rattachement et le retour avec le même sous-site
Sur une copie jetable, choisissez un sous-site et un compte éditeur autorisé. Dans l’exemple, le site 2 passe de https://atelier.reseau.test/ à https://atelier-association.test/. Le site principal garde https://reseau.test/. Les deux noms du sous-site sont déjà desservis par la copie et le client de recette approuve son certificat local. Relevez la fiche du site, les valeurs home et siteurl, le titre du contenu témoin et l’état des redirections. Conservez les réglages de départ avec la sauvegarde de la base.
Validez une connexion à l’adresse initiale avant le changement. Sur la copie, enregistrez le nouveau domaine dans la fiche du site 2. Vérifiez que l’identifiant n’a pas changé et que home et siteurl correspondent au plan. Depuis un profil neuf, demandez /wp-admin/ et observez la destination vers /wp-login.php. Ouvrez le formulaire, connectez-vous puis rechargez l’administration. Relevez le statut, l’hôte, le chemin et les attributs des cookies, sans noter leurs valeurs. Dans cette recette, la politique approuvée limite chaque session à son hôte.
Déclenchez le retour si le certificat est refusé, si un autre sous-site répond, si la session ne tient pas ou si un témoin du réseau régresse. Rétablissez l’ancienne adresse de la fiche et vérifiez home et siteurl. Remettez les réglages de proxy, de redirection et de cookie que vous auriez changés pour la bascule. Si plusieurs réglages sont devenus incohérents, restaurez la sauvegarde de la copie plutôt que de reconstituer ses valeurs de mémoire.
Refaites une connexion neuve sur l’ancien hôte, puis ouvrez et rechargez son administration. Une ancienne session encore ouverte ne suffit pas à vérifier ce retour. Comparez le site principal au témoin initial et confirmez que le sous-site a gardé son identifiant. Une boucle qui existe aussi en dehors du changement de domaine relève du guide de la connexion et des cookies. Pour contrôler les exclusions du cache de la connexion et des comptes, consultez le guide sur le cache des pages personnalisées.
- Vérifier le certificat, l’adresse et une connexion neuve avant le rattachement.
- Contrôler le même identifiant, les options, la session et les cookies sur le domaine rattaché.
- Revenir à la fiche précédente et refaire la connexion au domaine initial.
Conserver un relevé utile pour les prochains rattachements
Terminez par un relevé court : identifiant du sous-site, ancienne adresse, nouvelle adresse, symptôme initial, motif de rejet éventuel et correction retenue. Ajoutez les hôtes utilisés lors des vérifications et le résultat sur le site principal. Ce relevé permet de distinguer une amélioration locale d’un changement qui a seulement déplacé la panne vers un autre membre du réseau.
Si le blocage demeure, transmettez au mainteneur les noms des constantes personnalisées, les chemins observés et les destinations de redirection, sans leurs secrets. Le nom du cookie et son attribut Domain suffisent souvent à discuter une portée incorrecte. Mentionnez aussi une authentification externe existante et le rôle du proxy lorsqu’il intervient. Un message précis évite une réinitialisation générale des comptes.
Pour le prochain domaine, préparez dans cet ordre son routage, son certificat, sa fiche de sous-site et son parcours de connexion. Notez explicitement si les sessions doivent être indépendantes ou partagées. Aucune nouvelle extension de domain mapping n’est requise par défaut pour cette procédure native. Une extension supplémentaire ne doit être envisagée que pour une fonction définie, telle qu’une connexion unique entre domaines, avec une étude distincte de sa compatibilité et de ses effets.
