Make WordPress Core

Opened 19 years ago

Closed 18 years ago

Last modified 17 years ago

#1175 closed enhancement (wontfix)

Prioritize plugins

Reported by: skeltoac's profile Skeltoac Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0
Component: Administration Keywords:
Focuses: Cc:

Description

Plugins are loaded in an uncontrolled order. If their loading order could be controlled, plugin-to-plugin dependencies could be reliable and plugins could create APIs for use by other plugins, adding a new dimension of extensibility.

Change History (18)

#1 @Skeltoac
19 years ago

  • Patch set to No

#2 @MC_incubus
19 years ago

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.

#3 @MC_incubus
19 years ago

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

#4 @MC_incubus
19 years ago

  • Resolution changed from 10 to 70

#5 @Skeltoac
19 years ago

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...

#6 @Skeltoac
19 years ago

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

#7 @Skeltoac
19 years ago

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

#8 @ryan
19 years ago

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

#9 @ryan
19 years ago

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.

#10 @Skeltoac
19 years ago

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

#11 @skippy
19 years ago

  • Keywords bg|needs-patch added
  • Resolution changed from invalid to fixed
  • Status changed from new to closed

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

#12 @majelbstoat
18 years ago

  • Milestone set to 2.1
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 1.5 to 2.0

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?

#13 @majelbstoat
18 years ago

Oops, I meant #765

#14 @ryan
18 years ago

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.

#15 @majelbstoat
18 years ago

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?

#16 @ryan
18 years ago

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.

#17 @majelbstoat
18 years ago

  • Keywords bg|needs-patch removed
  • Resolution set to wontfix
  • Status changed from reopened to closed

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

#18 @Nazgul
17 years ago

  • Milestone 2.1 deleted
Note: See TracTickets for help on using tickets.