#2257 closed defect (bug) (worksforme)
Edit Page capability requires Edit Post in order to work
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.1 |
Component: | Administration | Keywords: | bg|reporter-feedback |
Focuses: | Cc: |
Description
I'm trying out the "Roles and Capabilities" plugin by Owen, and I found a little glitch that I'm pretty sure is in the WP core rather than in the plugin:
The capability "Edit Pages" can be turned on, but it doesn't work. Until you also turn on "Edit Posts" the Write and Manage menus do not show up. I tried to go directly to edit-pages.php bypassing the menus, and that indicated a lack of permissions as well.
I know this sounds silly for a "normal" blog, but I'm using WP as a lite CMS here, and there aren't any posts, and I want to save the "normal" users from seeing them and having a chance to mess up with them.
Attachments (2)
Change History (23)
#2
@
19 years ago
- Keywords bg|has-patch added
Ugh, that was a nasty one to fix. I'd really appreciate it if someone who knows what they're talking about could review this patch.
#3
@
19 years ago
- Keywords bg|reporter-feedback added; bg|has-patch removed
In page-new.php you checked the edit-posts cap. This isn't ready. Consider moving to 2.1 milestone.
#5
@
19 years ago
Here's a more flexible patch that automatically determines which submenu page should be the parent page. If for some reason a user cannot manage posts, pages, categories, or comments but can manage files, "Files" will be the parent page for the "Manage" menu.
#7
@
18 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I think a little more investigation/debugging needs to be done with the code additions done to admin-functions.php, specifically after Feb 12th to Feb 17th - it breaks backwards compatibility, perhaps in an avoidable way.
http://trac.wordpress.org/changeset/3536
After upgrading a blog from 2.0.4 to 2.1a2 I discovered that users with level 0 or 1 who I had given access to gravatars2 and an extended profile setup that uses the userextra plugin, could no longer access it - getting the error:
"You do not have sufficient permissions to access this page."
even though they could see it on the menu properly.
This comes from the added $menu_nopriv structure which may be built incorrectly and always returns false for them via
if ( isset($menu_nopriv[$pagenow]) ) return false;
It may also be causing some menu items from plugins not to be shown even at the admin level though I am still tracing that bug - some of my menu items have disappeared even though I can still directly access them via the full ?page= url.
#9
@
18 years ago
By the way I blogged about it in more detail here if that helps explain it better.
I specifically see the following behavior with the new menu.php code:
gravatar2 plugin: users can see the menu entry but when clicking on it are forbidden entry
userextra plugin: same as above
fifo-enroll-comments plugin: users can actually see and go into the menu but admin cannot see the menu sub-item at all
mangage roles plugin: admin cannot see the submenu at all - I can call it manually and it will run however
there might be others, I will go back and look in detail and append here
(note all the behavior is properly restored with the pre-2.1 code)
#10
@
18 years ago
My enroll comments plugin doesn't work because I use
add_submenu_page("profile.php", . . .
to add the options page, and in 2.1 the user page is "users.php" for anyone who can edit users, "profile.php" for everyone else.
#11
@
18 years ago
(my apologies for mispelling your name filosofo)
Deeper investigation has led me to something else.
Apparently I had a plugin active that tampers with admin menus - but not how you think - it actually IMPROVED things.
The "admin drop down menu" plugin apparently has a superior priviledge search as it shows me ALL the available options as long as I have the 2.0.4 menu.php installed and the plugin activated.
view source:
http://frenchfragfactory.net/ozh/download/plugins/wp_ozh_adminmenu.php
They all are available and work via the click.
Strangely if I do not have the plugin activated, all my admin submenu options disappear under "User" - maybe not so strangely - as it was when I use the 2.0.4 menu.php
Under the 2.1a2 menu.php however, I do not get any of the extra options that are available, with or without the admin drop down plugin activated.
Logged in as a level 0 subscriber and the admin dropdown plugin disabled, the 2.1a2 menu.php properly hides the unaccessable items however if you click on the ones that are left you get the
You do not have sufficient permissions to access this page.
Going back to the 2.0.4 menu.php exposes ALL of the menu options without the admin drop down plugin, so that's a no-go there.
I humbly recommend you take a close look at the admin dropdown menu plugin code to see how it scans for privileges and mimic it, as apparently it does something superior?
Thank you.
#12
@
18 years ago
I just realized the above may not be clear as I am running low on sleep. Here it is in a nutshell:
To visualize completely proper menu behavior in 2.1a2, install the menu.php from 2.0.4 and install+activate the "admin dropdown menu" plugin.
All menus will then be properly shown based on accessability (hidden if they are not, exposed if they are) for both users and admin.
The newer menu.php code with $menu_nopriv
- does NOT show admin all their options added by plugins
(it hides some things that should not be hidden)
- will cause users to get a lack of privilege error for items they can see, and should have access to, that are added by plugins
Simple demonstration of the problem:
- If you are running 2.1a2, install the Role Manager plugin and then try to find the menu option under Users -> Roles (I cannot)
There are a few other plugins that also exhibit this behavior.
- roll back to the 2.0.4 menu.php, install the "admin dropdown menus" plugin and you will now be able to find the menu items
#13
@
18 years ago
I'll add some back-compat code to fix plugins that are adding submenus to profile.php. That's the only problem I'm seeing at the moment. gravatars2 requires user level 9 for its options and management pages. That is being enforced correctly in my testing.
Since a number of plugins are adding to the user/profile menu, add_user_page() might be in order.
#15
@
18 years ago
I've now tested your new 4093 menu.php and admin-functions.php
(Oh I meant the "new" Gravatars2
which has adjustable userlevel settings so users can set their own avatars.)
I am pleased to report you fixed the admin menu for the administrator - I can see the once hidden extra options.
However the problem with subscriber level 0 users, which I allow access to userextra and gravatars2 (via their adjustable userlevel settings), still exists.
They can SEE the proper menu entries but they cannot access -
You do not have sufficient permissions to access this page.
(This is with admin dropdown menu plugin either turned OFF or ON)
Shouldn't the logic be if they are shown the menu item they should be able to access it? Remember, the behavior works correctly in 2.0.4
I know it has something to do with your new $menu_nopriv failing that If statement check in admin-functions.php function user_can_access_admin_page
Thanks so much for the quick attention to this, you're great Ryan.
#18
@
18 years ago
rev 4100 seems to fix both the admin menu for administrator (showing all sub-functions) and also allows proper access for subscribers. Good job!
Not sure what was with the change from 4097 to 4100 and that block commented out but it works now, so if the original bug for this ticket is still solved, I guess it's done? I'll leave it up to you to close the ticket.
Nice work Ryan and thanks again!
I was able to recreate. I am creating a patch right now.