Add hooks to enable access to pages in the admin when the menu layout has been changed by plugin

[mikeschinkel]

This patch and ticket is a follow on to tickets #16048 and #16050 and indirectly related to this discussion on hackers: ​http://lists.automattic.com/pipermail/wp-hackers/2011-January/037129.html

This patch simply adds the following hooks, all within /wp-admin/includes/plugin.php.

• menu_page_url
• admin_page_parent
• admin_page_title
• plugin_page_hookname
• user_can_access_admin_page

The patch does not attempt to unravel the many early exits of the various functions instead it simply redundantly adds the hooks at each exit point. As such it's backward compatibility can be reviewed simply by viewing the code.

The use-case for this patch is when the menus are not exactly in the format expected by WordPress (but instead desired by the client) it can sometimes take hours of trial and error to get the permissions to allow users access to the menus they should be allowed access to.

For example, if the first submenu page for a menu page is removed from the menu, even when it makes logical sense to the user WordPress currently does not allow that menu option to be viewed. These hooks would give plugin developers the ability to modify the menus and still enable users access to the pages they need access to.

[mikeschinkel]

Add hooks menu_page_url, admin_page_parent, admin_page_title, plugin_page_hookname and user_can_access_admin_page to /wp-admin/includes/plugin.php.

[westi]

Before adding loads of extra hooks like this we should fully understand the use-case and how this isn't supported fully by the new menu removal apis

[mikeschinkel]

I've described the various issues I'm having with admin menus hgere:

• ​http://andrewnacin.com/2010/12/20/better-admin-menu-controls-custom-post-types-wordpress-3-1/#comments

To further elaborate the security on admin menus is somehow coupled directly to the values in either the $menu or $submenu arrays which is problematic when the client does not want a submenu page to duplicate the menu page. Honestly I battled with it for over 8 hours and at the end I still wasn't sure exactly what it was doing which is why I can't give you a more specific answer:

I just know that the admin menu is extremely difficult to get to work the way the clients want it and all I'm asking for are hooks so that I can make it work.

I thought hooks were the things we were supposed to ask for when we needed something, so we could make it "plugin territory?"

[mikeschinkel]

@westi - Maybe the way you can understand the requirement is to build the above menu yourself and see how close to impossible it is? Be sure to implement a special submenu option that needs to be highlight when loading a customized edit.php page and also whenb loading apost.php page, and make it so that security doesn't keep you from loading those pages. Make it happen without needing to use output buffering and without hacking core and I'll withdraw the request for these hooks and the ones on tickets #16048 and #16050.

[mikeschinkel]

I just reread what I wrote and realized I should make something clear; they above was not meant to be snarky but instead simply matter-of-fact.

[mikeschinkel]

A point to be considered; if only one hook here added it could handle most needs, and that would be a hook for: 'user_can_access_admin_page'.

[chriscct7]

Couldn't the work of the filters be done automatically using user_can_access_admin_page()? Is there a benefit to the filters being there?

[DrewAPicture]

@mikeschinkel: Any followup to add here?

[wonderboymusic]

Marked close 12 months ago

[MikeSchinkel]

Replying to DrewAPicture:

@mikeschinkel: Any followup to add here?

I never saw this before. Is it agreed to be "won't fix", or can I follow up?

[samuelsidler]

Replying to MikeSchinkel:

I never saw this before. Is it agreed to be "won't fix", or can I follow up?

If you have follow up, it can continue in this ticket, even if it's closed. (And it can be reopened later, of course.)