wp-admin Redirects to profile.php After 7.1.4? Find the Cause

Since the WordPress 7.1.4 auto-update on October 28, some site owners report that every wp-admin screen (Posts, Pages, Plugins, Settings, even the editor) bounces them to /wp-admin/profile.php. The profile page itself loads fine and the front end works.

One report on the WordPress.org forums shows it on two sites at the same host, starting at the same time. As of 2026-11-02 that thread has no confirmed cause, so this post is about finding the culprit on your own site instead of guessing.

Before you roll back core: the 7.1.4 announcement lists security fixes only, and none of them is described as a change to roles, capabilities or admin redirects. I would not downgrade a security release over this.

---

Why core is probably not the one redirecting you

Open the browser dev tools, go to the Network tab and reload an admin page. You will see a 302 response with Location: .../wp-admin/profile.php and the header X-Redirect-By: WordPress.

That header only tells you wp_redirect() ran. Every plugin, theme and drop-in calls the same function, so it does not point at core.

Inside wp-admin, core does not send you to profile.php when you lack a capability. It stops the page with “Sorry, you are not allowed to access this page.” and a 403. The only core redirect to profile.php lives in wp-login.php: right after login, a user who can read but not edit_posts lands on the profile screen.

The “everything except profile.php” pattern matches a very common snippet that keeps subscribers out of the dashboard: on admin_init, if the user can’t edit_posts, redirect to profile.php. If your administrator account suddenly looks like it has no edit_posts, that snippet treats you like a subscriber.

A stale object cache or a damaged roles option can do exactly that. It’s my working theory, not a confirmed cause, so the steps below test it instead of assuming it.

---

Step 1. Back up the database and wp-content

You can’t trust the dashboard right now, so do everything from SSH with WP-CLI, starting in the WordPress root folder.

wp db export before-redirect-fix.sql

WP-CLI should end with a Success line naming the file. Since some of the steps below rename files, also grab a copy of wp-content over SFTP or with your host’s backup tool.

Step 2. Check what WordPress thinks your account can do

wp user get admin --field=roles
wp user list-caps admin | grep -E '^(read|edit_posts|manage_options)$'

Replace admin with your login, email or user ID. A healthy administrator prints administrator and then all three capabilities.

If the role is right but edit_posts or manage_options is missing, the administrator role itself was damaged. Put the default capabilities back:

wp role reset administrator

WP-CLI reports how many capabilities it restored. “No changes necessary” means the role was fine and the problem is somewhere else, so keep going.

💡 wp role reset only works on the default roles. Custom roles from membership or shop plugins are left alone.

Step 3. Take the object cache out of the picture

Both sites in the forum report use Redis through an object-cache.php drop-in, which is why the helpers there suspected it first. A cache that serves an old or partial copy of your roles makes WordPress believe you are someone else.

wp cache flush
mv wp-content/object-cache.php wp-content/object-cache.php.off

Reload wp-admin. If the redirect is gone, the cache was the problem. Rename the file back, flush again, and if it returns, check the Redis plugin settings or ask your host what changed on their side. My post on the Redis connection crash covers the connection side.

Step 4. Search mu-plugins and the theme for the redirect

Must-use plugins load on every request and never show up on the Plugins screen, so deactivating “all plugins” does not touch them. Managed hosts often drop their own files in there.

ls -la wp-content/mu-plugins/
grep -rln "profile.php" wp-content/mu-plugins wp-content/themes wp-content/plugins --include=*.php

The grep prints every PHP file that mentions profile.php. Most hits are harmless links to the profile screen. Open each one and look for wp_redirect() or wp_safe_redirect() next to a current_user_can() check.

To rule out the theme, rename its folder (for example wp-content/themes/betheme to betheme-off). WordPress falls back to a default theme if one is installed. Rename it back when you are done.

Step 5. Log the exact file that sends the redirect

If nothing above found it, make the redirect tell you who called it. Create wp-content/mu-plugins/debug-redirect.php with this:

<?php
/**
 * Temporary: log who redirects to profile.php. Delete when done.
 */
add_filter( 'wp_redirect', function ( $location ) {
    if ( false !== strpos( (string) $location, 'profile.php' ) ) {
        $trace = array();
        foreach ( debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS ) as $frame ) {
            if ( isset( $frame['file'] ) ) {
                $trace[] = $frame['file'] . ':' . $frame['line'];
            }
        }
        error_log( "Redirect to profile.php from:\n" . implode( "\n", $trace ) );
    }
    return $location;
}, 1 );

Then turn on logging in wp-config.php, above the “That’s all, stop editing!” line:

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

Load any admin screen once, then read the end of the log:

tail -n 30 wp-content/debug.log

You should see a “Redirect to profile.php from:” block with a list of file paths. Skip the ones in wp-includes and wp-admin. The first path inside wp-content (a plugin, theme, mu-plugin or drop-in) is the code that redirected you.

No log file at all? Then logging itself is broken, and my debug.log not created post walks through the usual reasons.

💡 Delete debug-redirect.php and set WP_DEBUG back to false when you are done. The trace exposes file paths in the log.

---

Stop the next update from locking you out

Once you know the file, fix it at the source. Update the plugin or theme, report the trace to its developer, or ask your host if the file lives in their mu-plugins.

If the culprit is a dashboard redirect you wrote yourself, give it an exit for AJAX requests and for the profile screen, so it can never loop or break admin-ajax.php:

add_action( 'admin_init', function () {
    global $pagenow;

    if ( wp_doing_ajax() || 'profile.php' === $pagenow || current_user_can( 'edit_posts' ) ) {
        return;
    }

    wp_safe_redirect( admin_url( 'profile.php' ) );
    exit;
} );

The bigger lesson is access. WP-CLI keeps working when the dashboard does not, so make sure you can SSH into every site before auto-updates run, and keep a recent database export around. If the problem you are fighting is the login screen itself looping, that’s a different cause, covered in fixing the admin login refresh and redirect loop.

TL;DR: core does not redirect admin screens to profile.php, so look for a plugin, theme, mu-plugin or object cache that makes your admin look like a subscriber. Check your capabilities with wp user list-caps, reset the role with wp role reset administrator, disable object-cache.php, and if it still happens, log a backtrace from the wp_redirect filter to get the exact file.