I cannot log in to the WordPress admin panel: A step-by-step solution when wp-admin will not open

Resetting a WordPress password with phpMyAdmin: The official method

If the email route is unavailable, the password can be changed directly in the database through phpMyAdmin in the hosting panel; this is one of the official methods used when an email does not arrive in an “I cannot log in to the WordPress admin panel” situation. WordPress documentation describes this method as being at the user’s own risk and recommends seeking support if unsure; this makes a database backup essential before starting. The steps in the official documentation are as follows:

1. Open phpMyAdmin from the hosting panel and select the site’s WordPress database.
2. Among the tables, wp_users is located and its Browse icon is clicked. The name differs if another table prefix was chosen during installation; the correct prefix is written in the wp-config.php file’s $table_prefix line.
3. In the user_login column, find the relevant user and select Edit.
4. In the user_pass field, delete the long character string and enter the new password.
5. Select MD5 from the function dropdown on the same row, check the value, and save with “Go.”
6. Try the new password on the login screen.

According to the official documentation, WordPress permits login when an MD5 hash is written to the field even if the existing password hash is stored in a different format. According to the WordPress 6.8 announcement on Make WordPress, passwords are now stored using bcrypt, hashes saved in the older format are converted to the new format at the user’s next login, and MD5 support is retained. Changing the password once more from the profile screen after login is an additional precaution we apply.

FTP, WP-CLI, and the emergency script

The same documentation describes three additional methods: adding a temporary wp_set_password line to the active theme’s functions.php file, using the WP-CLI wp user update command if server command-line access is available, and an emergency script uploaded to the root directory. The documentation states that the functions.php line must be removed immediately after login; otherwise, it resets the password on every page load. The emergency script must also be deleted from the server once the work is complete; leaving it in place opens the door to someone else changing the password.

WordPress login redirect loops and the “Cookies are blocked” error

If the page returns to the login screen despite entering the correct password, the cause is usually cookies or the site address setting. WordPress maintains sessions with cookies; if the browser cannot save the cookie or the cookie is written for the wrong address, login cannot complete. WordPress’s login troubleshooting documentation recommends clearing browser cookies and cache as the first step and also notes that some firewalls can prevent login.

The “Cookies are blocked” error

The error stating that cookies are blocked indicates that the browser does not accept the WordPress cookie. First clear cookies and cache for the site, then try logging in through a private window or a different browser. If login works in a private window, the problem is browser-side; if it fails in every browser, check the site address setting.

Correcting the site address with WP_HOME and WP_SITEURL

A WordPress login redirect loop can result from the WordPress address and site address on the Settings screen not matching the address where the site actually opens: www versus non-www or http versus https are the most common examples. Because the panel is inaccessible, make the correction in wp-config.php:

define( 'WP_HOME', 'https://ornek.com' );
define( 'WP_SITEURL', 'https://ornek.com' );

According to WordPress’s wp-config documentation, the address is written with https:// and no trailing slash. These lines override the database value but do not change it; deleting a line restores the old value, and while defined, the addresses cannot be edited from the Settings screen. The Changing the site URL section also specifically states that leaving the RELOCATE constant in the file is unsafe because it allows attackers to change the site address.

If the login address returns 404: Disabling the security plugin by renaming its folder

If /wp-admin or /wp-login.php returns 404, the most common cause is a security plugin having replaced the login address with a custom address. If the new address is known, use it to log in; if not, disable the plugin at file level. WordPress’s common errors documentation states that renaming wp-content/plugins disables all plugins; changing a single plugin’s folder name disables only that plugin.

1. Use the hosting panel’s file manager or FTP to open wp-content/plugins.
2. Find the folder of the plugin that changes the login address and append a suffix to its name, for example -kapali).
3. Log in through the standard /wp-login.php address.
4. Restore the folder’s original name, reactivate the plugin on the Plugins screen, and note the custom login address.

Because plugin settings remain in the database, renaming the folder does not delete them; deleting the folder makes recovery harder. WordPress’s brute force attacks documentation emphasizes that hiding the login address can reduce noise but should not be the only defense.

How do you remove a lockout after too many failed attempts?

WordPress core does not limit failed attempts by itself; a “too many attempts” lockout usually comes from a security plugin or the hosting firewall. The lockout is generally tied to an IP address and expires automatically after a certain period. If waiting is not possible, follow these methods:

• Use an unlock link in the plugin’s lockout email if one is provided.
• Try logging in from a different network, such as mobile data, meaning a different IP address.
• If the lockout comes from a plugin, temporarily rename its folder as described in the preceding section.
• If the lockout comes from the server firewall, ask the hosting company to remove the IP block.

A lockout occurring when nobody is attempting to log in may indicate automated password attempts against the login page. In that case, simply removing the lockout is insufficient; the password should be strengthened and two-step verification added.

How do you restore access if the administrator role is lost?

If login succeeds but the Plugins, Settings, or Users menus are missing, the account may have lost its administrator role. According to WordPress’s Roles and capabilities documentation, only the Administrator role has access to all administration features on a single site; Editor, Author, Contributor, and Subscriber roles work with narrower permissions. A plugin error, an incorrect bulk edit, or an attacker may have changed the role.

If another administrator account exists on the site, use that account to restore the role from the Users screen. If server command-line access is available, the WP-CLI wp user set-role command reassigns the administrator role to the user. Because role information is stored in serialized form in the database, manually editing it in phpMyAdmin can corrupt the record with a single-character error; this method requires experience.

Initial steps and signs of hacking if the account was compromised

If the user account has been deleted, its password and email changed, or unfamiliar administrator accounts have appeared, the problem is most likely an attack rather than a forgotten password. WordPress’s My site was hacked FAQ lists unauthorized creation of new users, search-engine blacklisting, and the hosting provider shutting down the site among clear signs of hacking. A detailed list of symptoms in the guide to identifying a hacked WordPress site is provided.

The initial steps recommended by the same FAQ proceed in this sequence:

1. Record the symptoms observed, the time they were noticed, and the most recent changes.
2. Scan the computer used to access the site for viruses and malware, along with the website itself.
3. Notify the hosting company; on a shared server, the problem may not be limited to one site.
4. Change not only the wp-admin password but also FTP/SFTP, hosting panel, and database passwords; reset passwords for all administrators.
5. Renew the secret keys in wp-config.php to close all remaining open sessions.
6. Back up the current state before beginning cleanup.
7. Change passwords once more after the site has been cleaned.

Regaining panel access through phpMyAdmin is only the beginning; access restored without removing backdoor files and fake users left by the attacker may soon be lost again. File-level cleanup is covered by the WordPress hacked site recovery service.

Common mistakes: Random attempts or systematic diagnosis?

What permanently complicates panel access is often panicked intervention rather than the original problem. The stories we most frequently hear from site owners saying they cannot log in to the WordPress admin panel come from the left column of the comparison below:

Systematic diagnosis identifies the symptom first, then changes a single variable and observes the outcome. Disabling plugins, changing addresses, and resetting passwords simultaneously makes it impossible to understand which step worked or what it broke.

Preventing recurrence: Two-step verification, strong passwords, and user roles

A significant proportion of login problems can be prevented through three habits: a strong and unique password, two-step verification, and user roles with permissions matched to their tasks. WordPress’s Brute force attacks documentation recommends long and unique passwords or passphrases, a password manager, and two-step verification for all administrators. Apply the following for an ongoing arrangement:

• Strong password: Do not use dictionary words, names, or numbers-only passwords; maintain a separate password for each service.
• Two-step verification: Require a second step through an authenticator app or hardware key for administrator and editor accounts.
• Least privilege: Give content contributors the Editor or Author role; retain Administrator access only for accounts that truly require it.
• Current email: Check that the email addresses in administrator accounts are accessible to the business.
• Unused accounts: Remove accounts belonging to departed employees and external service providers whose work is complete.

Plugin and theme updates, regular backups, and login-page protection are also part of this arrangement; the entire subject in the WordPress security guide is explained.

When should you consult a specialist, and how should access be shared?

Consulting a specialist makes sense when the database or wp-config.php needs to be modified, the account appears compromised, or the recommended steps fail. In an “I cannot log in to the WordPress admin panel” situation, a single incorrect query or incorrectly saved configuration file can turn a login problem into an error taking down the entire site. In the following situations, leaving intervention to someone experienced is safer:

• If hosting panel or FTP access is unavailable or has also been lost
• If unknown administrator accounts, changed email addresses, or unfamiliar files are found
• If the redirect loop involves cache, CDN, and SSL settings together
• If the site takes sales or appointments and downtime directly means lost revenue

Whichever method is chosen, passwords, hosting details, and FTP credentials are not shared with anyone through messages, email, or phone. Under our method, a separate user account is created for the service provider and removed when the work is complete, and the site owner’s own password is never requested. Refusing information to someone calling on behalf of WordPress, a hosting company, or a plugin and asking for a password is part of the same rule.

At Onur Freelance, login problems and similar faults are handled within the annual WordPress maintenance and update service . WordPress maintenance costs 500–2,000 TL per month; the scope is clarified in the initial consultation. Onur Freelance is not an official WordPress support channel and makes no promise of an outcome; it proceeds by explaining each step to the site owner.