[wp-trac] [WordPress Trac] #20111: Ability to set permission level for admin settings pages using filters

[WordPress Trac]

#20111: Ability to set permission level for admin settings pages using filters
-----------------------------+----------------------
 Reporter:  bananastalktome  |       Owner:
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |
-----------------------------+----------------------

Comment (by bananastalktome):

 Replying to [comment:6 scribu]:
 > Except what is a "distinct admin page"? For example, it's not obvious if
 {{{edit.php?post_type=post}}} should have a different filter than
 {{{edit.php?post_type=page}}}.

 IMHO, a distinct admin page is any page which corresponds to a nav menu
 item (as well as any interaction which occurs within those pages, such as
 clicking 'Save', 'Publish', etc/, and any sub-pages which may or may not
 be in the nav menu themselves). So in that case, {{{edit.php}}}(query
 parameter `post_type=post` is default) and {{{edit.php?post_type=page}}}
 ''would'' be two distinct pages since each has a direct point of entry
 from the nav menu.

 > That's why we have $current_screen (which also has a post_type property,
 btw), so that you can choose your own level of granularity.
 >
 > Having remove_(sub)menu_page() also block access is an interesting idea,
 but it suffers from the same problem: do you block the whole of edit.php
 or just parts of it? There's no 1-to-1 mapping between menu items and
 admin screens.

 By using {{{remove_menu_page(remove_menu_page('edit.php');}}} it already
 only removes the 'Posts' page and ''not'' the 'Pages' page.

 I think what it comes down to is that when I decide to remove a page, why
 is it still accessible? I can't think of a compelling reason why someone
 would remove a page but still want users to be able to access it. Part of
 what causes confusion for me (as well as from anecdotal accounts of others
 on websites I have come across when trying to find a 'best way' to remove
 admin pages, some of which terrifyingly proposes simply using css to hide
 the menu items with `display: none`), is that when I remove a menu page,
 it does not really 'remove' the page so much as hide it, which as far as
 security goes is little better than the css approach. Semantics, maybe,
 but IMHO given the current behavior, the function should be
 `remove_menu_item('blah');` as it really doesn't remove the page itself.

 Also, can you please clarify what you mean by "the 1-to-1 mapping between
 menu items and admin screens"? I thought there already was a 1-to-1
 mapping between each menu item and screens.

 I realize this may have gone beyond the scope of this original ticket, and
 I would be happy to move this conversation elsewhere if deemed more
 appropriate.

 Replying to [comment:7 nacin]:
 > One more thing to think about: options.php is not protected in these
 situations. You'll want to guard it there, too.

 Thanks for the tip!

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20111#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software