[wp-hackers] Plans to modify /wp-admin/plugins.php for 3.1?

Sat Sep 11 08:26:41 UTC 2010

> On Sep 11, 2010, at 3:12 AM, scribu wrote:
> 
>> The plugins page is in flux, with the new network area and the
>> ajaxified admin screens, so might as well make your suggestion now.
>> 
>> On Saturday, September 11, 2010, Mike Schinkel
>> <mikeschinkel at newclarity.net> wrote:
>>> Are there any plans to modify /wp-admin/plugins.php for 3.1?
>>> 
>>> I just tried to do something that should have been straightforward but was very difficult due to lack of extensibility. So I'd like to submit a proposed patch for it sometime over the next month but I don't want to work on it while it is otherwise in development.

Well, at the risk of being rather un-thorough I'll take a quick stab at it.

But first here was my use case:  I wanted to create a plugin that could move plugins to an "Archive" list so that you can have plugins in your system but out of site until you want to look at them.  Currently the only options are activated, deactivated or deleted; I wanted deactivated and also not part of the main list.  Trying to accomplish that was, shall we way, a bit frustrating. I was able to make it work but not with all the elegance we'd expect in code OR in the UI.  

If you want to play with it to visualize here it is (but I wouldn't want to "release" it in the public repository yet given how I had to hack to get around issues in core):

http://gist.github.com/574971

Here are the places where I identified the need to add a hook:

#1.) Line 38&39: Plugin Status are hardcoded so no ability to directly add a new status.  Here's the existing code:

if ( !in_array($status, array('all', 'active', 'inactive', 'recent', 'upgrade', 'network', 'mustuse', 'dropins', 'search')) )
	$status = 'all';

#2.)Lines 53 thru 311 are a switch ($action) statement with no option to run a custom action.  To get around this I hooked admin_init and just essentially ignore all the code in plugin.php, some of which I really needed.

#3.) Line 378-392 - the counts for the different type of plugins are stored in script local variables. for which there's no direct hook access, and there's not even any reasonable hooks that will allow you to get access to them by declaring them global. These should be packaged in an array and passed thought a filter so they could be set/modified:

$all_plugins = apply_filters( 'all_plugins', get_plugins() );
$search_plugins = array();
$active_plugins = array();
$inactive_plugins = array();
$recent_plugins = array();
$recently_activated = get_option('recently_activated', array());
$upgrade_plugins = array();
$network_plugins = array();
$mustuse_plugins = $dropins_plugins = array();
if ( ! is_multisite() || current_user_can('manage_network_plugins') ) {
	if ( apply_filters( 'show_advanced_plugins', true, 'mustuse' ) )
		$mustuse_plugins = get_mu_plugins();
	if ( apply_filters( 'show_advanced_plugins', true, 'dropins' ) )
		$dropins_plugins = get_dropins();
}

#4.) Lines 435 thru 442 - Similar to #3 the totals for each type of plugin are set to script local variables and there's no good way to affect the even with global access:

$total_all_plugins = count($all_plugins);
$total_inactive_plugins = count($inactive_plugins);
$total_active_plugins = count($active_plugins);
$total_recent_plugins = count($recent_plugins);
$total_upgrade_plugins = count($upgrade_plugins);
$total_network_plugins = count($network_plugins);
$total_mustuse_plugins = count($mustuse_plugins);
$total_dropins_plugins = count($dropins_plugins);

#5.) Lines 504 thru 642 - The print_plugins_table() function only provides a filter for the links but not for the content row for a plugin nor for the headings. It provides an after_row action but that action doesn't let you modify the row (unless you play programmer's Russian roulette with ob_start()/ob_get_clean()).

#6.) Lines 648-677 - The print_plugin_actions() function hardcodes the bulk actions and provides no way to add to, modify or delete existing bulk options (I actually did write a fix for this which is at the bottom of my plugin in my Gist file, see http://gist.github.com/574971)

#7.) Lines 699 thru 702 - The status hyperlinks with plugin counts are hardcoded here with no way to filter them.  (For my plugin I played programmer's Russian roulette with ob_start()/ob_get_clean() and hooked the admin_footer action and I had to do some really nasty and fragile regular expression matching.  A small change to core or by another plugin would easily break what I'd done.

Thus we have at least 7 places to update and those are just the ones that I noticed via a quick scan; there are more places than that which could use some love.  Yes I was able to get the plugin working but I couldn't get all the links at the top to display without duplicating a bunch of code from core (which I already had to do a bit of.) End users would see this and certainly get confused.  So the shortcoming of those 7 areas it hard to extend the plugin page in a reliable and usable way.  

Still, I already love the tiny feature set of this plugin;  having to wade through 20-30 plugins when I'm usually focused on just 2 or 3 has been a real pain. Now I've got control of the plugin screen instead.  But what would be even better would be if I could control it reliably so I could release the plugin and let others benefit too.

-Mike

>> 
>> -Mike
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> 
> 
> -- 
> http://scribu.net
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers