Users, Roles and Profiles

WordPress authorization has three layers:

A user’s roles are stored in the user meta key {prefix}capabilities (lp_capabilities), which can also hold individual capabilities granted on top of the role. The legacy meta key {prefix}user_level and the level_0 to level_10 capabilities are kept only for backward compatibility with plugins written before WordPress 2.0; nothing in current core decides access by level. wp role list lists the roles and wp user meta get maria.editor lp_capabilities prints array ( 'editor' => true, ) for an Editor.

The matrix below was produced from a fresh WordPress 7.1.3 site, one role at a time, with wp cap list <role>. It leaves out the eleven legacy level_N capabilities. The Administrator holds 61 capabilities (50 plus the levels level_0–level_10), the Editor 34, the Author 10, the Contributor 5 and the Subscriber 2 (read and level_0). Rows group capabilities that the five roles share in exactly the same way.

Source: WP-CLI Commands: wp cap list

Two settings on Settings → General control who may create their own account:

Source: WordPress.org Documentation: Settings General screen (Membership)

Open registration should only be enabled with Subscriber as the default role. A default role of Contributor or higher lets anyone on the internet create content in the admin, and a default of Editor or Administrator hands over the site; compromised sites are sometimes found with default_role changed to administrator and registration turned on, so both values are worth checking after an incident (wp option get users_can_register and wp option get default_role print 0 and subscriber on a default install). Registration forms also attract automated sign-ups: an anti-spam or CAPTCHA plugin, or email confirmation through a membership plugin, is the usual answer. Lumen Press keeps registration closed and creates staff accounts by hand.

The Administration Email Address on the same screen is not a user account. Changing it sends a confirmation link to the new address, and the old address stays active until the link is clicked. Multisite networks have their own registration options (users, sites, both or none) on Network Admin → Settings, covered in Multisite Networks.

Every user, whatever their role, can open Users → Profile (or the name in the top-right of the toolbar). An Administrator editing another user sees the same screen plus the Role drop-down. The fields and where they are stored:

Source: WordPress.org Documentation: Users Your Profile screen

The same values can be read and changed from the shell, for example to reset an Editor’s colour scheme:

Source: WP-CLI Commands: wp user meta

Gravatar URLs use HTTPS unconditionally since 6.7 and a SHA-256 hash of the lower-cased email since 6.8 (an MD5 hash before). Avatars can be switched off, and the default image and maximum rating chosen, under Settings → Discussion (options show_avatars, avatar_default, avatar_rating). Because the hash is derived from the email address, showing Gravatars discloses a stable identifier for every commenter to a third party; the privacy policy should say so (see SEO, Analytics and Privacy).

Source: Code Reference: get_avatar_data()

Password strength. The profile and Add New User screens generate a strong random password and show a strength meter (based on the zxcvbn library) as the user types. Core does not enforce a minimum strength: choosing a weak password only shows a Confirm use of weak password checkbox. Sites that need a policy enforce it with a plugin or with SSO.

Hashing. Since 6.8, passwords are hashed with bcrypt instead of phpass. WordPress pre-hashes the password with SHA-384 (bcrypt reads only 72 bytes), which is what the $wp$2y$ prefix in user_pass marks; existing phpass hashes keep working and are rehashed the next time the user logs in. On the test site every hash starts with that prefix:

Source: Make WordPress Core: WordPress 6.8 will use bcrypt for password hashing

Resetting a password. Users reset their own through Lost your password? on wp-login.php, which emails a reset link (so outgoing mail must work, see Email Delivery). An Administrator can send the same link from the user’s row (Send password reset) or set a password on the user’s profile. With shell access, WP-CLI is the reliable route:

Source: WP-CLI Commands: wp user reset-password

Writing an MD5 hash into user_pass with phpMyAdmin, the classic lock-out remedy, still works because WordPress accepts the old format once and rehashes it, but it is a legacy path that leaves a weak hash in the database until the next login. WP_ALLOW_REPAIR has nothing to do with passwords: it opens /wp-admin/maint/repair.php to anyone, without a login, and only repairs and optimizes tables.

Sessions. Each login creates a session token stored in the user’s session_tokens meta. Log Out Everywhere Else on the profile (or Log Out Everywhere when an Administrator views another user) destroys them. Changing the password also invalidates existing login cookies, because they are derived partly from the password hash. From the shell, wp user session list ana.contrib lists a user’s sessions and wp user session destroy ana.contrib --all ends them (it answers Success: Destroyed all sessions.); see WP-CLI Commands: wp user session.

Two-factor authentication. WordPress core has no two-factor authentication. It is added with a plugin; the canonical one is Two Factor, maintained by WordPress.org contributors, which offers authenticator-app (TOTP) codes, email codes and backup codes, with passkeys and security keys through a companion WebAuthn provider plugin. Single sign-on through an identity provider is the other common route. Lumen Press requires TOTP for the Administrator and Editors, because both roles can post unfiltered HTML. Login hardening (limiting attempts, XML-RPC) is in Security Hardening, and the methods themselves in Authentication Methods: Passwordless and 2FA.

Source: WordPress.org Plugins: Two Factor

Application passwords (since 5.6) let a script, a mobile app or another site call the REST API or XML-RPC as a user without knowing that user’s real password. Each one is a 24-character random password, shown once (grouped as six blocks of four for readability; the spaces are ignored), named after the application that uses it, and revocable on its own. They cannot be used to log in to wp-login.php, and no second factor is asked for when they are used, which is why they must be treated as secrets with the full power of the user who created them.

Where to create them. On Users → Profile → Application Passwords: type a name (for example "Lumen reader app"), click Add New Application Password, and copy the password from the notice. The list below the form shows each password’s name, creation date, last use and last IP, with a Revoke button per row and Revoke all application passwords. Administrators can do the same on another user’s profile.

When they are available. By default only when the site is served over HTTPS or WP_ENVIRONMENT_TYPE is local; on a plain-HTTP production site the section is missing from the profile. The check in WordPress 7.1.3:

Source: Code Reference: wp_is_application_passwords_supported()

The whole feature can be turned off with the wp_is_application_passwords_available filter, or restricted per user with wp_is_application_passwords_available_for_user. Lumen Press allows them only for staff who can write; this must-use plugin (wp-content/mu-plugins/lumen-app-passwords.php) hides the section from Subscribers and makes their existing application passwords stop working:

Source: Code Reference: wp_is_application_passwords_available_for_user

With the plugin active, wp_is_application_passwords_available_for_user() returned "not available" for sam.reader and "available" for tom.author, and a REST request with an application password of sam.reader was rejected with 401. WP-CLI does not apply the filter when creating a password, so the policy limits use, not creation from the shell.

The built-in roles already describe a simple newsroom. At Lumen Press:

The REST API enforces the same rules. Ana’s application password can create a pending post but not a published one:

Source: REST API Handbook: Posts (Create a Post)

The statuses and scheduling are explained in Posts and Pages. Core has no notification when a post is submitted for review, no editorial calendar, no custom statuses (such as "in copy-edit") and no per-category permissions. Those come from editorial workflow plugins, or from custom roles and capabilities in a plugin. Two practical consequences of the defaults:

The book catalogue (lp_book posts with the lp_genre and lp_series taxonomies, added by the lumen-catalog plugin) is maintained by a sales assistant who must not touch the news blog, pages or settings. No built-in role fits: an Author cannot edit books entered by others, and an Editor could rewrite every news post and page. Lumen Press therefore defines a Catalogue Manager role that may read the admin, upload cover images, create, edit, publish and delete any book (including other people’s) and manage genre and series terms, but has no access to posts, pages, comments, plugins, themes, settings, users or unfiltered HTML.

This needs capabilities of its own for the book post type rather than the post capabilities, and a role created once when the plugin is activated, not on every request. Both are implemented in Roles and Capabilities API. Plugins that edit roles from the admin exist for sites without a developer, but they write the same lp_user_roles option and survive deactivation, so a role created with them should be documented like any other configuration.