#1175 closed enhancement (wontfix)
Prioritize plugins
Reported by: |
|
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)
#3
@
20 years ago
Another cool thing is that this will work even if the plugin you need is disabled!
#5
@
20 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
@
20 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
@
20 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
@
20 years ago
That's nice when you have a hard dependency, but won't help with soft dependencies.
#9
@
20 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.
#11
@
20 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
@
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?
#14
@
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
@
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
@
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.
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.