WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#16050 closed enhancement (maybelater)

Add 'menu_page' and 'submenu_page' hooks

Reported by: mikeschinkel Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: menus has-patch
Focuses: Cc:

Description

Currently if it very difficult to modify the output of the admin menus. This ticket adds a patch that introduces 'menu_page' and 'submenu_page' hooks to enable a themer or plugin developer to intercept and modify the output for menu page sections and submenu page options in the admin menu.

It does not attempt to add any functionality, it only make the admin menu hookable.

This is related to #16048 but this ticket is applicable in more use-cases. To be clear however, this ticket does not eliminate the need for ticket #16048 as that ticket approaches the requirement from another perspective.

Attachments (1)

menu_page+submenu_page-hooks.diff (2.6 KB) - added by mikeschinkel 3 years ago.
Adds 'menu_page' and 'submenu_page' hooks

Download all attachments as: .zip

Change History (19)

mikeschinkel3 years ago

Adds 'menu_page' and 'submenu_page' hooks

comment:1 mikeschinkel3 years ago

  • Keywords has-patch added

comment:2 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:3 westi3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

I'm not sure why a plugin / theme should be editing the output of the admin menus.

I think the actual resolution for these issues would be to make it easier to style the admin menu and pages differently.

A new ticket which focused on minor incremental improvements to the HTML and CSS would be a much more appropriate way forward

comment:4 follow-up: mikeschinkel3 years ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

You closed this without even giving it a hearing.

The reason the plugins need to edit the output of the menus is that the clients say they don't like the way the current menus work and please change them.

Stying the menus is not at all the issue. The ability to reconfigure the menu as per the client requirements is the issue.

Here is a screenshot of what the client required the menu to be and I had to resort to using ob_start(), ob_get_clean() and preg_replace() to make it work; very, very nasty:

http://mikeschinkel.com/websnaps/skitched-20110114-045601.png

Note there are very few submenu pages, and the "Microsite Editor" subpage was required to be displayed for several different URLs in the admin. This took over 2 days to get working and that's just insane.

Listen, I'm not asking for any features, I'm just asking for hooks. I've been told if we need hooks the team is happy to include them. Why to immediate dismissal of the request for these?

comment:5 scribu3 years ago

I'm going to close this as dup of #16048, since the discussion is obviously being duplicated.

Please move the patch over there.

comment:6 scribu3 years ago

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

comment:7 mikeschinkel3 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

I duplicated the discussion because westi duplicated it. But they are not duplicates, they are different patches. As they are different patches and the decision to apply each patch should be separate; reopening.

comment:8 in reply to: ↑ 4 westi3 years ago

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

Replying to mikeschinkel:

You closed this without even giving it a hearing.

The reason the plugins need to edit the output of the menus is that the clients say they don't like the way the current menus work and please change them.

Stying the menus is not at all the issue. The ability to reconfigure the menu as per the client requirements is the issue.

Here is a screenshot of what the client required the menu to be and I had to resort to using ob_start(), ob_get_clean() and preg_replace() to make it work; very, very nasty:

http://mikeschinkel.com/websnaps/skitched-20110114-045601.png

Note there are very few submenu pages, and the "Microsite Editor" subpage was required to be displayed for several different URLs in the admin. This took over 2 days to get working and that's just insane.

Listen, I'm not asking for any features, I'm just asking for hooks. I've been told if we need hooks the team is happy to include them. Why to immediate dismissal of the request for these?

It did get a hearing.

At present we have no plans to do this - I don't think the hooks described here are a good idea.

This was closed as maybelater because it is no something we envisage doing at the moment and we are now trying to close these tickets down so as to make trac more managable and to not have 1000's of tickets for things we don't anticipate doing at the moment.

comment:9 mikeschinkel3 years ago

Do you envision some way to enable more control over the menu structures? Currently it's very difficult to get them to do what is wanted by clients. I would like to be able to build a tool that lets an administrator have control over the admin menus but without hooks it's essentially impossible.

comment:10 follow-up: scribu3 years ago

There already is a plugin for that:

http://wordpress.org/extend/plugins/admin-menu-editor/

comment:11 in reply to: ↑ 10 mikeschinkel3 years ago

Replying to scribu:

There already is a plugin for that:

http://wordpress.org/extend/plugins/admin-menu-editor/

This screenshot illustrates why Admin Menu Editor does not address the concepts addressed by this patch:

http://mikeschinkel.com/websnaps/skitched-20110114-192912.png

You can find an exhaustively detailed explanation about why this patch (or another that addresses the issue) is needed, along with #16204 and ideally also #16048 here:

comment:12 follow-up: scribu3 years ago

From the plugin readme:

If you delete any of the default menus they will reappear after saving. This is by design. To get rid of a menu for good, either hide it or set it's access rights to a higher level.

comment:13 in reply to: ↑ 12 mikeschinkel3 years ago

Replying to scribu:

From the plugin readme:

If you delete any of the default menus they will reappear after saving. This is by design. To get rid of a menu for good, either hide it or set it's access rights to a higher level.

That solved 1/2 of the problem, thank you. It had not occurred to me to use user rights in that manner.

However, there is still the problem with the "Posts" menu page inheriting the "Category"'s URL. Is there a way for the plugin to fix that?

http://mikeschinkel.com/websnaps/Menu_Editor_‹_WordPress_3.0_Test_Site_—_WordPress-20110115-075501.png

comment:14 follow-up: scribu3 years ago

I don't know. You should ask in the plugin's support forum.

comment:15 in reply to: ↑ 14 mikeschinkel3 years ago

Replying to scribu:

I don't know. You should ask in the plugin's support forum.

I'm not asking because I want to learn to use the plugin, I'm asking because I don't think it's possible for a plugin to fix this without (some of) the hooks proposed on this ticket (though I'd love to learn that I'm wrong.) That's my only reason for asking.

comment:16 follow-up: scribu3 years ago

There a contradiction between "I'm not asking because I want to learn to use the plugin" and "though I'd love to learn that I'm wrong".

Version 0, edited 3 years ago by scribu (next)

comment:17 in reply to: ↑ 16 mikeschinkel3 years ago

Replying to scribu:

There's a contradiction between "I'm not asking because I want to learn to use the plugin" and "though I'd love to learn that I'm wrong".

Sorry, I'm missing your point.

On the other hand I'm surprised you don't see the contradiction in telling me there is a plugin that handles what my ticket implies is not possible to handle, and then when I point out that it doesn't handle by asking you to show me how the plugin handles it you refer me to the plugin's support. My only takeaway is that you are not interested in helping nor in actually understanding the issue but are interested in contradicting.

So I will restate; I do not believe it is possible to fix the link in the $menu section so that it does not get changed to be the same as the link for the first $submenu. I really don't care how to do it in the plugin you suggested, I want to be able to do it in my own plugin and thus I'm asking for hooks to make it possible.

But, as I said before, if it is possible I'll happily agree I was wrong; I frankly don't care to be right or wrong here; I just want to be able to fully control the admin menu from within a plugin and I don't currently believe that it is possible without using PHP output buffering and fragile preg_replace() code.

comment:18 mikeschinkel3 years ago

Another issue with the admin menu system I just came across. Let's assume the requirements are to:

1.) Make the Dashboard menu page have no submenus, and

2.) Make the Dashboard menu page link to /wp-admin/index.php?page=analytics360.php

The menu system seems to again force it's will over my plugin's code yet again. If I use this in an 'admin_menu' hook:

add_menu_page('Dashboard','Dashboard','read','index.php?page=analytics360.php',false,false,2);

The link becomes an unworkable:

/wp-admin/admin.php?page=index.php?page=analytics360.php

Oh the other hand if I use this instead the dashboard won't load:

add_menu_page('Dashboard','Dashboard','read','analytics360.php',false,false,2);

And if I use this the then the dashboard loads again:

add_menu_page('Dashboard','Dashboard','read','page=analytics360.php',false,false,2);

But the link is broken yet again:

/wp-admin/page=analytics360.php

It appears to be a catch-22, no way around this in current WordPress. Now I anticipate someone will say "Use a different URL structure like this instead", something like this:

/wp-admin/admin.php?page=analytics360.php

And normally I would agree except in my use-case where I ran into this problem I was trying to link to the MailChimp Analytics 360 plugin's dashboard instead of the default dashboard, and I didn't want to have to modify their code. Yes I can figure out a way to hack around this but it is indeed a hack.

So once again, please reconsider adding these hooks and the main one need on ticket #16204.

Note: See TracTickets for help on using tickets.