[wp-trac] [WordPress Trac] #12718: Better structure for admin menu
WordPress Trac
wp-trac at lists.automattic.com
Thu Aug 2 04:51:07 UTC 2012
#12718: Better structure for admin menu
------------------------------------+-----------------------
Reporter: scribu | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone: 3.5
Component: Plugins | Version:
Severity: normal | Resolution:
Keywords: has-patch dev-feedback |
------------------------------------+-----------------------
Comment (by mikeschinkel):
Replying to [comment:59 azaozz]:
> This is OT here but perhaps we could implement some means of contacting
the plugin authors directly when there's something in core that affects
their plugin(s). Creating, refactoring or updating an API shouldn't be
held back and made dependent on plugins that "do something wrong" with
it...
I agree with this, with caveats...
> Filtered the plugins that use `global $menu` by plugin name rather than
file. There are 237 plugins in total. This will be reduced further by
removing plugins by same authors.
>
> So, as @nacin suggested, we could commit a new menu API but instead of
limiting it (a lot) to keep it back-compat, we can email about 200 or so
plugin authors and ask them to update their plugins.
If you consider the class of users most likely to make changes to the
admin menu outside of that admin menu APIs, it's most likely not plugin
authors because by nature most plugin authors want their plugins to
continue to look and feel like WordPress. And end-user bloggers are
typically not anal enough to spend their money on getting custom admin
menus.
Instead I think it's highly likely that the people who have done the most
direct manipulation of `$menu` and `$submenu` are '''custom site
builders''' whose clients have requested the admin menus to be simplified
in ways that the WordPress admin menu API does not currently support. I
know our main client has had us do major surgery on the admin menu system
and I've had many developers comment about similar needs on some of my
WordPress Answers posts, so I expect there are many people who will indeed
be in the same situation.
So if you break backward compatibility you are likely to create a lot of
havoc for all those consultants who were in a rock-and-a-hard place who
could not have achieved what their clients asked for any other way than to
directly modify `$menu` and `$submenu`. Some of those consultants will
likely be happy they get to bill their client's more through no fault of
their own but many will be caught off guard and have to eat the cost of
updates. And then there are the business end-users who if their site
breaks will probably blame WordPress for it, giving ammunition to others
in their organizations who want use a different CMS for their next
website.
All that is to say that WordPress shouldn't break old implementations that
use `$menu` and `$submenu` but instead draw a line in the sand between the
''"old way"'' and the ''"new way"'', as I think @scribu is suggesting
here:
Replying to [comment:64 scribu]:
> And there's a clear migration path for plugins:
>
> {{{
> global $admin_menu, $menu;
>
> if ( $admin_menu ) {
> // use new $admin_menu API
> } else {
> // hack on the old $menu global
> }
> }}}
Which raises some concerns for various use-cases ''(I mention plugins but
same goes for themes):''
1. '''New Installation of WordPress''': Easy, use the new admin menu
system.
2. '''Install Old Plugin on Site using Newer Menus''': User attempts to
install a plugin that uses `$menu` and `$submenu` and is not using a
plugin that uses the new approach: offer to downgrade the user but give
them a warning and recommend they instead contact the plugin developer to
upgrade.
3. '''Upgrade Site using Older Menus to New WordPress Version''': If there
are no plugins using old menu system switch to the new one. If there are
plugins using the old system tell the user and give them a choice to
deactive and go with new system or keep plugins and use old system.
4. '''Install Newer Plugin on Site using Older Menus''': Tell the user
they can't have both and ask which plugins they prefer to keep and suggest
they contact the plugin author(s) to update.
As for detection, I'm sure at plugin install time the plugin installer can
detect access to `$admin_menu` if implemented as an object ''(which
appears to be the case)'', and the plugin installer could attempt to use a
version of `$menu` and `$submenu` based on `ArrayAccess()` to test for
usage, possibly using `wp_remote_get()` to load WordPress in a special way
to see what happens. It wouldn't catch all situations because some plugins
may selectively add menu pages and submenu pages based on `$pagenow` or
some other criteria, but I expect it'll catch the vast majority. The other
rare situations can just crash as occasionally happens with custom code.
In addition it workd be helpful to set up a pair of indicators: a
`get_option()` that if it not set tells WordPress uses the new admin menu
system and if set then specifies which to use, as well as a constant that
could use code in `/wp-config.php` to force which admin menu system to
use.
As an aside, my concern for backward compatibility is a concern for
others. We will '''HAPPILY''' switch to a new admin menu system '''ASAP'''
for all our client usage as soon as one is available; the current admin
menu system is by far the biggest bane of our existence related to
outstanding WordPress legacy architecture issues.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/12718#comment:65>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list