The application password
Which WordPress account to use, where the password comes from, how to revoke it.
An application password is a WordPress credential you create for one program and revoke without touching your own login. wpreef uses one per site. It is the only thing that lets anything change your site, and it is the boundary that actually decides what an assistant can do.
Pick the account first
The role of the account is the limit. Nothing in wpreef widens it.
| You want the assistant to | Role |
|---|---|
| Write and edit posts, pages and media | Editor |
| Change design, templates, menus, navigation, widgets, plugins or users | Administrator |
Design work needs the edit_theme_options capability, which is an administrator capability. A
design-capable credential is an admin credential. If the work is content and media, use an
Editor account and keep it that way.
Why this matters
wpreef does not sandbox the model. It hands over a WordPress credential and shapes how easily each capability is reached. The closed list of sites and the role of this account are the two boundaries the model cannot write around.
Create it
Make a dedicated user.
Do not reuse your own login. Users → Add New, with the role you chose above.
Open that user's profile.
Users → Profile → Application Passwords, at the bottom.
Name it.
wpreefis a fine name. WordPress shows the password once, in blocks of four characters. Copy it as shown.Paste it here.
Sites → Add site, together with the site URL and the username. wpreef authenticates against the site before it saves anything; a credential that does not work is never stored.
WordPress also has a direct authorize link. Open
https://example.com/wp-admin/authorize-application.php on your own site and it offers to
create the password for you. npx wpreef doctor --add https://example.com prints that link
for the site you name.
Revoke it
Users → Profile → Application Passwords → Revoke, on the site itself. The credential stops working immediately, for wpreef and for anything else holding it. Your own login is unaffected.
Removing the site from wpreef also removes the stored credential, but revoking on WordPress is the change that matters: it is the only one your site enforces.
What the site needs
Three things, and npx wpreef doctor tests all three and prints the fix for each:
- HTTPS, or
WP_ENVIRONMENT_TYPE=localfor a local site. WordPress refuses to issue application passwords otherwise. - The REST API reachable — no plugin or host rule blocking
/wp-json/. - The
Authorizationheader passed through to PHP. Some Apache and FastCGI setups strip it.
wpreef never creates credentials
No route in wpreef can mint an application password. The request guard refuses
/wp/v2/users/*/application-passwords unconditionally, on every toolset, including the raw
request tool. Creating and revoking happen in wp-admin, by you.