[wp-hackers] plugin frameworks...
wp-hackers at striderweb.com
Mon Jan 25 23:03:33 UTC 2010
On Jan 25, 2010, at 4:17 AM, Davit Barbakadze wrote:
> So yes, your approach could be better in some
> sense, but then I still do not see why older plugin may need a newer
> library, especially when renewing is not guaranteed. So if newer
> library let's say does a patch on some crucial vulnerability, and then
> on deactivation it will suddenly bail out to older bugged version,
> then if anything will happen through this hole, no one and especially
> user will probably never understand what had happened at all.
At worst, an old plugin will run the version of the framework include in itself. Sometimes it will run on a newer (presumably improved) version. In *no* cases will a plugin run a version of the framework *older* than the one included with itself. So as I see it... some upside and no downside.
The other way is to just take the framework and change the class name for your particular plugin, and it becomes a stand-alone use of the framework, with code exclusive to the one plugin only.
> What if framework will stay inside the plugin folder, but using a bit
> of your approach will place a notice in global space about what
> version is activated and actually from where it was loaded and then a
> plugin with newer version of framework will renew all existing
> versions of framework upon install. Damn... I think that's a bit too
> much :D
Or just put out updates for plugins when the framework is updated. ;-)
Actually, I have a concept of the framework (optionally per plugin author) adding info to the plugin's Settings page in admin, giving info and possibly global settings for the framework itself.
> I think placing framework in seperate directory accessible from all
> plugins and then holding an eye on backward compatibility can be the
> best approach.
Basically what you're probably looking at is "plugin dependencies -- in which on plugin can be made dependent on another plugin. Then the framework could be a separate plugin in its own right.
That could be done right now, in WP 2.9, if you wanted to. Just add some code to the dependent plugin saying "if framework_class doesn't exist, deactivate this".
> Would be great if wordpress had support for that! You
> can't keep renaming your classes forever, right?
The hope is that true "back breakers" don't happen very often, but if they do, hey... integers are infinite. ;-)
> Or it least it's not
> a cleanest way. It has something of the flat plugin coding, when
> functions are not encapsulated in class and just prefixed. I used to
> use it initially and always felt uncomfortable.
Agreed it sometimes feels less than elegant, but it's not too bad. The only real danger is if some author picks up the framework and makes changes, but doesn't (as required by license) change the class names.
More information about the wp-hackers