add_menu_page doesn't respect "access level".

[denney]

I'm having the problem of my plugin toplevel menu being displayed regardless of the users access level.

I have the access level set to 10 in the "add_menu_page()" call but logging in as a standard subscriber still displays the menu and clicking on it shows the content of the menu item.

Any submenu's of the new toplevel menu aren't being displayed which is correct but to me, not even the menu should be displayed.

My function call is as follows:

"add_menu_page('Kavelier', 'Kavelier', 10, FILE, 'kav_plugin_options');"

This is using revision 3751.

[denney]

Patch to fix the problem.

[denney]

I don't think the patch I've submitted weakens security but it fixes the problem so it's a possible solution?

[westi]

Are you using the admin_menu hook to call add_menu_page?

I'm not sure you should - you should do it when you plugin is first included or on the init hook instead.

[denney]

1. The patch I posted doesn't work with other plugins that use add_submenu_page(). It keeps trying to redeclare the function. Not good. So don't use my patch.

2. I am using the "admin_menu()" hook to call "add_menu_page()" because that's what the Codex says to do. I tried just calling it when it's first included AND running it through init but I get an error about "add_menu_page() function doesn't exist".

[westi]

Ok sorry you are correct the right place to build admin menus is on the admin_menu hook.

However I can't reproduce your bug.

I am uploading my menu testing plugin and the menus I have set to have level_10 capability or a userlevel of 10 are only viewable by the admin user.

What version of WP are you testing - I have tested with 2.0.2 and trunk

[westi]

Simple menu testing plugin

[denney]

Menu test that does reproduce the results.

[denney]

Unless I'm using sloppy code, I cannot figure out why my test (I don't use classes) reproduces the problem.

It seems that if you use a class, it works, if not, it doesn't. I don't understand that.

I'm using trunk. I have uploaded a snippet of my code that does reproduce the problem.

[westi]

Ok, I can reproduce your issue now.

It's nothing to do with the classes/no-classes differences but it is todo with the fact that you have a submenu for your new top level menu in your test and I don't.

I see if i can knock up a patch for this.

[ryan]

(In [3756]) Check menu privs after plugins add their menus. fixes #2696

[ryan]

Try that patch out. Worked for me using your menu tester. Reopen if there are still problems.

[ryanscheuermann]

This also fixes #2610. But I'm now having a problem where plugin pages aren't showing up.

I use add_submenu_page to add a plugin page under "edit.php". Like so:

add_submenu_page('edit.php', 'Do Stuff', 'Do Stuff', 'do_stuff_page', 'do_stuff', 'my_do_stuff_function');

But when I take away the "edit_posts" privelege (and thus removing "edit.php" as the parent), my plugin page links are changing from "wp-admin/edit.php?page=do_stuff_page" to "wp-admin/do_stuff_page" on the admin menu. And of course, I get a big 404 when clicking on them.

[ryanscheuermann]

test plugin for replicating submenu permissions bug

[ryanscheuermann]

The attached plugin demonstrates what happens when you add a plugin page (based on a "named" page w/ function call) to the Manage submenu and then remove the 'edit_posts' permission from administrator.

The plugin also contains the hacks I found to make it work. Maybe this is the intended way to implement something like this, I don't know, but I couldn't find documentation anywhere.

[ryan]

[4093] should help.