Fix: Misleading Message When Accessing Admin Menu Page

[nirajgiriXD]

Description

This PR addresses the issue where the misleading message You do not have sufficient permissions to access this page. was displayed when attempting to access an admin page that doesn't exist. Instead of suggesting a permissions problem, the fix ensures that users are now shown a clearer message: The requested page does not exist. This provides a more accurate and user-friendly explanation when the page is missing or unavailable.

Screenshot

Testing Instructions

• Install a plugin that includes a settings page.
• Navigate to the plugin's settings page and copy the URL.
• Go to the plugins page and deactivate the plugin you just installed.
• Paste the copied URL of the plugin's settings page into the browser's address bar and press Enter.
• You should now see the message The requested page does not exist. instead of You do not have sufficient permissions to access this page.

Trac ticket: https://core.trac.wordpress.org/ticket/14060

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @nirajgiri9860@googlemail.com.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

Core Committers: Use this line as a base for the props when committing in SVN:

Props nirajgirixd, wildworks, westonruter, peterwilsoncc, apermo, mindctrl, noruzzaman, shailu25, huzaifaalmesbah, muryam.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[apermo]

Looks good to me

[mindctrl]

@nirajgiriXD I left some feedback for consideration. Also, could you bring this up to date with the latest trunk branch?

[nirajgiriXD]

@mindctrl Thanks for the feedback! I've implemented the suggested changes and updated the branch with the latest from trunk.

[mindctrl]

Needs unit tests. Needs discussion about introducing a new action, if it's desired, and what its name should be.

[westonruter]

🤖 Comment by Claude Opus 5

This is a review of the branch diff. The structural claims below were each verified against the current branch. Findings are ordered by severity.

The no-privilege registries are emptied after _admin_menu fires

src/wp-admin/includes/menu.php fires _admin_menu on line 41, then resets both registries on lines 84–85:

$_wp_submenu_nopriv = array();
$_wp_menu_nopriv    = array();

An add_submenu_page() call made before that point — on _admin_menu, or earlier still on init or plugins_loaded — takes the early return at src/wp-admin/includes/plugin.php:1505, which records $_wp_submenu_nopriv[ $parent_slug ][ $menu_slug ] and deliberately touches neither $submenu nor $_registered_pages. That record is then erased before wp_admin_page_exists() ever consults it.

The consequence is that a low-privilege user requesting such a page is now told "The requested page does not exist.", when previously a permission error was shown. This is the same class of misleading message the PR sets out to fix, inverted. Registrations on admin_menu (line 168) are unaffected, since that hook fires after the reset, so the exposure is limited to the early window — but that window is where a number of plugins do register.

admin_page_access_denied no longer fires for unregistered slugs

With the new elseif at src/wp-admin/includes/menu.php:375, a request for a page that does not exist reaches wp_die() on the wp_admin_page_exists() branch and never reaches do_action( 'admin_page_access_denied' ) on line 392.

That hook is used by plugins to intercept stale or mistyped ?page= requests and redirect them — to a dashboard, an onboarding screen, or a renamed page. Those redirects will silently stop working for exactly the requests they were most often installed to catch. Whether or not the new behavior is preferred, it is a back-compat break that warrants a mention in the commit message and a dev note.

$admin_page_parent becomes a per-request memo on a public function

At src/wp-admin/includes/plugin.php:2237:

$parent = $admin_page_parent ?? get_admin_page_parent();

user_can_access_admin_page() is a public function that plugins call directly, and menu.php now populates $admin_page_parent early by way of wp_admin_page_exists(). Every later call therefore reuses the parent computed for the original request. A plugin that temporarily assigns $GLOBALS['plugin_page'] and then asks about access — or that re-parents menus through remove_menu_page() — receives an answer derived from the wrong parent, and so a wrong $hookname and a wrong boolean.

The global name is also generic enough that collision with a plugin's own global is plausible, and ?? would then silently honor the poisoned value rather than recomputing. Passing the parent as an optional argument, or keying the memo on $plugin_page/$pagenow, would avoid both problems.

The existence check ahead of the capability check creates an enumeration oracle

Because wp_admin_page_exists() is consulted first, any authenticated user who can reach admin.php can now distinguish "does not exist" from "not allowed" for an arbitrary ?page= slug. That reveals which plugins are installed and which admin page slugs they register. Previously both cases produced an identical permission error.

This is inherent to the feature rather than a defect in the implementation, and the disclosure is modest. It is raised only so that it is an explicit decision on the ticket rather than an incidental one.

Test observations

tests/phpunit/tests/admin/includesPlugin.php:111 uses global $plugin_page; unset( $plugin_page );, which unsets only the local reference — $GLOBALS['plugin_page'] survives, and wp_admin_page_exists() re-imports it through its own global statement. The assertion passes only because reset_menu_globals() already unset the global correctly during set-up, so the test does not exercise the condition it is named for. unset( $GLOBALS['plugin_page'] ); would.

test_wp_admin_page_exists_returns_true_for_a_registered_page() builds $_registered_pages on line 125 from the same get_plugin_page_hookname( $plugin_page, $admin_page_parent ) call that the function under test performs, so it asserts that an expression equals itself and would still pass if hookname derivation were wrong. Registering through the public API as an administrator — as the fourth test already does — would give it teeth.

Noted and discounted

The scan at src/wp-admin/includes/plugin.php:2175 iterates every parent in $_wp_submenu_nopriv rather than scoping to the resolved parent, so tools.php?page=foo reports as existing when foo is a no-privilege submenu of options-general.php. That errs toward a permission error instead of a 404, which is the safer direction here, and appears deliberate.

[t-hamano]

Based on this feedback, I have proposed specific changes.

admin_page_access_denied no longer fires for unregistered slugs

I think this is worth discussing how to address. Since we now have the new admin_page_not_found action, we could probably cover this change with a dev note. Something like:

In WordPress 7.2, requests for admin pages that don't exist now show "The requested page does not exist." (404) instead of a permission error (403). As a result, admin_page_access_denied no longer fires for such requests; it only fires when the page exists but the user lacks permission. Plugins that use admin_page_access_denied to redirect old or mistyped ?page= URLs should also hook their callback to the new admin_page_not_found action. Hooking to both is safe on older WordPress versions, since admin_page_not_found simply won't fire there.

[westonruter]

@nirajgiriXD You can skip merging from trunk unless there are merge conflicts. Otherwise, this most likely this just waste CPU time running the jobs and it creates noise.

[Copilot]

Copilot review overview

🟡 Changes recommended

Parent-agnostic slug checks can misclassify nonexistent submenu URLs as permission-denied pages.

Review effort: Balanced
Findings: 1

Open (1)

• Scope no-privilege submenu fallback checks to the requested parent · New

Resolved since last review (2)

• This class already defines tear_down() at line 20, so this second declaration makes the test file…
• This treats capability-protected submenu pages as nonexistent. When add_submenu_page() is called…

[peterwilsoncc]

I've added some notes inline.

🔢 if the test suite indicates that the note applies to multiple tests.

[t-hamano]

Looks good from my end. The only notable point is the following, though I personally think this can be addressed in the dev notes.

admin_page_access_denied no longer fires for unregistered slugs

I think this is worth discussing how to address. Since we now have the new admin_page_not_found action, we could probably cover this change with a dev note. Something like:

In WordPress 7.2, requests for admin pages that don't exist now show "The requested page does not exist." (404) instead of a permission error (403). As a result, admin_page_access_denied no longer fires for such requests; it only fires when the page exists but the user lacks permission. Plugins that use admin_page_access_denied to redirect old or mistyped ?page= URLs should also hook their callback to the new admin_page_not_found action. Hooking to both is safe on older WordPress versions, since admin_page_not_found simply won't fire there.

[westonruter]

Some minor typing improvement suggestions.

[westonruter]

Minor: This here is still just array but for wp_admin_page_exists() it is richly typed as array<string, true>. It would be nice to include the richer typing here as well.

[t-hamano]

Fixed in 369fb0d

[westonruter]

Technically this could be null, right? The first statement in the function is to check if it is set.

Suggested change

	* @global string $plugin_page The plugin page slug being loaded.
	* @global string|null $plugin_page The plugin page slug being loaded.

[t-hamano]

Fixed in 369fb0d

[westonruter]

These can be more richly typed to match the above as well.

[t-hamano]

Fixed in 369fb0d

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 64351
GitHub commit: 6dc9323

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.