[wp-hackers] plugin frameworks...

[Stephen Rider]

On Jan 24, 2010, at 4:56 AM, Davit Barbakadze wrote:

> I like your versioning idea, never thought about it. Could be really
> handy. But why such complex approach?

I would like to make it as simple as possible -- that's what I came up with.  Basically, the way WP plugins work, it *must* load each plugin -- so I set it up so that loading simply checks for each framework version, and then after all plugins are loaded, it loads the framework with the highest version, then the "meat" of each actual plugin.

So, yeah, it seems a bit complex, but basically:
  1) load each plugin, record the framework version numbers (but do nothing else yet -- basically just loading a "bootstrap" file for each of those plugins)
  2) wait for plugins_loaded, find the highest version of the framework, load that copy of the framework
  3) load the "main" file for each plugin using the framework

If you have suggestions for simplifying the code that does that, I'm open to them.  ;-)

> What will happen if user will
> deactivate plugin with newest Strider version, the whole thing will
> failback to old one again, right?

The Strider Core that is the highest version in any *activated* plugin will run.  So yes, deactivate a plugin with a high version may cause a lower version to run from a still active plugin.

> Why not to place Strider files right
> in wp-plugins/ folder (without plugin meta info) and just include them
> once from there? I think that's what I will do in the end. Any bad
> sides to this?

I very much like the idea of plugins being completely self-contained.  No bad sides to putting it separate in the plugins folder, except that a user might forget to update the framework when updating a plugin.  Other than that, I think the same issues arise with that as with using my method -- that is a newer version of the framework may be running with an older plugin, and thus you have to be careful of backward compatibility.

My system is actually a bit more flexible in that last regard, because if a new version really must break backward compatibility, you can just alter the framework's class (e.g. strider_core_2) and you're still good to go.

Stephen

> On Sun, Jan 24, 2010 at 9:32 AM, Stephen Rider
> <wp-hackers at striderweb.com> wrote:
>> 
>> Mine's not very polished -- the others you've been shown probably do things differently, but it may be worth a look:
>> 
>> Strider Core:
>> <http://code.google.com/p/strider-core/>