[wp-hackers] Plugin deactivation

[Robert Deaton]

Amit, I do think that plugin authors understand this very well, but this is 
only true for filters, but what if a plugin was trying to call functions 
that your plugin needs to have defined before that plugin has been called, 
thereby creating errors and the like. I think that we don't necessarily need 
a way for plugins to load before other plugins, but how about a way for 
plugints to be specified to be loaded later? This way, plugins that have 
dependancies can take advantage of being loaded later when the independant 
plugins have already been loaded and their functions will be available. This 
way, the original plugin authors nor the independant plugin authors have to 
change the flow of their plugins to make it work.

Andy, your solution is just another way to do what I was thinking of. My 
method was telling all plugin authors to wrap everything in a function, and 
add it as add_action('init', 'their_function'); and then having my plugin 
add its action as add_action('init', 'my_function', 99999) to be sure that 
my code was executed later, but it'd be much nicer to not have to add these 
sort of things to my plugin documentation and to have to think of ways to do 
this.

On 7/4/05, Amit Gupta <amit at igeek.info> wrote:
> 
>  well, as I know of it, the application orders for the filters are there 
> for the sole purpose of specifying which plugin runs first. Like
> 
> add_filter('the_content', 'my_plugin', 1);
> 
> this will make my plugin run first, if the sequence order is not specified 
> then its defaulted to the last in the order, 10. I believe this was made so 
> that like you said, plugins that want to stop the execution of other code 
> can run first, and so on. however I don't think that this feature is used 
> optimally by plugin-authors(myself included as I had my syntax hiliting 
> plugin running at #1 in first versions, but now I've 2 filters at #3 & #4).
> 
> so IMHO, plugin authors need to understand that and use it, instead of 
> just whipping up a quick hack. for that I think that there should be a page 
> at the Codex stating the basic essential guidelines that the plugins must 
> follow. though I know it can't be controlled, but to some extent it can be 
> controlled. As wp-plugins.org <http://wp-plugins.org> is under control of 
> WP, I suggest that it should be mandatory for all plugins listed there to 
> follow the basic essential guidelines.
> 
> just my $0.02
> 
> -----
> Amit Gupta
> 
> || Canned!! -- my Atropine <http://blog.igeek.info/> || iG:Syntax Hiliter 
> v3.0<http://blog.igeek.info/still-fresh/2005/06/29/let-the-code-be-colourised/>||
> || iGEEK.INFO <http://www.igeek.info/> || Free Nokia Ringtones<http://www.igeek.info/ringtones.php>|| Online 
> Gaming @ Games Planet <http://www.igeek.info/games.php> || 
> 
> 
> 
> 
> ---------- Original Message from davebytes at comcast.net ----------
> Wouldn't it be easiest (and completely under your control) to have all the 
> sub-plugins register off a custom message/action (init_any_blah_plugins), 
> and then have the 'master' register for the plugins_loaded action, and when 
> that gets hit do_action(init_any_blah_plugins)?
> 
> I agree that some priority ordering would be nice -- i.e., CG-Referrer 
> would love to run first, as it may potentially 'bounce' access, and thus 
> would like to short-circuit other plugin code loading. Unfortunately, then 
> EVERYONE fights for who really needs to run first. ;) we might need 
> 'classes' of plugins, so that things that want to prevent other code 
> execution can run first, things that control secondary code 
> loading/execution (chaining, whatever) run second, and 'normal' plugins can 
> run third (oh, and 'late' plugins run fourth, as there's a class of things 
> that want to run after all other plugins have hooked in...). But this goes 
> both for initial loading and hooking off of plugins_loaded...
> 
> -d
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> 


-- 
--Robert Deaton
http://somethingunpredictable.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://comox.textdrive.com/pipermail/wp-hackers/attachments/20050705/63040086/attachment-0001.html