Most WordPress tips and tricks posts are really emergency notes. That is fine until you are the person responsible for a live client site, a handover, or a locked-out administrator account. In that situation, the goal is not cleverness. It is restoring access with the least risk, the clearest audit trail, and the fewest side effects.
If you need to recover a WordPress admin account today, use this order: try WP-CLI first, use direct SQL only when that is the only access you have, and treat old MD5 password tricks as a temporary compatibility fallback rather than a normal operating method.
Start with WP-CLI, not raw SQL
For most business owners, ops leads, and agencies, WP-CLI is the safest fast path. It lets WordPress handle the update properly instead of you hand-editing user data and hoping nothing else depends on it.
wp user list --role=administrator --fields=ID,user_login,user_email --format=table
wp user update 1 [email protected] --skip-email
wp user update 1 --user_pass='A-long-unique-password'This gives you a clean operational flow: confirm the right administrator account, change the recovery email, and set a new password without manually generating hashes. On a live site, that is usually better than creating a second admin account that nobody remembers to remove later.
If you are managing more than one environment, use the same commands on staging first. That sounds obvious, but it is where many rushed recovery jobs go wrong: the fix works, but it gets applied to the wrong site or the wrong user.
If you only have MySQL access, keep the change narrow
There are still cases where wp-admin is inaccessible and WP-CLI is unavailable. In those cases, direct SQL can get you back in. The key is to change as little as possible. First, confirm the actual table prefix and the correct user record. Many sites do not use the default wp_ prefix, and in multisite the users table is shared across the network.
SELECT ID, user_login, user_email
FROM yourprefix_users
ORDER BY ID;If the problem is simply that the admin email is outdated or inaccessible, update only that field first. That often restores the normal password reset route without changing anything else.
UPDATE yourprefix_users
SET user_email = '[email protected]'
WHERE ID = 1;This is the useful core of the original note, and it still holds up. It is simple, low risk, and easy to reverse if you confirmed the right user before running the update.
The old MD5 password trick is now a last resort
Older WordPress notes often recommend generating a hash with echo -n 'password' | md5sum and inserting that value into the database. That advice is no longer complete. Current WordPress versions store new passwords using stronger hashing, and older hashes are handled for backward compatibility.
That means the old MD5 trick can still get you unstuck, but it should be treated as a temporary recovery move, not standard practice. If database access is truly your only tool, this is the shortest path back in:
UPDATE yourprefix_users
SET user_pass = MD5('temporary-strong-password')
WHERE ID = 1;After the next successful login, replace that temporary password through wp-admin or WP-CLI so WordPress stores a current hash. Do not leave a legacy-style password in place just because the incident is over.
This is also a good place to sanity-check the age of any snippet you copied from an old forum thread. Current WordPress core uses a varchar(255) field for user_pass, and password handling changed again in WordPress 6.8. If a how-to article assumes much older hashing behavior, treat the rest of its advice cautiously.
Use Application Passwords for integrations and vendor access
A lot of WordPress access problems start because a team reused a real admin password for a script, a reporting tool, or a third-party service. WordPress has a better built-in option: Application Passwords. They are meant for programmatic access, can be revoked individually, and are easier to manage than a shared administrator login that ends up in chat messages, tickets, and onboarding docs.
A simple rule works well: one application password per integration, name it clearly, and revoke it when the tool or vendor no longer needs access. That gives you a cleaner handover path and reduces the blast radius if one credential leaks.
A short recovery checklist for live sites
- Take a database backup or snapshot before changing user records.
- Confirm whether the site is single-site or multisite before editing the users table.
- Change one thing at a time: email first, then password if needed.
- After access is restored, remove temporary credentials and record the final handover path.
- If the site uses SSO, membership plugins, or custom authentication, test carefully because the WordPress user record may not be the only moving part.
Most WordPress access incidents are not technically difficult. They become expensive because ownership is fuzzy, shortcuts stay in place, and nobody writes down the safe recovery route. A small amount of operational discipline prevents a lot of repeat drama.
If you want a calmer setup for WordPress operations, recovery, or agency handover, Greg can help put the process and implementation in place without overcomplicating it.
Need help with this kind of work?
Need Greg to make WordPress operations and handovers less fragile? Get in touch with Greg.