Comprendre pourquoi le formulaire de création manque
Dans le tableau de bord d’un sous-site WordPress, un administrateur ouvre Comptes > Ajouter et ne voit que le formulaire « Ajouter un compte existant ». C’est le symptôme signalé sur le forum. Le réseau WordPress sépare la création d’un compte commun et l’attribution d’un rôle sur un sous-site. L’administrateur local peut avoir le droit de rattacher un compte connu alors que le réseau réserve la création de nouveaux comptes à ses administrateurs. Dans la configuration standard qui produit ce symptôme, le compte local peut donc fonctionner normalement.
Trois états permettent de situer le besoin. Le compte peut être absent du réseau. Il peut exister dans le réseau sans être membre du sous-site. Il peut enfin être membre du sous-site avec un rôle qui ne permet pas l’action souhaitée. Vérifiez aussi une éventuelle invitation en attente. Le message qui indique qu’un courriel a été envoyé ne signifie pas que la personne a déjà accepté le rôle. Une personne qui voit l’administration d’un autre sous-site peut parfaitement manquer du rôle nécessaire sur celui-ci.
Commencez par l’adresse exacte du tableau de bord. Dans la barre d’administration, utilisez Mes sites et sélectionnez le sous-site concerné. Vérifiez son nom et son domaine avant de regarder la liste des comptes. Les libellés « Comptes » et « Utilisateurs » peuvent varier selon la traduction ou la version. Sur une installation sans réseau, l’absence du formulaire suit un autre parcours de droits. Sur un service géré, vérifiez que vous êtes dans l’administration WordPress du site et que la gestion des comptes n’est pas prise en charge par un autre panneau.
- Relevez l’adresse du sous-site et le rôle attendu pour la personne. Déterminez si elle possède déjà un compte sur ce réseau.
- Ouvrez Comptes > Tous les comptes sur le sous-site, puis l’écran d’ajout. Notez si aucun formulaire n’apparaît ou si seul l’ajout d’un compte existant est disponible.
- Demandez à un super administrateur de vérifier l’existence du compte dans la liste du réseau si vous ne pouvez pas le faire. Une recherche infructueuse sur le sous-site ne suffit pas à décider qu’il faut créer un nouveau compte.
Rattacher un compte existant avec les droits du sous-site
Si la personne a déjà un compte réseau et que vous pouvez utiliser « Ajouter un compte existant », ouvrez ce formulaire sur le bon sous-site. Avec les droits ordinaires de l’administrateur de site, le formulaire natif demande l’adresse du compte existant. Certaines configurations proposent aussi une recherche par nom. Utilisez l’adresse exacte confirmée par le responsable ou par la personne concernée. Une suggestion absente pendant la saisie ne prouve pas que le compte manque. Le cœur peut limiter l’autocomplétion et celle-ci peut aussi dépendre du réseau.
Choisissez le rôle minimal qui convient à la tâche. Un compte destiné à préparer des articles peut recevoir le rôle retenu pour ce travail, sans devenir administrateur. Consultez la liste des rôles proposée par le sous-site. Les rôles personnalisés peuvent différer entre deux sites d’un même réseau. Avant de valider, vérifiez que l’adresse du tableau de bord et le nom du site correspondent à la demande. Si la personne est déjà membre, examinez son rôle actuel depuis la liste du sous-site et ne lancez pas une seconde invitation pour corriger un rôle.
Lorsque le formulaire envoie une confirmation, demandez à la personne de suivre l’invitation prévue et de se connecter avec son compte réseau. Dans une recette, utilisez une boîte de capture et une identité fictive. Si le message reste absent, notez l’adresse et l’heure dans le dossier autorisé, vérifiez la réception et faites confirmer l’état du compte. Répéter l’invitation à plusieurs adresses risque de lier un mauvais compte ou de laisser des confirmations en circulation. Si la personne a accepté mais ne voit toujours pas le sous-site, vérifiez la liste du sous-site et la session avant d’envoyer un nouveau lien.
- Sous Comptes > Ajouter, choisissez le formulaire d’ajout d’un compte existant et renseignez l’identité exacte, avec le rôle prévu.
- Suivez l’étape de confirmation quand l’écran l’annonce. Ouvrez ensuite Comptes > Tous les comptes sur le sous-site et cherchez l’identité ajoutée.
- Vérifiez l’accès avec ce compte et une action permise par son rôle. Si vous avez rattaché le mauvais compte, retirez son appartenance depuis le sous-site, après avoir vérifié l’impact sur ses contenus et ses autres accès.
Créer le compte depuis l’administration du réseau
Cette voie convient à un super administrateur lorsqu’aucun compte ne correspond à la personne et qu’il faut l’ajouter à un seul site. Dans la barre, ouvrez Mes sites > Administration du réseau > Comptes. Recherchez l’identifiant et l’adresse avant toute création. Un ancien compte peut exister avec un autre nom affiché. Si une adresse est déjà utilisée, vérifiez son propriétaire. Une seconde identité ajoutée pour contourner ce contrôle pourrait accéder à des contenus qui ne lui sont pas destinés.
Dans l’administration du réseau, ouvrez Comptes > Ajouter et créez l’identité avec le nom et l’adresse prévus. Surveillez les messages sur la création et la notification. La présence du compte dans Comptes du réseau confirme sa création, tandis que sa présence dans Comptes du sous-site confirme l’appartenance. Pour effectuer les deux contrôles au même endroit, le super administrateur peut ouvrir Sites > Tous les sites, modifier le sous-site et choisir l’onglet Comptes. Dans le cœur, cet écran peut proposer l’ajout d’un compte existant et la création d’un nouveau compte directement pour ce site. Des filtres ou une interface gérée peuvent modifier les formulaires proposés.
Si la création et l’ajout ont lieu sur le même écran mais que l’ajout échoue, vérifiez quand même la liste réseau. Le compte peut avoir été créé avant l’erreur d’affectation. Réutilisez-le lors de la correction du rattachement au lieu de demander une nouvelle adresse. Si l’interface réseau permet un ajout immédiat sans confirmation d’appartenance, contrôlez l’identité et la portée avant de le faire. La notification de création du compte et l’invitation sur un site sont deux étapes qui peuvent suivre des chemins différents.
- Recherchez le compte dans la liste du réseau. Créez-le seulement si son absence est confirmée.
- Ouvrez Sites > Tous les sites > Modifier > Comptes pour le sous-site visé. Ajoutez le compte existant avec le rôle prévu et vérifiez la ligne obtenue.
- Contrôlez un deuxième sous-site témoin. Le nouveau rôle doit apparaître sur le premier, avec les droits attendus. Sur le second, l’appartenance doit correspondre à l’état relevé avant l’opération.
Vérifier si le réseau délègue la création
Si les administrateurs de plusieurs sous-sites doivent régulièrement créer de nouveaux comptes, le responsable du réseau peut examiner Mes sites > Administration du réseau > Réglages > Réglages du réseau. Dans les réglages d’inscription, l’option d’ajout de nouveaux comptes par les administrateurs de site correspond à add_new_users. Cette case vise le réseau. L’autorisation d’inscription publique est un autre réglage, avec une autre portée. Pour une demande ponctuelle, la création et le rattachement par le super administrateur permettent de conserver la politique actuelle.
En configuration native, un super administrateur peut créer des comptes en multisite même lorsque la délégation est désactivée. Avec un administrateur local, WordPress exige que la politique réseau le permette et que le rôle possède la capacité create_users. Le formulaire d’ajout d’un compte existant est présenté selon promote_users. La soumission vérifie ensuite les droits pour la personne ciblée. Voir le formulaire ne garantit donc pas que toute promotion sera autorisée. Une extension peut modifier les capacités ou filtrer les formulaires de l’administration réseau. Si les contrôles natifs paraissent satisfaits mais que l’interface est différente, comparez les extensions et le compte dans une recette.
- Notez la valeur du réglage et les administrateurs concernés. Si la délégation est souhaitée par le réseau, testez-la sur une copie avec deux sous-sites et des comptes fictifs.
- Enregistrez le réglage réseau dans la recette, puis reconnectez-vous comme administrateur local. Vérifiez que le formulaire de création apparaît pour ce compte et reste hors de portée d’un compte éditorial sans droits de gestion.
- Pour revenir à la politique initiale, rétablissez la case dans Réglages du réseau. Contrôlez la disparition du formulaire chez l’administrateur local. Les comptes créés pendant le test subsistent tant que vous ne traitez pas séparément leurs appartenances ou leur cycle de vie.
Comparer les capacités et l’appartenance dans un terminal
Avec un accès WP-CLI autorisé, enregistrez la sonde ci-dessous dans un fichier privé nommé verifier-ajout-compte.php. Elle utilise deux identifiants, d’abord le compte qui ouvre l’écran d’ajout puis le compte qu’il faut rattacher. Les valeurs d’exemple sont fictives. Exécutez wp --path="/chemin/recette" --url="https://site-a.recette.example.test" eval-file "/chemin/prive/verifier-ajout-compte.php" 42 85. Choisissez une URL de sous-site et vérifiez le numéro affiché. Répétez avec l’URL du site témoin. Aucun compte ni rôle n’est modifié par le script.
Lisez create_users et promote_users séparément. Un résultat non puis oui est cohérent avec l’écran du forum. invite_existe=oui associé à invite_membre=non indique que le compte est reconnu par le réseau et manque d’appartenance sur la cible. Si les deux valent oui, vérifiez le rôle dans la liste du site. La sonde mesure les contrôles natifs dans le contexte du terminal. Elle ne vérifie ni une invitation en attente, ni l’autorisation d’attribuer un rôle particulier, ni l’affichage d’une page modifiée par une extension. Exécutez-la sur des comptes connus et ne sautez pas le chargement des extensions lors de la comparaison.
Si creation_deleguee=oui mais que create_users=non, vérifiez que le compte possède la capacité appropriée sur le bon sous-site. Si la valeur diffère entre les deux URL, comparez ses rôles et les extensions de chaque sous-site. Si le terminal et le navigateur se contredisent, vérifiez que l’identifiant inspecté est celui de la session, puis recherchez une règle qui dépend de l’écran ou du contexte. Consignez les valeurs sans relever l’adresse des comptes dans le rapport.
<?php
if (!is_multisite()) {
WP_CLI::error('La cible ne fait pas partie d’un réseau multisite.');
}
$operateur = filter_var($args[0] ?? null, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]]);
$invite = filter_var($args[1] ?? null, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]]);
if (count($args) !== 2 || $operateur === false || $invite === false) {
WP_CLI::error('Indiquez deux identifiants entiers et positifs.');
}
$compte_operateur = get_userdata($operateur);
if (!$compte_operateur) {
WP_CLI::error('Compte opérateur introuvable sur le réseau ciblé.');
}
$site = get_current_blog_id();
$compte_invite = get_userdata($invite);
$etat = static fn (bool $valeur): string => $valeur ? 'oui' : 'non';
WP_CLI::log(sprintf(
'site=%d creation_deleguee=%s super_admin=%s create_users=%s promote_users=%s invite_existe=%s invite_membre=%s',
$site,
$etat((bool) get_site_option('add_new_users', false)),
$etat(is_super_admin($operateur)),
$etat(user_can($compte_operateur, 'create_users')),
$etat(user_can($compte_operateur, 'promote_users')),
$etat((bool) $compte_invite),
$etat($compte_invite && is_user_member_of_blog($invite, $site))
));Tester la politique sur deux sous-sites de recette
Préparez deux sous-sites qui ont des noms différents. Sur le premier, utilisez un administrateur local et un compte réseau fictif qui est membre uniquement du second. Notez son rôle sur le second avant le test. Si la délégation est désactivée, comparez l’écran du premier site dans la session de l’administrateur local et dans celle du super administrateur. Le premier doit pouvoir voir l’ajout d’un compte existant s’il possède le droit, et le second doit pouvoir accéder à la création. Fermez la session entre les deux lectures pour éviter de prendre les menus d’un compte pour ceux de l’autre.
Toujours en recette, rattachez le compte fictif au premier site avec un rôle adapté. Lorsque le sous-site passe par une invitation, vérifiez les résultats avant et après la confirmation interceptée. Avant la confirmation, l’invitation peut être enregistrée tandis que le compte n’apparaît pas encore comme membre. Après confirmation, la liste doit montrer le même identifiant et le nouveau rôle. Sur le second site, contrôlez que l’identifiant et le rôle sont ceux du début. Ce test permet de détecter une modification involontaire du mauvais site même lorsque le message de succès semble correct.
Faites un deuxième contrôle avec une identité fictive que le réseau ne connaît pas. Le formulaire pour compte existant ne suffit pas à l’ajouter. Créez-la par l’administration réseau, vérifiez d’abord sa présence dans la liste réseau, puis attribuez un rôle au premier site. La sonde du terminal doit pouvoir distinguer ces deux moments. Si un écran d’extension les regroupe, vérifiez les deux listes après une erreur. Terminez le test en retirant l’appartenance ajoutée sur le premier site. Utilisez la même identité pour vérifier que le second site conserve son état initial.
Valider l’accès et prévoir son retrait
Le résultat utile associe une identité réseau, un rôle local et une action observable. Fermez les sessions administratives et connectez-vous sur le sous-site avec le compte fictif ajouté. Ouvrez l’écran requis et testez une action prévue par le rôle, par exemple créer un brouillon sans le publier si le compte sert à préparer des articles. Vérifiez également une action qui doit rester interdite, telle que l’administration du réseau pour un compte éditorial. Sur le deuxième sous-site, comparez le rôle et l’accès à l’état initial. Si l’utilisateur y avait déjà un rôle, le test doit retrouver ce rôle.
Si l’interface annonce une invitation mais que le compte manque toujours dans la liste, contrôlez d’abord la confirmation et la bonne session. Si le compte apparaît avec un rôle, mais que l’action échoue, traitez la capacité de l’action elle-même. Si le site est archivé, désactivé ou géré par une extension d’accès, vérifiez son état et les règles en vigueur avant de recommencer l’ajout. Le même formulaire peut rester masqué sur un seul sous-site à cause d’une personnalisation. Faites reproduire le résultat avec les comptes et le chemin précis de recette.
Pour retirer un accès attribué par erreur, ouvrez la liste du sous-site et choisissez l’action locale de retrait. Vérifiez les conséquences sur les contenus associés et suivez la procédure de réattribution de votre réseau lorsque nécessaire. La suppression du compte depuis l’administration réseau a une autre portée. Après le retrait local, vérifiez que le compte existe encore dans le réseau, que l’accès visé est retiré et que ses autres rôles restent corrects. Retirez enfin le fichier de sonde de la recette et consignez le site, le rôle et le résultat des deux témoins.
