Make WordPress Core

Opened 19 years ago

Closed 18 years ago

Last modified 17 years ago

#2257 closed defect (bug) (worksforme)

Edit Page capability requires Edit Post in order to work

Reported by: whimsy's profile whimsy Owned by: markjaquith's profile markjaquith
Milestone: Priority: normal
Severity: normal Version: 2.1
Component: Administration Keywords: bg|reporter-feedback
Focuses: Cc:


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)

edit_pages_fix.diff (4.5 KB) - added by markjaquith 19 years ago.
Fix for edit_pages cap
auto_parent.diff (5.2 KB) - added by ryan 18 years ago.
Automattically determine proper menu parent

Download all attachments as: .zip

Change History (23)

#1 @markjaquith
19 years ago

  • Owner changed from anonymous to markjaquith
  • Status changed from new to assigned

I was able to recreate. I am creating a patch right now.

#2 @markjaquith
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.

19 years ago

Fix for edit_pages cap

#3 @skeltoac
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.

#4 @matt
19 years ago

  • Milestone changed from 2.0.1 to 2.1

18 years ago

Automattically determine proper menu parent

#5 @ryan
18 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.

#6 @ryan
18 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [3536]) Dynamic menu reparenting. fixes #2257

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

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.

#8 @ryan
18 years ago

  • Version changed from 2.0 to 2.1

Which plugins exactly?

#9 @_ck_
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 @filosofo
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 @_ck_
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:
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 @_ck_
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

  1. does NOT show admin all their options added by plugins

(it hides some things that should not be hidden)

  1. 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:

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

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

#14 @ryan
18 years ago

[4093] should help.

#15 @_ck_
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.

#16 @ryan
18 years ago

[4097] Try that.

#18 @_ck_
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!

#19 @foolswisdom
18 years ago

_ck_ , whimsy , markjaquith are there any outstanding issues here or can the bug be closed?

#20 @masquerade
18 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

#21 @Nazgul
17 years ago

  • Milestone 2.1 deleted
Note: See TracTickets for help on using tickets.