WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#16048 closed enhancement (maybelater)

Make Admin Menu Generation Hookable

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

Description

This ticket proposes to make the code that generates the admin menus "hookable." It removes the hard-coded call to _wp_menu_output() and replaces it with a priority 0 call to the 'adminmenu' hook that currently immediately precedes the existing call to _wp_menu_output(). It also adds an add_action() call to assign _wp_menu_output() to be called by the 'adminmenu' hook at priority 0.

With the exception of a plugin or theme using a negative or zero priority for the 'adminmenu' hook this hook will be 100% backward compatible.

Why?

Currently _wp_menu_output() in /wp-admin/menu-header.php is coded with very few hooks making it hard at time to modify for client requirements.

The admin menu variables $menu and $submenu use numeric array indexes for menu page and submenu page placement which makes it harder to ensure that plugins and themes that modify admin menus are robust and compatible with other plugins and themes that modify admin menus. It's been discussed that thIs admin menu structure is suboptimal but for sake of backward compatibility it's wisely been decided to maintain it as is.

This hook would allow a site developer to build his or her own admin menus without modifying core. It would allow a theme vendor to do the same with the caveat that replacing the admin menu means that other plugins or themes might not work as expected. In general this might be a problem but for those building custom solutions based on WordPress, especially when they are building products based on WordPress (as I am) this would be extremely helpful. If it was felt necessary to ensure people don't do this without understanding the compatibilities issues a requirement to first set a constant like 'INCOMPATIBLE_ADMIN_MENUS' could be required to make it work.

Enabling this would also enable people (like me) to explore building admin menus such that in the future better admin menus could evolve to the point they are well thought out enough to actually replace the core admin menus.

So hopefully since this is such a small patch, introduces no new hooks, and is 99.999% backward compatible it should be a no-brainer?

Attachments (2)

hook-_wp_menu_output.diff (764 bytes) - added by mikeschinkel 9 years ago.
Makes _wp_menu_output() Hookable
hook-_wp_menu_output-v2.diff (1.1 KB) - added by mikeschinkel 9 years ago.
Hooks _wp_menu_output(), adds test for CUSTOM_ADMIN_MENUS constant

Download all attachments as: .zip

Change History (13)

@mikeschinkel
9 years ago

Makes _wp_menu_output() Hookable

#1 @mikeschinkel
9 years ago

Related: #16050 - While #16050 is applicable for more use-cases to be clear that ticket does not eliminate the need for this ticket as this ticket approaches the requirement from another perspective.

@mikeschinkel
9 years ago

Hooks _wp_menu_output(), adds test for CUSTOM_ADMIN_MENUS constant

#2 @mikeschinkel
9 years ago

I just added a second patch with introduces a test for a CUSTOM_ADMIN_MENUS constant in /wp-admin/menu.php to allow bypassing of all the admin menu creation code if the developer wants to build admin menus using their own logic.

#3 @mikeschinkel
9 years ago

  • Keywords has-patch added

#4 @mikeschinkel
9 years ago

  • Cc mikeschinkel@… added

#5 @westi
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • 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

#6 @mikeschinkel
9 years ago

  • Resolution wontfix 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?

#7 follow-ups: @scribu
9 years ago

I don't see the problem with this patch. Take wp_list_categories() as an example:

  • we add loads of classes by default, for easy CSS styling
  • we use a Walker that can be overwritten
  • we have a filter at the end, for ultimate extensibility

Each of these methods is usefull in particular contexts. So why not allow something similar for the admin menu as well?

#8 in reply to: ↑ 7 @mikeschinkel
9 years ago

Replying to scribu:

Each of these methods is usefull in particular contexts. So why not allow something similar for the admin menu as well?

Thank you.

#9 in reply to: ↑ 7 ; follow-up: @westi
9 years ago

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

Replying to scribu:

I don't see the problem with this patch. Take wp_list_categories() as an example:

  • we add loads of classes by default, for easy CSS styling
  • we use a Walker that can be overwritten
  • we have a filter at the end, for ultimate extensibility

Each of these methods is usefull in particular contexts. So why not allow something similar for the admin menu as well?

Because that is for frontend and this is backend.

At present we don't anticipate including customisations into core for theming the admin dashboard.

As I said above the best first step would be to improve the current markup/css to make it easier to theme.

#10 in reply to: ↑ 9 @ericmann
9 years ago

Replying to westi:

Because that is for frontend and this is backend.

At present we don't anticipate including customisations into core for theming the admin dashboard.

As I said above the best first step would be to improve the current markup/css to make it easier to theme.

If you've already made up you mind, there's not much I can say to change it. But consider that for many end users, the look, feel, and functionality of the back end is just as or more important than that of the front-end.

Several people are using WordPress as a fully-fledged CMS that touches multiple users. When you've got a team of doctors writing to a collaborative medical website and sharing resources, many will be using and interacting with the backend far more often than they ever go to the frontend. Theming the backend is becoming a more common requirement for business (i.e. non-blogging, multi-user sites).

#11 @brianlayman
8 years ago

Given that my task today is to research/prototype a fully themed admin, I fully agree with Eric's statement. Only I'm working with lawyers today instead of doctors.

Note: See TracTickets for help on using tickets.