Make WordPress Core

Opened 15 years ago

Closed 14 years ago

Last modified 12 years ago

#10190 closed enhancement (wontfix)

Plugin Dependency Class API

Reported by: shanef's profile ShaneF Owned by: westi's profile westi
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Plugins Keywords:
Focuses: Cc:


This is the start of my WP_Plugin_Dependency class.

This has "checks" to see if a plugin or theme can be activated based on it's requirements. The plugin-dependency.php file is placed in '/wp-admin/includes/'.

Attachments (1)

plugin-dependency.php (5.3 KB) - added by ShaneF 15 years ago.

Download all attachments as: .zip

Change History (16)

#1 follow-up: @Denis-de-Bernardy
15 years ago

As much as I like the idea, I think this should be dealt with by the plugins themselves, or internally over in (using the readme files).

#2 @logikal16
15 years ago

Alternative: a function, get_plugin_versions() that prints an array of active plugins and their corresponding versions.

This would make it the plugin author's responsibility to check for plugin dependencies.

#3 @Denis-de-Bernardy
15 years ago

how about this:

function get_plugin_versions() {
    require_once(ABSPATH . '/wp-admin/includes/plugin.php');

    $plugins = array();
    $all_plugins = get_plugins();
    $active_plugins = get_option('active_plugins');

    foreach ($active_plugins as $file)
        $plugins[$file] = $all_plugins[$files]['Version'];

    return $plugins;

#4 @logikal16
15 years ago

One more... this would allow authors to choose whether to see ALL plugins, or whether to see just ACTIVE ones:

function get_plugin_versions($status = 'active') {
    require_once(ABSPATH . '/wp-admin/includes/plugin.php');

    $plugins = array();
    $all_plugins = get_plugins();
    $active_plugins = get_option('active_plugins');

    foreach ($all_plugins as $key => $attr) {
        if ('active' != $status || in_array($key, $active_plugins)) {
            $plugins[$attr['Name']] = $attr['Version'];
    return $plugins;

#5 in reply to: ↑ 1 @ShaneF
15 years ago

Replying to Denis-de-Bernardy:

As much as I like the idea, I think this should be dealt with by the plugins themselves, or internally over in (using the readme files).

Not all plugins are released via

#6 @mikeschinkel
15 years ago

While I'm not ready to support inclusion of this specific patch as I'm having a discussion about doing something similar but more involved on wp-hackers I'd like to ask Denis-de-Bernardy why he thinks it better to depend on often inexperienced plugin authors to do version checking when much of it can be done in the core?

Moving to the core increases consistency and robustness for the end user (who blames WordPress not the plugin when things go wrong) and doing so in the core allows for hooks to be defined for plugin authors to augment or override dependency determination thus making it more obvious to a plugin authors that they need to do dependency checking and also how to do it.

#7 @Denis-de-Bernardy
15 years ago

@mike: If any, my main point is that this depend should be in a readme file. If a plugin has known depends, we'd want to add a Depends: field, either in the plugin's file or in its readme file, and have WP refuse to install the plugin (or automatically install and activate its depends) if the depends are not present.

That plugins aren't all hosted on should not be a valid argument. It's very possible to look at the plugin/readme headers from within WP before activating.

#8 @ShaneF
15 years ago

I posted here ( on the hackers mailing list on how this is might go in direction.

#9 @mikeschinkel
15 years ago

@Denis-de-Bernardy: I defintely agree that adding a header field in the plugin is the proper way to notate the existence of a dependency. I even stated so here on an email send earlier than your reply above:

Differences from what I read in your comments are 1.) I'm proposing the header field to denote the name to be used to bootstrap validation code (vs. writing prose in a readme) and 2.) I'm proposing more granular named "interfaces" vs. simple "dependencies." Those differences, documented in the thread, add a significant number of capabilities over mere prose.

@ShaneF: I also replied on the wp-hackers list:

In summary I think it'd be best to revisit your concept and join forces using your dependency work with the "interfaces" concept we've been discussing on the wp-hackers list.

#10 @westi
15 years ago

  • Owner changed from ShaneF to westi
  • Status changed from new to reviewing

#11 @ryan
15 years ago

  • Type changed from task (blessed) to enhancement

#12 @westi
14 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from reviewing to closed

I'm not sure of the benifit of this and in the end it is encouraging people to create plugins which depend explicitly on the behaviour of other plugins and make it harder for end-users to get things up and running.

I much prefer the concept of graceful degradation - plugins that want to make use of other plugins should be written such that they work fine when those other plugins are not there but have enhanced functionality when they are.

Marking as WONTFIX.

#13 @scribu
13 years ago

See #11308 for a followup.

#14 @mikeschinkel
13 years ago

  • Cc mikeschinkel@… added

#15 @stephenh1988
12 years ago

  • Cc stephen@… added
Note: See TracTickets for help on using tickets.