Introduce register_plugin

[filosofo]

Problem

Plugins load themselves eclectically, with the result that many end up initializing too soon or adding action/filter hook callbacks that can't be accessed by other plugins. Furthermore, plugins all repeat a handful of actions to initialize themselves, and that's code that's repeated across all active plugins.

Solution

I propose that we introduce the following new function, register_plugin(). It's first, required, argument accepts either the name of a function to call or a class to instantiate upon plugins_loaded.

bool register_plugin ( string $init_callback [, array $args ] )

Examples of Use

Class name for the first argument

class My_Plugin_Factory
{
[snip]
}

register_plugin('My_Plugin_Factory');

Function name for the first argument

function my_plugin_loaded( $something = '' )
{
   echo $something; // prints "Whatever"
}

register_plugin('my_plugin_loaded', array( 'init_args' => array( 'Whatever' ) ) );

[westi]

Why?

Plugins can just do the same thing without us adding extra code:

class MyPlugin {
	function action_plugins_loaded() {
		add_action('admin_menu', array('MyPlugin', 'action_admin_menu'));
		load_plugin_textdomain('my-plugin', false, dirname(plugin_basename(__FILE__)) . '/lang');
	}
}
add_action('plugins_loaded', array('MyPlugin','action_plugins_loaded'));

We have a perfectly good api for this already!

[filosofo]

Replying to westi:

Why?

For the reasons mentioned:

• Plugins all have to repeat the same code, sometimes less effectively than we would desire. And code duplication is not desirable.
• Plugins often initialize at the wrong point (too early or too late). This takes care of it for them.

Note that your example only works for static methods in MyPlugin. To actually instantiate, you have to do something like the following:

function load_my_plugin()
{
   global $my_great_plugin;
   $my_great_plugin = new MyPlugin;
}

add_action('plugins_loaded', 'load_my_plugin');

The current API requires practically every single plugin to repeat this type of code.

[westi]

For a non-static class it is just as simple:

add_action('plugins_loaded', create_function('','global $my_plugin_instance; $my_plugin_instance = new My_Plugin();'));

You don't nee d a global scope function for this

[filosofo]

Replying to westi:

For a non-static class it is just as simple:

add_action('plugins_loaded', create_function('','global $my_plugin_instance; $my_plugin_instance = new My_Plugin();'));

You don't nee d a global scope function for this

Anonymous functions are often undesirable. See for example, #14424

Besides, that's still unnecessarily repeated code. And it depends on the plugin authors' knowing to use plugins_loaded in the first place. I'm suggesting that we remove duplicated code, avoid anonymous functions, make plugin objects globally available, and initialize consistently, all in an easy-to-remember function call.

The point isn't that it can't be done currently, but that it could be done better.

Please explain why you think less than thirty more lines of core code is worse than at least three or four lines repeated for every single plugin. Why wouldn't we want to

• avoid code duplication
• make initialization simpler
• make initialization more consistent

?

[westi]

The problem is that this is trying to solve the wrong problem.

The problem is that plugin authors do use the correct hooks not that we don't have a function for them to use.

The solution is education not adding a new function IMHO.

[filosofo]

What about avoiding code duplication? It's a real problem solved by this proposal. And education is simplified with a simpler API.

Besides, there are plenty of examples in WP where syntactic sugar enhances existing APIs: register_activation/deactivation_hook on top of action hooks; the admin settings API, many taxonomy functions, much of the post_type API, are some examples that come to mind where developers could do something another way, but the API was extended to make it simpler and easier.

Not to mention, there are lots of other potential arguments that could be added to the $args array, such as activation and deactivation callbacks, PHP or WP version checks, etc. For example, a little more code and you could do something like:

register_plugin( 'My_Great_Plugin', array(
   'domain' => 'my-plugin-domain',
   'activation_callback' => array( 'My_Great_Plugin', 'do_on_activation' ),
   'deactivation_callback' => array( 'My_Great_Plugin', 'do_on_deactivation' ),
   'php_min' => '5.2',
   'wp_min' => '3.2',
) );

[scribu]

I have a similar function in my scb Framework, but it's necessary only because I need to do some extra stuff to get activation hooks to work.

I don't think the amount of duplicated code saved is worth the extra level of indirection.

Plugin authors would still need to learn about register_plugin(), instead of learning the name of the appropriate hook.

[filosofo]

As Samuel Johnson said, "read over your compositions, and wherever you meet with a passage which you think is particularly fine, strike it out."