Prioritize plugins

If you have a plugin that depends on another plugin, you could have the dependent do this (right at the top):

include_once('plugin_i_need.php');

When plugins are called, they are called using include_once(). This means that if your dependent plugin is called first, it will include the plugin it needs, and when WP goes to include that plugin, nothing will happen because it has already been included. If, however, WP loads the plugin you need first, the include_once() in your dependent plugin will be ineffective (and unnecessary), because it has already been included. Either way, you can create a dependency relationship this way. The great thing about this is that you don't need to modify the original plugin. Just for plugins that need the other plugin, you basically say "I need this plugin to work."

Make sure that you clearly state that your plugin depends on another plugin.

Another cool thing is that this will work even if the plugin you need is disabled!

It sure will, but that's not ideal. Twould be a boon to develop a plugin dependency scheme of some sort, enforcing deactivation on child plugins, but that's making WP look like a Microsoft product. Rather, I'll see what I can do about making child plugins self-deactivate or refuse to load if their parent plugin is inactive. I just don't want to query the database every time a child is loaded. More research, one more foray into the flowery fields of the WordPress core for answers...

From the PHP Manual: "Any valid PHP code may appear inside a function, even other functions and class definitions." The child plugin can have all its code inside a wrapper function. At the end, outside the wrapper function, the plugin can fork like this: if ParentPlugin? is loaded, call MyWrapperFunction?; else add_action('my_parent_plugin_loaded', 'my_wrapper_function'); and then create the action hook 'my_parent_plugin_loaded' at the end of the parent plugin. This way, activated child plugins will never fully load if the parent is deactivated. Are there any other good reasons to prioritize plugins? Troubleshooting maybe? If not, this ticket is dead.

edited on: 03-27-05 23:06

For plugin dependency, I have created a model to defer loading a dependent plugin's core until another plugin has loaded. It differs from setting a priority in that it actually prevents a dependent plugin from loading in case the parent plugin is deactivated. Working example is at http://www.skeltoac.com/zip/count-my-clicks.zip. Basic framework:

key-plugin.php <?php // Plugin Core $parent_plugin_loaded = true; do_action('parent_plugin_loaded'); ?>

dependent-plugin.php <?php function loadDependentPlugin() {

// Plugin Core

} if ($parent_plugin_loaded) loadDependentPlugin(); else add_action('parent_plugin_loaded','loadDependentPlugin'); ?>

edited on: 03-29-05 18:29

That's nice when you have a hard dependency, but won't help with soft dependencies.

Note that since plugins are loaded in filename sort order, a plugin named 00-high-priority-plugin.php will be loaded before 01-lower-priority-plugin.php which will be loaded before low-priority-plugin.php. This is similar to how SysVInit operates.

Noted, thank you. The related locale issue is still beyond my grasp.

marking this closed; since the core issue (plugin load order) is a non-starter, and the reporter has something more mature for plugin dependencies.

I still see this as an issue. As was discussed on #768, there are problems with locales. I have a multilingual plugin, Gengo, which sets the global locale based on the current post's language. Other multilingual plugins exist and I'm sure they do the same. I add a locale filter to set this. However, many plugin authors choose to call plugin_load_textdomain() as soon as the file is included, rather than when first used. (I'm probably guilty of this myself, too). This means that any plugin which is loaded before Gengo will have the blog's default locale.

The majority of the users of Gengo also install other localised plugins, because they want a consistent language across their pages. I've had a number of reports of other plugins not being localised correctly because they are loaded before Gengo is. My best response so far is "rename it x_plugin.php", which is far from ideal and which sometimes doesn't fix the problem.

In general, the ability to specify a high priority for a plugin would allow for a closer integration with WordPress at the earliest possible opportunity, which would be very useful in a number of other areas, I'm sure. We don't need a complex mechanism to make this all work - Ryan's suggestion in #768 of a Priority field in a plugins header would be enough. And if you really wanted to, a Required field could be added as well.

/*
Plugin Name: Parent Plugin
Priority: 1
...
*/

/*
Plugin Name: Child Plugin
Priority: 100
Required: Parent Plugin, Hello Dolly
...
*/

I'm not too bothered about the Required: field to be honest, but I can see how it would be useful. The Priority: field however, I consider, well, a priority :) If this gets approval, I'm more than happy to draw up a patch. Thoughts?

Oops, I meant #765

Plugins that load their textdomain before init is complete are broken. Gengo shoud hook onto the 'init' action with a priority of 0 and other plugins should load their textdomains at the default priority of 10.

I actually need to use the plugins_loaded hook because wordpress' own load_default_textdomain() triggers get_locale(), setting the locale, which can't be changed once it's set. But, that works fine.

Ryan, you actually proposed the Priority header a few months ago. Out of interest, is there a particular reason you don't want to see it implemented now?

Right you are, you need 'plugins_loaded'.

I don't think we need a priority header. Plugins can set priority when they bind to plugins_loaded or init.

Ok, that's fair enough. I'll close this one then.