Skip to main content
2 of 7
added 570 characters in body
scribu
  • 13.2k
  • 38
  • 49

_Note: This answer is just here to make discussion between @scribu and @kaiser easier. Mods: Please don't delete. Users/Readers: Please don't vote. If you want to follow the discussion, take a look at the revision/edit log. If you want to join the discussion, edit the Answer. If the discussion has a result, then it will be marked as such. Thank you._


Szenarios

There are also different szenarios that weight different, where you could have a plugin dependency. (The examples are only fictional). The word "(parent) Plugin" can be exchanged with "Theme" from parent point of view.
  1. (hard) A child plugin that only extends the functionality or alters the display (and similar) of an existing plugin and therefore can't exist without the parent. Example: BuddyPress » BuddyPress-FunkyCommentDisplay
  2. (normal) A plugin that has extended functionality when a child plugin is activated. Example: jQueryAttachmentCarousel » jQuerySlideDeck
  3. (soft) A plugin that just adds a feature. Example: DisneyWonderlandTheme » MickeysSocialLinks

In the following I try to sketch what happens when you update the "other" plugin and the check doesn't work anymore.

  • Ad 1) The plugin couldn't exist without BuddyPress activated » Stuff is completely broken.
  • Ad 2) The plugin couldn't offer the option to switch from Carousel to SlideDeck » Displays wired (I assume that styles are modified to SlideDeck).
  • Ad 3) MickeysSocialLinks disappear.

Check

There are imho three possibilities to check against, if you want to know if a plugin is active:
  • A. Does the folder exist?
  • B. Does the main file - option 'active_plugins' - exist?
  • C. Does a particular function exist?

If I now take my Internal Link Checker Plugin as an example, that offers no public API and isn't meant to get extended, then I'd see no reason (as author) to not change internal function naming on demand or just on will. So if someone would try to piggyback on this plugin, then stuff would simply break (depending on functionality and tightness of bundling) on update. The same goes for file names. I'd have no real reason (aside from that the plugin would get deactivated on update) to not change the filename. The only thing that would hold me back from changing the folder name is that the update check & notification runs against the file name - if it's hosted in the official repo.

So I'd say from weakest (easy to change) to toughest (a lot speak against changing) part of a (parent) plugin would be:

function » main file name » folder


When I said that a function check is less fragile than using is_plugin_active() I assumed that the function in question is one that the plugin author explicitly encourages. The ultimate example of this would be the wp_pagenavi() template tag offered by the WP-PageNavi plugin.

The difficulty in defining dependencies is that there's no standard way to uniquely identify plugins that doesn't involve file names.

More thoughts on the subject:

http://wordpress.org/support/topic/plugin-plugin-dependencies-unreliable-plugin-namingidentifying-scheme

kaiser
  • 50.8k
  • 27
  • 150
  • 244