If you have another admin account, log in with it. Go to Users → All Users, find the affected account, and check its Role column. If it shows anything other than “Administrator,” click Edit, change the role to Administrator, and save.

You should see: The role updated to “Administrator” and a green success notice at the top of the Users screen.

Go to Plugins → Installed Plugins, select all plugins, and use the Bulk Actions dropdown to deactivate them all. Try accessing the restricted page again. If it loads, reactivate plugins one by one until the error comes back — that plugin is your culprit.

You should see: The previously blocked page now loads correctly once all plugins are off.

Log into your hosting control panel and open phpMyAdmin. Select your WordPress database, then browse the wp_usermeta table. Find the row for your user ID where meta_key equals wp_capabilities. The meta_value field should contain exactly this:

a:1:{s:13:"administrator";b:1;}

If it’s empty, missing, or shows a different role, click Edit, paste in the correct value above, and save.

You should see: A success message in phpMyAdmin. Reloading wp-admin should now grant you full access.

If you have SSH access to your server, run this command — replacing username with the actual WordPress login name:

wp user set-role username administrator

You should see: Output that reads “Success: Added role.” The user now has full admin access immediately.

As a last resort, open phpMyAdmin and insert a new row into wp_users with a username, email, and MD5-hashed password. Then in wp_usermeta, add a row setting wp_capabilities to a:1:{s:13:"administrator";b:1;} and another row setting wp_user_level to 10 for that new user ID. Log in with the new account.

You should see: A fully working admin dashboard. You can then repair or delete the broken account from inside WordPress.

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

You should see: Your site loads without a redirect loop. If it still loops, move to the next step — don’t skip it.

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

You should see: WordPress now correctly detects HTTPS even when your host terminates SSL at the edge, stopping the redundant redirect chain.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

You should see: No duplicate RewriteRule entries redirecting HTTP to HTTPS. One enforcement point only — either server or .htaccess, never both.

wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

You should see: Both fields display https:// after saving, and no redirect warning appears on the Settings page.

You should see: The site loads cleanly at https:// with a valid padlock icon and no redirect error in any browser.

You should see: A file path starting with /wp-content/ and a specific line number in the error output.

You should see: The directory containing the broken file, accessible through your FTP client or File Manager.

You should see: The file saved locally on your machine before any changes are made.

# Common issues to look for near the reported line:
# - Missing semicolon at the end of a statement
# - Unclosed string (missing closing " or ')
# - Extra or missing curly bracket { }
# - Curly/smart quotes instead of plain straight quotes

You should see: The problematic character near or just above the reported line — visually out of place compared to surrounding code.

You should see: No syntax errors flagged by your editor on or around the corrected line.

You should see: Your WordPress site loading normally in the browser after a page refresh.

# Rename via FTP to disable a broken plugin:
/wp-content/plugins/broken-plugin  →  /wp-content/plugins/broken-plugin-DISABLED

# Rename via FTP to disable a broken theme:
/wp-content/themes/broken-theme  →  /wp-content/themes/broken-theme-DISABLED

You should see: Your WordPress site coming back online, running without the disabled plugin or theme.

You should see: The uploaded file listed in the current month’s uploads folder.

define('WP_ALLOW_REPAIR', true);

Then visit https://yoursite.com/wp-admin/maint/repair.php and click Repair and Optimize Database. Once it finishes, remove that line from wp-config.php immediately.

You should see: Each database table listed with a status of Repaired or OK — no table should show Error.

SHOW GRANTS FOR 'your_db_user'@'localhost';

The output must include INSERT, UPDATE, and DELETE on your WordPress database. If not, update the user’s permissions through your host’s control panel.

You should see: GRANT ALL PRIVILEGES ON `your_database`.* TO 'your_db_user'@'localhost' in the results.

You should see: The upload succeeds with plugins off, and fails again only after re-enabling one specific plugin.

define('WP_MEMORY_LIMIT', '256M');

Alternatively, add this to your .htaccess file in the root of your site:

php_value memory_limit 256M

You should see: The upload completes without error and the attachment appears in your Media Library.

You should see: The renamed file uploads successfully and shows up in your Media Library.

You should see: Something like Call to undefined function get_plugin_data() in a specific file on a specific line.

You should see: The file where the function is declared — this tells you which plugin or theme owns it.

You should see: Your site loads normally again and the error is gone.

if ( function_exists( 'your_function_name' ) ) {
    your_function_name();
}

You should see: No fatal error — the block is skipped gracefully when the function is unavailable.

add_action( 'init', function() {
    your_function_name();
});

You should see: The function executes without error after WordPress has fully initialized.

You should see: A PHP version of 8.0 or higher listed, and the error resolved after the upgrade.

You should see: A path like /wp-content/plugins/plugin-name/some-file.php clearly identifying the broken component.

You should see: Either the file is missing entirely or it exists but may have a permission issue.

wp plugin deactivate plugin-name
wp plugin delete plugin-name
wp plugin install plugin-name --activate

You should see: The plugin reinstalled and active with no PHP errors on the page.

You should see: Your theme loading correctly with no stream errors.

wp core download --force

You should see: Core files refreshed with your plugins, themes, and content completely untouched.

// Replace this:
require_once '/home/user/public_html/wp-content/plugins/my-plugin/file.php';
// With this:
require_once plugin_dir_path( __FILE__ ) . 'file.php';

You should see: No more path errors, even if the site moves to a different server or directory in the future.

Open wp-config.php in your WordPress root directory and add this line just before the comment that reads /* That's all, stop editing! */:

define('WP_MEMORY_LIMIT', '256M');

You should see: The error disappears and your site loads normally. If it persists, your server-level limit is overriding this setting — continue to Step 2.

Create or edit a file named php.ini in your WordPress root directory and add the following line:

memory_limit = 256M

You should see: The site loads without errors. On some shared hosts, php.ini changes are silently ignored — try Step 3 if this doesn’t help.

For Apache-based servers, open .htaccess in your WordPress root and insert this line near the top:

php_value memory_limit 256M

You should see: The page loads cleanly. If you get a 500 Internal Server Error after saving, remove that line — your host doesn’t permit PHP directives in .htaccess.

If the error keeps returning after raising the limit, the root cause needs identifying. Deactivate all plugins from the WordPress admin panel, then reactivate them one by one, checking memory usage each time using the Query Monitor plugin.

You should see: A noticeable memory spike in Query Monitor when you reactivate the offending plugin — that’s your target to replace, configure, or contact the developer about.

If none of the file edits above take effect, your host has locked the memory limit at the server level and your changes are being overridden. Submit a support ticket asking them to raise PHP memory to at least 256MB — this is a routine request any reputable host will handle.

You should see: A support confirmation that the limit has been updated, after which your site should run cleanly without the error returning.

You should see: Either the site loads normally (browser cache was the culprit) or the same error in a clean window, confirming it is a server-side issue worth digging into.

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

Replace the URL with your actual domain, using the correct HTTP or HTTPS prefix.

You should see: The site loads without a redirect error, or you can reach the WordPress admin panel again.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

You should see: The site or admin panel loads after saving the new file, indicating the old .htaccess had conflicting redirect rules.

You should see: The site loads, confirming a plugin is responsible. Rename the folder back to plugins, then reactivate plugins one at a time — testing after each — until the loop returns, identifying the problem plugin.

$_SERVER['HTTPS'] = 'on';

You should see: The redirect loop stops because WordPress no longer attempts its own HTTPS redirect on top of the one already happening at the proxy level.

You should see: The site loads correctly after updating both rows and hard-refreshing the browser.

You should see: A fresh login page with no pre-filled fields. Attempt to log in before moving on.

You should see: If login succeeds here, your browser’s stored cookies were the culprit. If the loop continues, move to Step 3.

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

Replace the URL with your actual address. Use the exact format your site runs on — include “www” if your site uses it, and “https” if SSL is active. These values override whatever is stored in the database.

You should see: The login page loads and you are redirected to wp-admin after submitting credentials. If this works, you have found the fix.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

You should see: Successful login to wp-admin. Afterward, navigate to Settings → Permalinks and click Save Changes to let WordPress regenerate the correct .htaccess rules for your permalink structure.

You should see: Login succeeds. Rename the folder back to plugins, then go to the Plugins screen and reactivate them one at a time — testing login after each activation — until the loop returns. That last plugin is your culprit.

You should see: Your site loads normally. If it does, the old .htaccess file was corrupted. You can safely delete .htaccess_old.

You should see: The site loads (likely with a stripped-down look). That confirms a plugin is the culprit. Rename the folder back to plugins, then reactivate plugins one at a time — testing after each — until the 500 returns and reveals the bad actor.

You should see: If the site loads cleanly, your theme’s code is the problem. Restore the folder name, then inspect the theme’s functions.php for recent edits or contact the theme developer.

define('WP_MEMORY_LIMIT', '256M');

You should see: The site loads if memory exhaustion was the root cause. If your host caps memory below 256M, you’ll need to contact them to raise the server-level limit.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then check /wp-content/debug.log for the actual PHP error. Your host’s error_log file in the root directory is another place to look.

You should see: A specific error message naming the exact file and line number that caused the crash — this eliminates all guesswork and points you straight to the fix.