Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3706 closed defect (bug) (fixed)

Admin Menu Hooks confusing

Reported by: mattyrob Owned by:
Milestone: 2.1.3 Priority: low
Severity: minor Version: 2.1
Component: Administration Keywords: needs-patch
Focuses: Cc:


With the release of 2.1 the menu structure change so that admin level users got a User menu and subscriber level users go a Profile menu.

If you use add_submenu_page and specify hooking into users.php this works and is only visible to admins.

If you change this to hooking in to profile.php the menu is visible to subscribers under Profile AND admins under Users.

I don't think it should be visible to admins as profile is not a main menu for admins so how can you specify a submenu?

This issue is affecting my plugin quite drastically as I dynamically link to this page from within the content of the blog. It's impossible to specify the link if it's moving!

Change History (11)

comment:1 @foolswisdom9 years ago

mattyrob, I imagine the details are sufficient to the core developers, but to allow others to try to help, maybe even including which plugin this affects will inspire more participation?

comment:2 @foolswisdom9 years ago

Oh, just catching up on wp-testers and found your post naming the plugin Subscribe2

comment:3 @mattyrob9 years ago

  • Priority changed from normal to low
  • Severity changed from major to minor

I've managed to implement a workaround on my plugin that changes the substituted link based upon the user capability level in WordPress.

if (current_user_can('manage_options')) {
	$this->s2form = $this->use_profile_admin; //use admin form link
} else {
	$this->s2form = $this->use_profile_users; //use users form link

From my point of view though this is still something that could be tidie up in the backend as linking in to 2 menus for 1 purpose that only changes depending on user capability seems backwards. It also generates essentially unecessary code in plugins.

comment:4 @ryan9 years ago

I'm not too fond of the current behavior either. I'll try to muster consensus on changing it back.

comment:5 @markjaquith9 years ago

We could also just API the function (add_users_page()) and do the logic test there.

Or we could change it so that the profile is the default item. I don't think anyone is going to stage a protest over one additional click to get to the Authors and Users page.

comment:6 @mattyrob9 years ago

I think I'd support reverting to Users or to implementing add_users_page() rather than making Profile the default.

two reasons for not making Profile default:

1/ It doesn't make sense in the admin panel - meaning the title Profile is not a correct description of the menu contents
2/ Visually it would be too many "Ps" with Presentation, Plugins and Profile all next to each other!

Just my pedantic mind at work :-)

comment:7 @Nazgul9 years ago

  • Milestone changed from 2.1.1 to 2.1.2

+1 for changing it back.

comment:8 @markjaquith9 years ago

  • Keywords needs-patch added

+1 for add_users_page() API. That way we are free to change it in the future without harm.

comment:10 @markjaquith9 years ago

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

(In [4987]) add_users_page() to address changing top-level menu item. fixes #3706

comment:11 @markjaquith9 years ago

(In [4988]) add_users_page() to address changing top-level menu item. fixes #3706

Note: See TracTickets for help on using tickets.