Plugin dependency checking
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
|
|
|
Re: Plugin dependency checking
by Shane A. Froebel
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 I rather that there be a API on the plugin itself so other plugins could use it to see if it's there and working.... IMO. Your Friend, Shane scribu wrote: > How about we just use the Extend slug for plugins hosted there and a full > url for the rest? The following examples would all be valid identifiers: > > All-in-1 SEO Pack > all-in-1-seo-pack > http://wordpress.org/extend/plugins/all-in-1-seo-pack > http://example.com/some-other-plugin * > > * The said URL would have to provide an API similar to that on Exend. > > In other words, if you have a plugin called Master hosted on your site and > your site could provide automatic updates for that plugin, then Master could > also be used as a base plugin. > > > -- > http://scribu.net > _______________________________________________ > wp-hackers mailing list > wp-hackers@... > http://lists.automattic.com/mailman/listinfo/wp-hackers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJKMauhAAoJEChMcQvNqPqm/0oQALSkV1/CLijxNPSNSkdsB6ty 5/YbYTS/Zdpdp3ShC1erB/215E8AQkPDENFtjzuAsGTpD4IvuvUa7ZKuwdIl3En+ tiugAPRGmuMeM81yzhHEuFl9mz6QMNh7IyWNo/KkuuCVcZ1eNBZvFMNh8aUbCyT9 C0tUb088OttCqHWzIjnz9v43B1lNaWp1r/OCiFTafGA80BcB5S2D69LijOyjNjlr 3leFya+HBVg3Hkdka5MWRYlDsTL5pmR2EiCbWAmbKasgedG68ps5miqyz6s9KoiE TC7BWbEMk5lEnL/m0pibZ828RkOj/+dzBnRuLt51vDaHwmYainEkQzLZH4CfPEyC 39rWKwaShTut/nlloOz8Koov5/+NUALeaunKEqRx4VavFl5LFUbFqMl3ZeOS7mA6 8x+bETeQeDloGGqabmX528U2iAsQ7PtDd4PCzZxBl1p5uvCyl4HC/9zQzRbOmclD 6QYR9ngCZk+7Zx30TrX6uolsEESK8sm1frArtC0FKRjeY9Lsy+wyN7HPs7ntlzPQ Jcru1DZ1jozXYIeGpUGVkzx2B0Y0241W4celmXD9hWcITugppyg8xIm99fgVnd5M 3CzzCjaLz8PdFcSRNTm446FxB/uva+ONPs5foe7Y/UDG+xFGa87OnzDANv8f/um6 sFECcE7lNQ73K8JGa/8i =QXDz -----END PGP SIGNATURE----- _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
On Fri, Jun 12, 2009 at 4:13 AM, Shane A. Froebel <shane@...>wrote:
> I rather that there be a API on the plugin itself so other plugins could > use it to see if it's there and working.... IMO. > You don't need an API for that. Just do a function_exists('function_defined_in_plugin') or a class_exists(). Like I've said previously, the issue is providing a good user experience in the case that the dependant plugin is not installed + activated + loaded. -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Mike Schinkel-5
::
Rate this Message:
"scribu" <scribu@...> write:
> How about we just use the Extend slug for plugins hosted there > and a full url for the rest? The following examples would all be > valid identifiers: > All-in-1 SEO Pack > all-in-1-seo-pack > http://wordpress.org/extend/plugins/all-in-1-seo-pack > http://example.com/some-other-plugin * Interesting. Looks good to me. > * The said URL would have to provide an API similar to that on Exend. > In other words, if you have a plugin called Master hosted on your > site and your site could provide automatic updates for that plugin, > then Master could also be used as a base plugin. Sounds good. I do think we might be looking for trouble asking sites to implement a hosted API similar to extend, that is unless we provide a reference implementation, or better yet provide it as part of the WordPress distribution or a well-known plugin. FWIW. -Mike _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Stephen Rider
::
Rate this Message:
Hi --
Okay, back up a moment. First... for the moment, FORGET about auto download/install of master plugins. One Thing At A Time or we won't get it committed. Let's figure out dependencies and sub-plugins, and get that rolling. Then later we can improve it with further automation, etc. Second -- I'd like to reiterate the idea I said previously. Two ways to set a "master" plugin: 1) via good old plugin_basename. "myplugin/myplugin.php" is well established in WP, and **by definition** unique. 2) A plugin can register itself as "pluggable" via a function. In the process it establishes its own "master" tag for use by dependents. E.g. register_master_plugin( __FILE__, 'myplugin' ); Again, very common in WordPress -- plugins frequently pick a "keyword" to represent themselves, whether it's an option name or a registered JS dependency. Theoretically there could be duplication, but that hasn't been a problem with the other places such keys are used, so probably won't be here. > I think a better way to display dependency information is to have a > prompt > that tells you which plugin depends on which. This prompt would only > show up > when a user tries to activate or deactivate one or more plugins. > This way, > we don't get three types of plugins. There aren't really three, just two. Regular and Dependent. **Any** plugin can be a "Master" plugin -- all it takes is the existence of some other plugin that requires it. I could create a plugin right now that depends on a function from Akismet, for example. Thus, "Master" isn't really a special type-- it's just a relative term when speaking of Dependent plugins. Under the "Dependent" banner, there are two subtypes: "dependent" and "sub" plugins. The only *real* difference here is how they appear in the Manage Plugins screen. Dependent plugins look just like any other plugin. Sub-plugins appear indented underneath their Master plugin (with Ajax reveal/hide control). Thus if a sub-plugin is dependent on more than one other plugins, it may choose ONE other plugin to be its Master. The reason the sub-plugins are important is that some Master plugins may have a large number of sub-plugins. For example, Spam Karma, right now out of the box comes with TEN Spam Karma plugins. For purposes of upgrades and such, it would be best if these could each be actual WordPress plugins, but we *don't* want to add ten rows in the Manage Plugins screen! Thus the desired ability to specify them as Sub-Plugins that can be hidden away in their own little nook under Spam Karma itself. [FYI -- I'm involved with the development of SK, and this very topic has been discussed there. That's why I keep using it as an example ;-) ] Food for thought/ Questions to answser: 1) We must check required versions of Master plugins (previously mentioned) 2) If a user tries to activate a Dependent plugin and the master is missing or inactive, we need some way to tell the user "You also need Plugin X". That is, the plugin name -- not just the "id tag" discussed earlier. Maybe sub plugins can define their own custom error message for this? 3) If Master plugin is deactivated or goes missing, sub should be deactivated as well. (Not too difficult actually to code it so that if Master is missing or inactive, Sub just doesn't load -- even if "activated".) 4) We somehow need to continuously keep track of versions. What happens if one or the other is upgraded? How about DOWNgraded? Also, we can NOT depend on auto-install routines, nor activate/deactivate hooks. Plugins are often upgraded via FTP, and are often up/ downgraded without being deactivated. Stephen -- Stephen Rider http://striderweb.com/ _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
|
|
|
Re: Plugin dependency checking
by Burt Adsit-3
::
Rate this Message:
Just to throw some more into the mix. What happens now when a base
plugin is auto updated? It seems to change the sequence of the base plugin in the active plugins list. Thus crashing all dependent plugins. Happened about an hour ago. -- Code Is Freedom Burt Adsit _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Stephen Rider
::
Rate this Message:
On Jun 11, 2009, at 9:56 PM, Burt Adsit wrote: > Just to throw some more into the mix. What happens now when a base > plugin is auto updated? It seems to change the sequence of the base > plugin in the active plugins list. Thus crashing all dependent > plugins. Happened about an hour ago. Well... the thing we're talking about doesn't exist yet. We're discussing hypothetical changes to Core WP. What will happen (roughly speaking) is this: All activated normal plugins will load. Next, all activated dependent plugins will load, IF their respective required Master plugins are also active. Plugins will go in rounds. Theoretically a dependent plugin could also be a Master to a third plugin, which would activate in the *third* round.... Stephen -- Stephen Rider http://striderweb.com/ _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
>
> Thus if a sub-plugin is dependent on more than one other plugins, it may > choose ONE other plugin to be its Master. I don't think choosing ONE master plugin is useful. Instead, each plugin should have a button that, when pressed, simply computes the list of other plugins that depend on the plugin at hand. That button may be the "Deactivate" link or a new one. 1) via good old plugin_basename. "myplugin/myplugin.php" is well > established in WP, and **by definition** unique. The Extend slug is also unique. 2) A plugin can register itself as "pluggable" via a function. In the > process it establishes its own "master" tag for use by dependents. E.g. > > register_master_plugin( __FILE__, 'myplugin' ); > If we use either of these methods, there will be no way to retrieve the normal plugin name that you mention here: 2) If a user tries to activate a Dependent plugin and the master is missing > or inactive, we need some way to tell the user "You also need Plugin X". > That is, the plugin name -- not just the "id tag" discussed earlier. Maybe > sub plugins can define their own custom error message for this? > Error messages should be standard. -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Stephen Rider
::
Rate this Message:
On Jun 11, 2009, at 9:49 PM, Mike Schinkel wrote:
>> First... for the moment, FORGET about auto download/install of >> master plugins. One Thing At A Time or we won't get it committed. > > Just for clarity, that's almost trivial by leveraging code already > in the core. Heh. Duly noted. :) Download and auto-install is trivial. Determining what needs to be downloaded/installed may not be. (More later RE version checking....) On Jun 12, 2009, at 2:28 AM, scribu wrote: >> Thus if a sub-plugin is dependent on more than one other plugins, >> it may >> choose ONE other plugin to be its Master. > > I don't think choosing ONE master plugin is useful. Instead, each > plugin > should have a button that, when pressed, simply computes the list of > other > plugins that depend on the plugin at hand. That button may be the > "Deactivate" link or a new one. I'm referring specifically to sub-plugins. (Again, "regular" dependent plugins don't look any different that regular plugins in Admin -- not indented, not under another plugin. Only sub-plugins go specifically underneath another particular plugin.) I think you're looking at it from the code perspective -- I'm looking from the user interface. The same plugin appearing in more than one place will confuse the heck out of users. A Spam Karma sub-plugin might also depend on some framework plugin, but logically goes under Spam Karma, not under the framework plugin. It doesn't need to go both places. Thus, the Master of a sub-plugin is simply the plugin that it appears underneath in the Plugin admin. Okay... one difference for dependents: taking a tip from Drupal, we should add a small line below the Description that says "Requires: Plugin X, Plugin Y". >> 1) via good old plugin_basename. "myplugin/myplugin.php" is well >> established in WP, and **by definition** unique. > > The Extend slug is also unique. True, but not all plugins have one. Also, I'm trying to keep the code straightforward, and using Extend slug complicates things. With plugin_basename we directly identify the plugin file. Ditto a master plugin registering itself with __FILE__ (even better actually). Extend slug is unique, but doesn't give me a definition of what the plugin file itself is -- even in the best of situations the system will have to go look something up in a reference list of some sort. Also... I explicitly do not want to make non-Extend plugins second- class citizens any more than they already are. (grmblemumble) (I'm basically thinking in terms of how adding Admin pages works -- authors can use either the basename or a slug that they pick. I think it's a good system, and it's already familiar to plugin authors.) Of course, if a plugin registers itself, it can use its Extend slug as the keyword. ;-) > 2) A plugin can register itself as "pluggable" via a function. In the >> process it establishes its own "master" tag for use by dependents. >> E.g. >> >> register_master_plugin( __FILE__, 'myplugin' ); > > If we use either of these methods, there will be no way to retrieve > the > normal plugin name that you mention here: It can with registration, we just need to rework the function a bit (second parameter or whatever). As for plugin_basename.... We could do a one-time retrieval of its name using get_plugin_data. Perhaps (I was trying to avoid this, but...) storing a list of active Master plugins in the DB. Actually, we already have an array of all activated plugins. Modify it to also store the plugin name? (?) I need to think on this one. Hmmmm.... > 2) If a user tries to activate a Dependent plugin and the master is > missing >> or inactive, we need some way to tell the user "You also need >> Plugin X". >> That is, the plugin name -- not just the "id tag" discussed >> earlier. Maybe >> sub plugins can define their own custom error message for this? > > Error messages should be standard. Yeah, you're right. Still, if we solve the above, we solve this too. :) Overall, I think the hardest part of all this (by far) will be tracking versions, since we basically need to make that comparison on *every single run*. I'm pretty sure we don't want to run get_plugin_data() for every plugin on every run of WordPress, but I'm not sure how else to do it.... This is definitely a puzzle. The fact that plugins can change without firing activate/deactivate hooks (or "upgrade" hooks, or whatever) complicates this in a way that WordPress has never had to even *think* about unless you're on the Manage Plugins page. Stephen P.S. -- no rush to respond for my sake -- I won't see any of this for the rest of the day. -- Stephen Rider http://striderweb.com/ _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Austin Matzko
::
Rate this Message:
On Thu, Jun 11, 2009 at 11:43 AM, Stephen
Rider<wp-hackers@...> wrote: > Something you might try is make the plugin do nothing but hook a function to > run at plugins_loaded. Then in that function you check that the "master" > plugin is running, and if it is, load the dependent stuff. Instead of using "plugins_loaded" (or some new action hook or function), why not attach a callback to a custom action hook of the parent? So for example if "My Child Plugin" is dependent on "My Parent Plugin," then fire the "my_parent_plugin_initialized" action when "Parent Plugin" has loaded. Then "My Child Plugin" can attach its initialization method to the "my_parent_plugin_initialized" hook. If the parent has initialized, it does too; otherwise, it doesn't. Such a custom action hook would let you toggle "My Child Plugin" object properties, so that you could print error messages in the case that someone activates "My Child Plugin" without a "My Parent Plugin," or when "My Parent Plugin" is out-of-date, etc. No new core functionality necessary. _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
Regarding the identifier:
I think it's best to use the plugin basename (i.e: 'bb-press/bb-loader.php') because: - it doesn't require any work on the master plugin side - doesn't require loading the master plugin first Considering "sub-plugins" and providing a nice plugin name, I think this is what a call to register_dependecy() would look like: // my_dependent_plugin.php: register_dependency(__FILE__, array( 'bb-press/bb-loader.php' => array('name' => 'BuddyPress', 'min-ver' => '1.0', 'master' => 'true'), 'plugin-framework.php' => array('name' => 'WP Plugin Framework', 'min-ver' => '2.1') ); As for plugin versions, I think we should store them in the active plugin list. Then when we check dependencies, we would have them handy. -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
On Fri, Jun 12, 2009 at 6:12 PM, Austin Matzko <if.website@...> wrote:
> Instead of using "plugins_loaded" (or some new action hook or > function), why not attach a callback to a custom action hook of the > parent? > That would be very nice, but what about register_activation_hook() and the rest? -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Austin Matzko
::
Rate this Message:
On Fri, Jun 12, 2009 at 10:16 AM, scribu<scribu@...> wrote:
> On Fri, Jun 12, 2009 at 6:12 PM, Austin Matzko <if.website@...> wrote: > >> Instead of using "plugins_loaded" (or some new action hook or >> function), why not attach a callback to a custom action hook of the >> parent? >> > > That would be very nice, but what about register_activation_hook() and the > rest? Here's what you could do in the child plugin: On the standard activation hook: Set the child plugin's object property $is_being_activated to true. On the "my_parent_plugin_initialized" hook: If $is_being_activated is true, do the activation stuff. _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
Yes, that might work.
Another issue: what if the parent plugin is called Z and the child plugin is called A? The child plugin hooks would never fire. -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
|
|
|
Re: Plugin dependency checking
by Austin Matzko
::
Rate this Message:
On Fri, Jun 12, 2009 at 11:07 AM, scribu<scribu@...> wrote:
> Another issue: what if the parent plugin is called Z and the child plugin is > called A? The child plugin hooks would never fire. By "called Z" and "called A", I'm guessing that you're asking what would happen if the child plugin's file is included before the parent's file? In general, good WordPress plugin practice does not initialize the plugin when its files are first included, and that would be particularly true for a plugin that's consciously a "framework" or "parent" plugin. Any other behavior can't really expect core WP support, anyways. So as long as the parent plugin's initialization event hook doesn't fire until all plugins are loaded, it's not an issue when particular files are loaded. _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by scribu
::
Rate this Message:
On Fri, Jun 12, 2009 at 7:43 PM, Austin Matzko <if.website@...> wrote:
> By "called Z" and "called A", I'm guessing that you're asking what > would happen if the child plugin's file is included before the > parent's file? > > In general, good WordPress plugin practice does not initialize the > plugin when its files are first included, and that would be > particularly true for a plugin that's consciously a "framework" or > "parent" plugin. Any other behavior can't really expect core WP > support, anyways. > > So as long as the parent plugin's initialization event hook doesn't > fire until all plugins are loaded, it's not an issue when particular > files are loaded. Ok, thanks for the pointers. I'll see if I can manage to pull off the activation hook workaround without modifying the active_plugins list. -- http://scribu.net _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Stephen Rider
::
Rate this Message:
> On Fri, Jun 12, 2009 at 11:07 AM, scribu<scribu@...> wrote:
>> Another issue: what if the parent plugin is called Z and the child >> plugin is >> called A? The child plugin hooks would never fire. > > By "called Z" and "called A", I'm guessing that you're asking what > would happen if the child plugin's file is included before the > parent's file? > > In general, good WordPress plugin practice does not initialize the > plugin when its files are first included, and that would be > particularly true for a plugin that's consciously a "framework" or > "parent" plugin. Any other behavior can't really expect core WP > support, anyways. > > So as long as the parent plugin's initialization event hook doesn't > fire until all plugins are loaded, it's not an issue when particular > files are loaded. There are some problems here, due to a bug in WordPress (At least I think it's a bug -- I've yet to hear a good explanation). The earliest hook you can use after plugins load is "plugins_loaded". Unfortunately, the plugins_loaded hook is NOT the first thing that happens after plugins are loaded. First pluggable.php is called, then some caching stuff happens. So if your plugin wants to replace any of the pluggable.php functions, it MUST do so immediately -- it can't run later on a do_action. A second comment though -- your sugegstion regarding "is_being_activated" helped me out on something else I've been working on (Strider Core framework). Thanks! ;) Stephen _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
|
|
Re: Plugin dependency checking
by Austin Matzko
::
Rate this Message:
On Fri, Jun 12, 2009 at 5:28 PM, <wp-hackers@...> wrote:
> The earliest hook you can use after plugins load is "plugins_loaded". > Unfortunately, the plugins_loaded hook is NOT the first thing that happens > after plugins are loaded. First pluggable.php is called, then some > caching stuff happens. > > So if your plugin wants to replace any of the pluggable.php functions, it > MUST do so immediately -- it can't run later on a do_action. I'm not sure why "plugins_loaded" is called at that point, but I think that's a separate issue from having dependent plugins. You can define a pluggable function when the plugin is loaded, without having to initialize the plugin itself. If it's a matter of wanting the child plugins to be able to redefine the pluggable function, you could let the parent plugin define the pluggable function as a wrapper of a parent plugin's factory method, which would then open up the possibility of child plugins re-defining the behavior of the pluggable function. _______________________________________________ wp-hackers mailing list wp-hackers@... http://lists.automattic.com/mailman/listinfo/wp-hackers |
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
