WordPress user management

What it does

Client sites collect WordPress accounts: a contractor added to six sites last spring, an admin account left over from the build, a client’s former employee who still has Editor. Sites → WordPress users lists every account on every connected site in one table, grouped by person — by email address, so jane@agency.com on five sites is one row with five role chips — and lets you change those accounts across sites in one go.

It is part of Studio, Agency and Scale (the 14-day Agency trial includes it). Each site needs the WPClientHub One plugin 0.11.0 or newer; an older plugin shows Update WPClientHub One to manage users instead.

What you see

• Person: name, email and username(s). An administrator called admin, administrator or test is marked Guessable username.
• Sites & roles: one chip per site with the role there (“brightleaf.co · Administrator”).
• Last sign-in: the most recent across their sites, or Inactive 90+ days, or Not recorded yet — see Last sign-in below.
• 2FA: On, Off or Some sites when the site runs a two-factor plugin we can read (Two Factor, WP 2FA, Wordfence Login Security or Solid Security); Unknown otherwise — never a guessed “off”.
• Filters: search by name, email or username; by role; by site; and quick filters for Administrators, Inactive 90+ days and On N+ sites.

Each site also has a Users tab with the same information for that site alone, plus post counts, and the same actions.

The lists are read from each site once a day (spread over the early hours, UTC) and whenever you press Sync now; a site’s Users tab reads it straight away the first time it is opened. Every change you make from WPClientHub updates the list immediately.

Changing accounts across sites

Open the ⋯ menu on a person (or Add a person at the top), pick the sites, check the summary, and confirm. You then see a result for every site — done, skipped (already that way) or failed, with the reason in plain words. Changes to more than 3 sites run in the background with a progress bar; you can close the dialog and keep working.

• Add to sites with a role. By default WordPress emails them its own “set your password” link. Or choose Generate a password and show it to me once: each site generates a strong password and it appears in the dialog once — it is never stored by WPClientHub (not in the database, the activity log or a queued job), so copy it before closing. Because of that, generated passwords work for up to 5 sites at a time; for more, use the email. Someone who already has an account on a site is left as they are and shown as skipped.
• Change role on the chosen sites.
• Remove from sites. WordPress needs someone to hand the account’s posts, pages and links to, so for every site you choose who receives them. The default — shown next to each site — is the site’s first other administrator; you can pick any other user of that site instead. Content is reassigned, never deleted.
• Reset password: WordPress sends its own password-reset email. Tick Also sign them out everywhere to end their current sessions too.
• Log out everywhere: ends every session they have on the chosen sites. Their password does not change — reset it as well if it may have leaked.

What the site always refuses

These rules are checked by WPClientHub before anything is sent, and again by the plugin on the site itself:

• A site’s last administrator is never removed or demoted. Add another administrator there first.
• Removing an account always needs someone to receive its content, and that person must be another user of the same site.
• If an account’s email changed since the last sync, the change is refused (“Sync and try again”) rather than applied to the wrong person.
• On a multisite network, only the current site is managed: removing someone takes them off that site, and network super admins are never removed from a site.
• A site owner can switch the whole feature off on their site with the wpch_allow_user_management filter; the site then shows as switched off.

Last sign-in

WordPress does not record when someone last signed in. From version 0.11.0 the WPClientHub One plugin records it on every sign-in (including one-click logins from WPClientHub); before that, the newest still-active session is the best a site knows. So right after the update most people show Not recorded yet.

Someone counts as inactive when their last recorded sign-in is more than 90 days old — or when the site has been recording for at least 90 days and has none for them. A person is shown as inactive only if they are inactive everywhere we can tell; one recent sign-in anywhere makes them active.

In the Security report

On every plan (no Studio needed), each site’s Security report has three rows about administrators, under Hardening and Access & transport:

• Administrator count is sane — warns above a few administrators, as before.
• No guessable administrator username — fails for an administrator called admin, administrator or test (−6).
• No unused administrator accounts — fails for each administrator with no sign-in for 90 days or more (−3 each, at most −6). Until a site has 90 days of sign-in history the row is shown as not checked and costs nothing.

Each row says how to fix it in plain words. See Security findings.

Who can do what

Every change is written to the Activity Log (Users category) as one line — for example “Removed jane@agency.com from 4 sites (content reassigned to mark)” — with who did it. The site’s own activity log records each account change too, naming the person at your agency who made it.

What is stored

For each account: login, email, display name, roles, registration date, last sign-in, two-factor status and post count. Never a password or password hash. See Security & data.

Limits & defaults

Troubleshooting