Confirmer le site qui manque et la liste consultée
Vous pouvez ouvrir l’accueil public d’un site WordPress, mais son nom a disparu de la liste du compte où vous êtes connecté. Vous pouvez aussi voir deux titres identiques sans savoir lequel ouvrir. Relevez l’adresse publique complète, l’adresse d’administration que l’équipe utilisait et le nom de la liste consultée. Dans une installation en sous-dossier ou dans un réseau, le chemin qui suit le domaine peut distinguer deux sites. Une copie de préproduction peut partager le titre de la version publique.
Vérifiez d’abord l’adresse connue en tant que visiteur, puis ouvrez l’administration depuis un favori vérifié ou le lien donné par l’équipe du site. Notez si l’écran s’ouvre, demande une connexion ou affiche un accès refusé. Ne saisissez vos identifiants qu’après avoir vérifié le domaine exact. Si un lien reçu vous dirige vers un formulaire inhabituel, reprenez l’adresse officielle que vous connaissez et demandez confirmation de la destination à l’administrateur.
Conservez une autre adresse témoin visible dans la liste. Si elle reste présente, le problème peut être limité à un site, une invitation ou un filtre. Si toute la liste a changé, commencez par l’identité et la vue utilisées. L’objectif est de retrouver le bon site avec les droits prévus et une preuve claire de l’endroit où l’accès se gère.
Repartir de la liste complète sur WordPress.com
Depuis WordPress.com, ouvrez le tableau de bord d’hébergement avec le logo WordPress en haut à gauche. Si vous êtes sur la page d’un seul site, revenez à la liste générale. Videz la recherche, ouvrez les filtres actifs et retirez ceux qui limitent les résultats. Le tableau permet notamment de filtrer par offre, visibilité, état de préproduction ou sites supprimés. Les libellés varient selon la langue et les filtres proposés à votre compte.
Cherchez l’adresse complète puis une partie distinctive de son nom. Regardez aussi les sites au titre similaire et leurs adresses. Une ancienne adresse gratuite peut encore être associée à un site dont le domaine public a changé. Si un résultat correspond à une préproduction, notez-le avant de poursuivre. Ouvrir la fiche d’un site depuis la liste ne modifie ni sa visibilité ni son contenu.
Si le site revient dès que le filtre est retiré, l’accès existait déjà. Gardez la liste générale ou un favori vérifié pour y revenir sans modifier ses utilisateurs.
- Notez la recherche et les filtres affichés.
- Revenez à la liste générale, retirez les filtres et cherchez le domaine ou l’adresse connue.
- Comparez les adresses des résultats qui portent le même titre.
- Ouvrez la fiche correcte et vérifiez l’adresse affichée avant de passer à WP Admin.
- Remettez les filtres d’origine seulement si cette vue vous reste utile.
Comparer l’identité du compte sans interrompre une session utile
Ouvrez votre profil depuis le tableau de bord et relevez votre nom de compte ainsi que l’adresse affichée, sans les transmettre dans un espace public. Comparez ces éléments à la consigne de l’équipe ou à l’invitation d’origine. Deux adresses proches, par exemple personnelle et professionnelle, peuvent appartenir à des comptes différents même si le même nom et la même photo apparaissent. Une méthode de connexion via un fournisseur externe peut aussi ouvrir une identité différente de celle attendue.
Si vous disposez de deux comptes que vous êtes autorisé à utiliser, comparez-les dans deux profils distincts du navigateur. Conservez la session qui fonctionne déjà. Ouvrez directement WordPress.com dans le second profil, connectez le compte voulu et répétez le contrôle de la liste sans filtre. Cherchez l’adresse du site, puis vérifiez votre profil avant d’ouvrir WP Admin. Une fenêtre séparée permet de faire cette comparaison sans effacer les cookies des autres sites.
Dans un jeu de données fictif, deux équipes voyaient chacune un site intitulé « Atelier ». Les domaines étaient différents. Le domaine recherché apparaissait dans le profil de la deuxième équipe. Un autre résultat, dans le premier profil, était simplement masqué par un filtre de préproduction. Les deux vérifications donnent des indices différents. Conservez seulement l’identité et l’adresse qui correspondent à votre intervention.
Vérifier une invitation encore en attente
Si quelqu’un devait vous ajouter à un site WordPress.com, demandez à un administrateur autorisé d’ouvrir Utilisateurs, puis la liste des utilisateurs de ce site. L’interface peut montrer les invitations en attente dans la rubrique équipe ou dans la colonne de statut de connexion, selon son mode. Faites confirmer le site exact, l’identité invitée et le rôle prévu. Une invitation en attente ne donne pas les mêmes accès qu’une inscription terminée.
Ouvrez l’invitation reçue sur le compte prévu, après avoir vérifié son expéditeur et sa destination. Relisez le nom de compte affiché avant d’accepter. Revenez ensuite à la liste générale et cherchez l’adresse. Le rôle attendu doit permettre le travail convenu. Une personne qui doit relire ou rédiger un article n’a pas nécessairement besoin des réglages du domaine ou de la facturation.
Si l’adresse invitée était erronée, demandez au responsable de vérifier et, le cas échéant, de retirer l’invitation incorrecte avant d’en émettre une nouvelle vers l’identité validée. Évitez de créer un doublon ou de renvoyer plusieurs invitations par réflexe. Dans le jeu fictif, le site n’apparaissait qu’après le passage de l’état en attente à l’état actif pour le compte prévu. La recette n’a utilisé ni compte WordPress.com ni courriel réel.
Identifier les changements de propriétaire ou d’équipe
Si vous voyiez le site auparavant, demandez ce qui a changé depuis votre dernier accès. Relevez une éventuelle sortie d’équipe, un transfert, la reprise du site par une agence ou un changement d’adresse du compte. Le propriétaire du domaine, le propriétaire du site et la personne qui paie l’offre peuvent être différents. Une facture ou un accès à la zone DNS ne suffit donc pas à établir le rôle dont vous disposez dans WordPress.
Faites confirmer le propriétaire actuel et l’administrateur qui peut consulter les utilisateurs. Demandez un accès limité au travail prévu plutôt qu’un transfert de propriété. Si un transfert était effectivement prévu, le responsable vérifie son résultat et les rôles conservés. Réutilisez un compte existant lorsque l’équipe l’a déjà validé. Pour corriger un accès éditorial, les réglages d’abonnement et la propriété du domaine n’ont généralement pas besoin d’être changés.
Si le propriétaire légitime a perdu l’accès à son propre compte WordPress.com et ne peut plus utiliser les méthodes ordinaires de connexion, utilisez la procédure de récupération officielle de ce service. Rassemblez les éléments demandés uniquement dans son formulaire autorisé. Évitez de joindre des mots de passe, des codes à usage unique ou des clés à un message d’assistance. Une autre personne disposant encore des droits nécessaires peut d’abord confirmer le statut du compte sans modifier le site.
Vérifier l’administration locale d’un site auto-hébergé
Un site WordPress auto-hébergé peut disposer de son propre compte d’administration. Il peut apparaître dans le tableau WordPress.com lorsqu’une liaison prévue existe et fonctionne. Si vous utilisez normalement l’administration locale, ouvrez l’adresse WordPress confirmée par le responsable de l’installation. Vérifiez que vous êtes sur le bon site et que votre compte local y a le rôle attendu. La simple présence ou absence du site dans une liste hébergée ne dit pas si ce compte local fonctionne.
Si l’administration locale s’ouvre et que les opérations habituelles fonctionnent, notez si vous avez réellement besoin de la liste centralisée. Une connexion d’un site à un service externe peut avoir plusieurs usages et être gérée par une autre personne. Demandez au responsable de vérifier l’état du connecteur existant et l’identité qui lui est associée, avant de tenter une reconnexion. Une déconnexion globale peut toucher d’autres personnes et les fonctions déjà utilisées.
Si l’administration locale refuse aussi la connexion, confirmez d’abord l’adresse et la méthode d’accès habituelles. Demandez au responsable de rechercher votre compte sur cette installation. Ce cas relève du contrôle de l’identité locale ou des droits du site. Évitez de créer une deuxième installation, d’enregistrer une nouvelle adresse ou de modifier la configuration du domaine pour retrouver la liste.
Contrôler l’appartenance à un sous-site multisite
Dans un réseau multisite, ouvrez Mes sites avec le compte concerné et repérez le domaine ou le chemin du sous-site attendu. Un compte peut exister dans le réseau et intervenir sur un premier site tout en étant absent du second. L’accès au tableau d’administration du réseau relève d’un rôle distinct. Demandez à l’administrateur réseau de confirmer que le sous-site existe, qu’il est actif et que le compte est membre de ce site précis.
Comparez le rôle attendu à l’action prévue. Si l’utilisateur doit éditer des pages du sous-site, vérifiez le rôle convenu sur ce seul site. Si le compte existe déjà, l’administrateur autorisé peut le rattacher au sous-site avec les fonctions du réseau, en tenant compte de sa politique d’invitation. Il peut ensuite vérifier la liste avec ce compte et tester une seule action prévue. N’accordez pas de droits de super administrateur pour faire apparaître un sous-site dans Mes sites.
Un sous-site archivé, supprimé ou marqué comme indésirable peut être absent de la liste ordinaire. Si l’état du site explique l’écart, faites confirmer le motif et la décision du responsable avant tout changement. L’apparition du site après attribution d’un rôle ne prouve pas que les autres restrictions sont résolues. Testez l’action utile et laissez les autres sites intacts.
Lire l’inventaire et le rôle sur la copie avec WP-CLI
Si vous administrez déjà ce réseau avec WP-CLI, vous pouvez relever la présence et l’état du sous-site, puis vérifier l’appartenance du compte. Les commandes suivantes sont prévues pour une copie autorisée. Remplacez l’adresse de l’atelier et le nom de compte par ceux que vous avez confirmés. Contrôlez d’abord le dossier où vous lancez WP-CLI. Deux réseaux peuvent employer le même nom de compte.
La première commande donne l’adresse et les indicateurs du sous-site. La seconde indique si le compte appartient au sous-site que désigne le paramètre url. Un compte reconnu par la seconde commande peut rester sans rôle à cet endroit. Gardez les résultats dans votre dossier privé et remplacez les noms réels par des repères avant de transmettre un exemple à l’assistance.
Ces contrôles lisent l’état de la copie. Aucune réinitialisation du compte ni modification du DNS n’est nécessaire. Si la liste affichée dans l’administration diverge de ce relevé, vérifiez le compte, le réseau, l’état du site et les éventuelles règles personnalisées qui construisent l’affichage.
wp --url="http://atelier.example.test" site list --fields=blog_id,url,archived,spam,deleted --format=table
wp --url="http://atelier.example.test/atelier/" eval '$u=get_user_by("login","lecteur-exemple"); if (!$u) { echo "Compte absent du reseau\n"; } else { echo is_user_member_of_blog($u->ID,get_current_blog_id()) ? "Membre du site\n" : "Compte present, acces au site non attribue\n"; }'Confirmer la correction avec deux identités de test
Sur la copie multisite, un premier compte fictif disposait d’un site et le second compte avait une affectation indépendante. Le sous-site cible existait dans l’inventaire du réseau, mais ne figurait pas pour le premier compte. Après attribution du rôle éditeur sur ce seul sous-site, la liste du premier compte comportait deux sites. Celle du second n’a pas changé. Le retrait de la seule nouvelle affectation a rétabli les listes d’origine et le premier compte est resté présent dans le réseau.
Sur votre copie, choisissez deux comptes et un site témoin, puis définissez le résultat attendu pour chaque personne. Vérifiez la liste avant et après, l’adresse d’administration et une action permise par le rôle. Si vous testez WordPress.com, vérifiez l’invitation et l’identité selon le tableau de bord, avec l’administrateur qui maintient le site. Les comparaisons fictives illustrent la démarche. Elles ne reproduisent pas l’interface hébergée ni les éventuelles politiques de votre équipe.
Si un rôle a été ajouté par erreur, retirez la seule affectation qui a été créée, en vérifiant la conservation de l’auteur des contenus et des accès existants. Évitez de supprimer le compte global pour corriger une association à un sous-site. Si la correction s’est limitée à un filtre ou à un changement de profil, revenez simplement à votre vue habituelle après le contrôle.
Transmettre le relevé si le site reste introuvable
Préparez le nom du service ou du réseau, l’adresse complète, le résultat de l’ouverture directe de l’administration et les filtres vérifiés. Indiquez si l’accès a déjà fonctionné pour ce même compte et la date du dernier changement connu. Une personne de l’équipe peut alors rechercher l’invitation, un autre site au titre identique ou un changement de rôle sans rouvrir toutes les pistes.
Si l’invitation est active et que l’administrateur confirme le bon compte sur le bon site, notez l’écart exact entre accès direct et résultat dans la liste. Si le site lui-même n’est plus joignable, demandez d’abord de confirmer son état chez l’hébergeur ou dans le réseau. La disparition de la liste et une panne publique peuvent coïncider. Vérifiez ces deux résultats séparément avant de décider d’une récupération.
Clôturez le diagnostic lorsque l’adresse confirmée est visible, que l’utilisateur entre par la voie prévue et qu’il retrouve ses capacités habituelles. Notez le chemin à utiliser à l’avenir et la personne qui peut vérifier un rôle ou une invitation. Ces indications évitent de changer de mot de passe ou de multiplier les comptes lors de la prochaine confusion.
