[wp-trac] [WordPress Trac] #12718: Better structure for admin menu

[WordPress Trac]

#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