WordPress multisite shows only “Add Existing User”

Understand why the creation form is missing

In a WordPress subsite dashboard, an administrator opens Users > Add New and sees only “Add Existing User”. This is the symptom reported on the forum. A WordPress network separates creation of a shared account from assignment of a role on a subsite. The local administrator may be allowed to add a known account while the network reserves new-account creation for its administrators. In the standard configuration producing this symptom, the local account can therefore be working normally.

Three states establish the need. The account may be absent from the network. It may exist in the network without being a subsite member. Finally, it may be a member with a role that cannot perform the desired action. Also check for a pending invitation. A message saying an email was sent does not mean the person has already accepted the role. Someone who can see another subsite's administration area may still lack the necessary role on this one.

Start with the exact dashboard address. In the admin bar, use My Sites and select the affected subsite. Check its name and domain before examining users. Labels may vary with translation or version. On an installation without a network, a missing form follows a different permissions workflow. On a managed service, check that you are in the site's WordPress administration area and user management is not handled by another panel.

1. Record the subsite address and intended role for the person. Establish whether they already have an account on this network.
2. Open Users > All Users on the subsite, then the add screen. Record whether no form appears or only adding an existing user is available.
3. Ask a super administrator to check account existence in the network list if you cannot. An unsuccessful subsite search is insufficient reason to create a new account.

Add an existing account using subsite permissions

If the person already has a network account and you can use “Add Existing User”, open that form on the correct subsite. With ordinary site-administrator permissions, the native form asks for the existing account's email address. Some configurations also offer name search. Use the exact address confirmed by the owner or person concerned. No suggestion during typing does not prove the account is missing. Core may restrict autocomplete, which can also depend on the network.

Choose the least privileged role suited to the task. An account preparing posts can receive the role designated for that work without becoming an administrator. Consult the subsite's offered roles. Custom roles may differ between two sites in one network. Before submitting, check that the dashboard address and site name match the request. If the person is already a member, inspect their current role in the subsite list instead of sending a second invitation to correct it.

When the form sends confirmation, ask the person to follow the intended invitation and log in with their network account. In staging, use a capture mailbox and dummy identity. If the message does not arrive, record the address and time in the authorized record, check receipt and have account status confirmed. Repeated invitations to several addresses risk linking the wrong account or leaving confirmations circulating. If the person accepted but still cannot see the subsite, check the subsite list and session before sending another link.

1. Under Users > Add New, select the existing-user form and enter the exact identity with the intended role.
2. Follow the confirmation step when the screen announces it. Then open Users > All Users on the subsite and find the added identity.
3. Check access with that account and an action its role permits. If you added the wrong account, remove its subsite membership after checking effects on its content and other access.

Create the account through Network Admin

This route suits a super administrator when no account matches the person and they need adding to one site. In the bar, open My Sites > Network Admin > Users. Search the username and address before creating anything. An old account may exist under another display name. If an address is already used, verify its owner. A second identity added to bypass this check might access content not intended for it.

In Network Admin, open Users > Add New and create the identity with the intended name and address. Watch creation and notification messages. Presence in the network Users list confirms creation, while presence in the subsite Users list confirms membership. To perform both checks in one place, the super administrator can open Sites > All Sites, edit the subsite and choose Users. In core, this screen may offer both adding an existing user and creating a new user directly for this site. Filters or a managed interface may alter the available forms.

If creation and addition occur on the same screen but addition fails, check the network list anyway. The account may have been created before the assignment error. Reuse it when correcting membership instead of requesting a new address. If the network interface allows immediate addition without membership confirmation, check identity and scope before doing so. Account-creation notification and site invitation are separate steps that may follow different paths.

1. Search for the account in the network list. Create it only when absence is confirmed.
2. Open Sites > All Sites > Edit > Users for the target subsite. Add the existing account with the intended role and check the resulting row.
3. Check a second control subsite. The new role should appear on the first with expected permissions. Membership on the second should match the pre-operation state.

Check whether the network delegates creation

If administrators of several subsites regularly need to create accounts, the network owner can inspect My Sites > Network Admin > Settings > Network Settings. Under registration settings, the option allowing site administrators to add new users corresponds to add_new_users. This checkbox applies network-wide. Public registration permission is a different setting with another scope. For a one-off request, creation and addition by the super administrator preserve the current policy.

In the native configuration, a super administrator can create multisite accounts even when delegation is disabled. For a local administrator, WordPress requires both network policy permission and the role's create_users capability. The existing-user form is shown according to promote_users. Submission then checks permissions for the targeted person. Seeing the form therefore does not guarantee every promotion is authorized. A plugin may modify capabilities or filter Network Admin forms. If native checks appear satisfied but the interface differs, compare plugins and account in staging.

1. Record the setting value and affected administrators. If the network wants delegation, test it on a copy with two subsites and dummy accounts.
2. Save the network setting in staging, then log back in as the local administrator. Check that the creation form appears for this account and remains unavailable to an editorial account without management permissions.
3. To return to the original policy, restore the checkbox under Network Settings. Check that the form disappears for the local administrator. Accounts created during testing persist until you separately handle their memberships or lifecycle.

Compare capabilities and membership in a terminal

With authorized WP-CLI access, save the probe below in a private file named verifier-ajout-compte.php. It uses two IDs: first the account opening the add screen, then the account to add. Example values are fictional. Run wp --path="/chemin/recette" --url="https://site-a.recette.example.test" eval-file "/chemin/prive/verifier-ajout-compte.php" 42 85. Choose a subsite URL and check the displayed number. Repeat with the control site's URL. The script changes no account or role.

Read create_users and promote_users separately. A non then oui result is consistent with the forum screen. invite_existe=oui with invite_membre=non means the network recognizes the account but it lacks membership on the target. If both are oui, check the role in the site list. The probe measures native checks in terminal context. It checks neither a pending invitation, permission to assign a particular role nor the display of a plugin-modified page. Run it on known accounts and do not skip plugin loading during comparison.

If creation_deleguee=oui but create_users=non, check that the account has the appropriate capability on the correct subsite. If the value differs between the two URLs, compare its roles and each subsite's plugins. If terminal and browser contradict one another, verify the inspected ID matches the session, then look for a screen- or context-dependent rule. Record values without including account addresses in the report.

<?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))
));

Test the policy on two staging subsites

Prepare two subsites with different names. On the first, use a local administrator and a dummy network account that belongs only to the second. Record its role on the second before testing. If delegation is disabled, compare the first site's screen in the local-administrator session and super-administrator session. The first should see adding an existing user if permitted, and the second should access creation. Log out between readings to avoid mistaking one account's menus for the other's.

Still in staging, add the dummy account to the first site with an appropriate role. When the subsite uses an invitation, check results before and after captured confirmation. Before confirmation, the invitation may be recorded while the account is not yet listed as a member. After confirmation, the list should show the same ID and new role. On the second site, check that ID and role match the beginning. This detects unintended changes to the wrong site even when the success message looks correct.

Perform a second check with a dummy identity unknown to the network. The existing-user form cannot add it by itself. Create it through Network Admin, first verify presence in the network list, then assign a role on the first site. The terminal probe must distinguish these moments. If a plugin screen combines them, check both lists after an error. End by removing the membership added on the first site. Use the same identity to verify that the second retains its initial state.

Validate access and plan removal

The useful result combines a network identity, local role and observable action. Close administration sessions and log into the subsite with the added dummy account. Open the required screen and test an intended role action, such as creating a draft without publishing if the account prepares posts. Also check an action that must remain prohibited, such as Network Admin for an editorial account. On the second subsite, compare role and access with the initial state. If the user already had a role there, the test must recover that role.

If the interface announces an invitation but the account is still absent from the list, first check confirmation and the correct session. If the account appears with a role but the action fails, address that action's capability. If the site is archived, deactivated or managed by an access plugin, check its status and current rules before adding again. The same form may remain hidden on only one subsite due to customization. Have the result reproduced using the precise staging accounts and path.

To remove mistakenly granted access, open the subsite list and choose local removal. Check consequences for associated content and follow your network's reassignment procedure where necessary. Deleting the account from Network Admin has a different scope. After local removal, check that the account still exists in the network, targeted access is removed and other roles remain correct. Finally remove the staging probe file and record the site, role and results of both controls.

Choose the role before adding the account

For a writer proposing text without publishing, start with Contributor on the staging subsite. Author adds, among other things, publication and management of their own posts; Editor covers other people's content. Plugins can modify these capabilities: validate an actual action instead of relying only on the role name.

Before adding, prepare a small decision table: confirmed network identity, target subsite, expected task and selected role. For occasional writing access, do not grant super-administrator status to make a form appear. The super administrator can perform native membership addition for free while leaving account-creation policy unchanged.

After invitation acceptance, open a private session with the dummy account and create a draft. Also check that an unneeded action, such as managing network plugins, remains unavailable. To end the test, remove only target-subsite membership, check attributed content and confirm the network account and control-site role remain.