Misleading "You do not have sufficient permissions to access this page."

[hakre]

When accessing a page of a plugin in the admin that does not exists any longer, you're told by an error message, that:

You do not have sufficient permissions to access this page.

This message is a little misleading, because there is no such page.

A message that better reflects the decision to display it would be less misleading, e.g.:

The requested page is not accessible.

[hakre]

Simple Patch

[hakre]

FYI: at the end of Plugin.php there are a lot of functions undocumented and in addition to that important global variables for the admin like $parent_file or $plugin_page are not documented as well.

[nacin]

Related, #14039

[envygeeks]

Better description

[dd32]

Both of those proposed wordings are not appropriate IMO.

The major case of that block is to prevent users accessing pages which they do not have access to, The current wording seems appropriate for that (A straight up, Permission denied message).

"The requested page is not accessible." - Doesn't convey the reason for the page being inaccessible.

An alternate solution could be such as follows to give non-existant pages a specific error:

if ( !admin_page_exists() ) {
 do_action...
 wp_die "non-existant page!"
} elseif ( !user_can_access_admin_page() ) {
 do_action...
 wp_die "You dont have access!...";
}

[Ornani]

I'm with dd32.

[hakre]

For my scenario to check whether or not a page exists, would haven been helpful already.

[hakre]

Related: #15394

[ramiy]

Related: #18218

[SergeyBiryukov]

14060.2.patch​ implements dd32's suggestion.

[SergeyBiryukov]

Closed #18662 as a duplicate.

[jane]

"The requested page no longer exists."

[SergeyBiryukov]

Related: #24689

[SergeyBiryukov]

Related: #28643

[Nikschavan]

Refreshed the patch

[Nikschavan]

Refreshed the patch by @SergeyBiryukov

[Presskopp]

Related: #36897

[Nikschavan]

Refreshed the patch with current trunk

[Nikschavan]

Updated the patch with the latest trunk attached a screenshot of the error message.

Can this be targeted for 4.9?

[pento]

Patch needs testing and review.

[jorbin]

As 5.2 is now in beta and this was something that needed early attention, I'm removing it from the milestone.

## 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

[sainathpoojary]

Tested the implementation and verified that the message now correctly shows "The requested page does not exist" instead of the previous permissions error.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7613

Environment

• WordPress: 6.7-beta3-59237-src
• PHP: 8.2.26
• Server: nginx/1.27.3
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.26)
• Browser: Chrome 131.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins: None activated

[thabotswana]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://patch-diff.githubusercontent.com/raw/WordPress/wordpress-develop/pull/7613.diff

Environment

• OS: macOS 15.2
• Web Server: PHP.wasm
• PHP: 7.4.31-dev
• WordPress: 6.8-alpha-20241025.105215
• Browser: Firefox 133.0.3
• Theme: Twenty Twenty-Five
• Active Plugins: None

Actual Results

• ✅ Issue resolved with patch.

Supplemental Artifacts

[nirajgirixd]

I submitted a PR on GitHub for this issue, which has already been approved. Other contributors have also tested and verified the changes.

I would greatly appreciate it if someone could review the ticket and either approve it, provide feedback, or guide me on the next steps.

cc: @nacin, @SergeyBiryukov, @jorbin

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

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

[mindctrl]

This probably needs to be moved to a future milestone. The patch isn't fully ready and needs discussion around the proposed action hook.

[poojapadamad]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://patch-diff.githubusercontent.com/raw/WordPress/wordpress-develop/pull/7613.diff

Environment

• WordPress: 7.0-alpha-20251202.032557
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 144.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

===Actual results
A message that better reflects the decision to display it would be less misleading, e.g.:
The requested page is not accessible.✅

Screenshot is attached for reference:

https://core.trac.wordpress.org/attachment/ticket/14060/New%20Note.jpeg

Trac ticket:

## Use of AI Tools

[audrasjb]

As per today's 7.0 pre-RC1 bug scrub:
Unfortunately, the last patch still needs testing.
It adds a new function, so 3 days before RC1 is not the best time to ship this. Moving to 7.1 with early keyword.

## Description

Accessing the URL of a plugin admin page that is no longer registered previously
showed the misleading "Sorry, you are not allowed to access this page." message,
implying a permissions problem where none exists.

This introduces admin_page_exists(), which determines whether the requested page
is registered independently of the current user's capabilities. When the page does
not exist, wp_die() is now called with a clearer "The requested page does not
exist." message and a 404 status, and a new admin_page_not_found action fires,
mirroring the existing admin_page_access_denied action.
user_can_access_admin_page() reuses the new function so the registration check is
no longer duplicated.

Builds on #7613 and #10955, adding the refactor and unit-test coverage for
admin_page_exists().

## Testing Instructions

• Install and activate a plugin that includes a settings page.
• Navigate to the plugin's settings page and copy the URL.
• Deactivate the plugin.
• Paste the copied URL into the browser's address bar and press Enter.
• You should see "The requested page does not exist." (404) instead of "Sorry, you are not allowed to access this page."

Unit tests:
npm run test:php -- --filter admin_page_exists tests/phpunit/tests/admin/includesPlugin.php

Closing this in favor of #7613

Closing this in favor of #7613

[wildworks]

To prevent discussion fragmentation, I have closed all PRs except for ​PR 7613. Additionally, all PRs introduce a new admin_page_exists() function. However, since the addition of new APIs is generally not permitted after the Beta phase, I'd like to punt this to 7.2.

[audrasjb]

As per today's 7.2 bug scrub:

This one is 16 years old, owned by @SergeyBiryukov
I bugscrubed it during 7.0 and @wildworks during 7.1. We now have one PR waiting for review.
It introduces a new function, so it would be nice to review it by early October.
I'll try to have a look by next week but anyone is welcome to jump in.

(also we have good testing instructions, so I'm adding needs-testing )

[ozgursar]

Before PR12591

[ozgursar]

After PR12591

[ozgursar]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/12591

Environment

• WordPress: 7.2-alpha-63166-src
• Subdirectory: No
• PHP: 8.4.23
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.4.23)
• Browser: Chrome 152.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins:
  • docker-loopback-fix.php
• Plugins:
  • Test Reports 1.3.1

Steps taken

1. Install any plugin that has a settings page (I tested with the Code Snippets plugin)
2. Copy URL of its setting page (in my case http://localhost:8889/wp-admin/admin.php?page=snippets-settings)
3. Deactivate the plugin and visit the copied URL
4. Observe the error message Sorry, you are not allowed to access this page.
5. Apply the patch
6. Revisit the copied URL
7. Observe the error message The requested page does not exist.
8. ✅ Patch is solving the problem

Expected result

• The displayed error message should not be misleading. Hence The requested page does not exist. is the correct message in this case where the URL actually does not exist.

Screenshots/Screencast with results

Before

After

Test Report

Patch/PR tested: #7613

Environment

• OS: Windows 11
• Web Server: <e.g. Apache / Nginx>
• PHP: 8.5
• WordPress: trunk (with PR #7613 applied)
• Browser: Chrome
• Theme: Twenty Twenty-Five

Steps to Test

1. Install and activate a plugin that adds an admin settings page, then copy its page URL.
2. Deactivate the plugin.
3. Paste the saved URL back into the browser.

Expected Results

The message should indicate the page does not exist, rather than a permissions error.

Actual Results

• Without patch: "Sorry, you are not allowed to access this page." (misleading)
• With patch: "The requested page does not exist." ✅
• Verified that legitimate permission errors are unaffected — a registered page the current user genuinely lacks the capability for still returns the "not allowed" message.

Supplemental Artifacts

🤖 _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.

[vgnavada]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7613

Environment

• WordPress: 7.2-alpha-20260921.194908
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 153.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.1

Steps taken

1. Tested the current WordPress Core behaviour without the patch.
2. Accessed an admin page URL that was no longer registered/available.
3. Confirmed that WordPress displayed: "Sorry, you are not allowed to access this page."
4. Repeated the same test using WordPress Playground with PR #7613 applied.
5. Accessed the same type of unavailable admin page URL.
6. Confirmed that WordPress displayed: "The requested page does not exist."
7. ✅ Patch is solving the problem.

Expected result

• When an admin page does not exist, WordPress should display an accurate message indicating that the requested page does not exist, instead of incorrectly suggesting that the user lacks permission to access it.

Additional Notes

• The issue was successfully reproduced before applying the patch.
• After applying PR #7613, the misleading permissions message was replaced with the expected "The requested page does not exist." message.
• No unexpected behaviour was observed during this test.

Screenshots/Screencast with results

• Screenshot before: Shows "Sorry, you are not allowed to access this page." - ​https://prnt.sc/41fE3lGrJjBt
• Screenshot after: Shows "The requested page does not exist." - ​https://prnt.sc/_-mXzuhtgWSq

Support Content

• Trac ticket: https://core.trac.wordpress.org/ticket/14060
• Pull Request: ​https://github.com/WordPress/wordpress-develop/pull/7613
• Testing performed using WordPress Playground.

[huzaifaalmesbah]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7613

Environment

• WordPress: 7.2-alpha-63166-src
• Subdirectory: No
• PHP: 8.3.35
• Server: nginx/1.31.6
• Database: mysqli (Server: 9.7.2 / Client: mysqlnd 8.3.33)
• Browser: Chrome 154.0.8037.58
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins: None activated

Steps taken

1. Log in to the WordPress admin panel (/wp-admin/).
2. Navigate to an admin page URL that is not registered or whose plugin is inactive (e.g. /wp-admin/admin.php?page=non-existent-plugin-page).
3. Observe the error message and HTTP status code returned on the page.
4. ✅ Patch is solving the problem

Expected result

• WordPress displays 'The requested page does not exist.' with HTTP 404 status when an admin page is missing.

Screenshots/Screencast with results

• Before: before.png​
• After: after.png​

[arifulislam1]

tested before PR

[arifulislam1]

tested after PR

[arifulislam1]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7613

Environment

• WordPress: 7.2-alpha-20261002.112716
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 154.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.1

Steps taken

1. Log in to the WordPress admin panel (/wp-admin/).
2. Navigate to an admin page URL that is not registered or whose plugin is inactive (e.g. /wp-admin/admin.php?page=snippets-settings). While testing, the Code Snippets plugin was deactivated so that the page is not currently available.
3. Observe the error message and HTTP status code returned on the page.
4. ✅ Patch is solving the problem

Expected result

WordPress displays 'The requested page does not exist.' with HTTP 404 status when an admin page is missing.

Screenshots/Screencast with results

• Before: before.2.png​
• After: after PR.png​

[chinmoy709]

This message points users to a page that doesn't exist, which could be confusing.

[chinmoy709]

After the PR the message is now showing properly.

[chinmoy709]

Test Report

Patch tested: REPLACE_WITH_PATCH_URL

Environment

• WordPress: 7.2-alpha-20261002.115318
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 142.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Fluent Forms 6.2.15
  • Hello Dolly 1.7.2
  • Test Reports 1.3.1

Steps taken

• Added Fluent Forms plugin
• Visited ?page=fluent_forms_2 which is not an exisiting plugin page
• The Error occurs "This message is a little misleading, because there is no such page."
• After installing the patch the issue is solved

Expected result

• A message that better reflects the decision to display it would be less misleading, e.g.:

"The requested page is not accessible."

Screenshots/Screencast with results

• Before: Misleading Message.png​ ]
• After: after-pr-showing-correct-message.png​ ]

[ahsannayem]

Test Report

Environment

• WordPress: 7.2-alpha-20261002.120743
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 154.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Hello Dolly 1.7.2
  • Test Reports 1.3.1

Steps taken

Added FluentCRM plugin
Visited ?page=fluent_crm_2 which is not an exisiting plugin page
The Error occurs "This message is a little misleading, because there is no such page."
After installing the patch the issue is solved

Expected result

It should show page does not exist.

Screenshots/Screencast with results

Before:

​https://prnt.sc/UkO7_8t-Klgk

After:

​https://prnt.sc/82VUiALtcMRv

[marzanhusain]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/7613

Environment

WordPress: 7.2‑alpha‑20261002.120743

Subdirectory: No

PHP: 8.3.33

Server: PHP.wasm

Database: WP_MySQL_On_SQLite (Server: 8.0.38‑mysql‑on‑sqlite‑3.0.2 / Client: 3.51.0)

Browser: Chrome 154.0.0.0

OS: macOS

Theme: Twenty Twenty‑Five 1.5

MU Plugins: None activated

Plugins:

Hello Dolly 1.7.2

Test Reports 1.3.1

Steps taken

Added FluentCRM plugin.

Navigated to ?page=fluent_crm_2, which is not an existing plugin page.

Observed the error message returned.

Applied the patch from PR #7613.

Repeated the same navigation to confirm behavior.

Expected result

A clearer message that reflects the missing page, e.g.:

“The requested page is not accessible.”

HTTP status code should be 404.

Actual result

Before patch:

“You do not have sufficient permissions to access this page.”

HTTP status code returned: 200 (misleading).

After patch:

“The requested page does not exist.”

HTTP status code returned: 404 (correct).

✅ Patch is solving the problem

Screenshots/Screencast with results

Before:

After:

[syedjakir91]

Test Report

Patch tested:https://github.com/WordPress/wordpress-develop/pull/7613

Environment

• WordPress: 7.2-alpha-20261002.145137
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 153.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.1

Steps taken

1. Log in to the WordPress admin panel (/wp-admin/).
2. Navigate to an admin page URL that is not registered or whose plugin is inactive (e.g. /wp-admin/fluent-crm_3/). While testing, this plugin was deactivated so that the page is not currently available.
3. Observe the error message and HTTP status code returned on the page.
4. ✅ Patch is solving the problem

Expected result

• WordPress displays 'The requested page does not exist.' with HTTP 404 status when an admin page is missing.

Screenshots/Screencast with results

• Before - irrelvant message.png​
• After - After PR.png​

[habiburdev]

Bug Report

Description

When attempting to access a non-existent settings admin page (e.g., wp-admin/options-general.php?page=non-existing-settings-page-slug), WordPress does not handle the invalid slug cleanly, leading to an unexpected screen layout or improper redirection instead of a clean error/redirect handling.

Environment

• WordPress: 7.2-alpha-20261005.233140
• Subdirectory: No
• PHP: 8.3.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38-mysql-on-sqlite-3.0.2 / Client: 3.51.0)
• Browser: Chrome 153.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.1

Steps to Reproduce

1. Log in to the WordPress admin dashboard.
2. Navigate to a non-existent settings page URL under Settings: http://example.com/wp-admin/options-general.php?page=non-existing-settings-page-slug
3. Observe the rendered page behavior.
4. 🐞 Bug occurs.

Expected Results

1. ✅ WordPress should gracefully handle the invalid page query parameter (e.g., displaying a standard "Cannot load [page]" error or redirecting safely back to the main Settings screen).

Actual Results

1. ❌ The invalid page request fails to handle the non-existent slug properly, resulting in unexpected layout rendering or missing navigation state.

Additional Notes

• Re-tested against current trunk (7.2-alpha) in a browser-based PHP.wasm test environment.

Supplemental Artifacts

• Before: before.3.png
• After: after.2.png

@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.

[audrasjb]

Hello, this ticket is marked early so it would be nice to have it committed this week as we are only two weeks from 7.2 beta 1. If it doesn't look realistic, we should move it to Future Release.

[audrasjb]

As per today's 7.2 bug scrub:
No change in the previous week, so I'm inclined to move it to Future Release.

[audrasjb]

Moving to 7.3 which was just created.

[audrasjb]

Moving to 7.3 which was just created.