[wp-hackers] Auto Update Plugins
wp-hackers at striderweb.com
Tue Feb 17 22:36:41 GMT 2009
On Feb 17, 2009, at 4:20 PM, Jess Planck wrote:
> Now it's confirmed as a "plugin extension" and not a user upload.
> Then a proper location like even wp-content/spam-karma would be
> appropriate as well. Buddypress uses wp-content/member-themes and of
> course WPMU uses wp-content/mu-plugins.
> I thought the entire purpose of /wp-content was "site centric", but
> if a consensus appears with plugin extensions and extra non-user
> data then I wouldn't mind.
> As mentioned originally, auto-updating plugins can destroy plugin
> extensions if they reside in the /wp-content/plugins/plugin-name/
Actually, you've just made a point that pushes me more strongly toward
my original suggestion of /plugins/plugin-data/<plugin-name> rather
Different blogs may share /plugin/ directories, but are probably less
likely to share an entire /wp-content/ directory. Thus files that
directly relate to plugins are best located in the plugins directory,
FYI -- a few examples of plugins that could use this structure:
Spam Karma -- for SK plugins
Core Control -- (Dion's I think...) will eventually accept plugins.
Basically any plugin that has a modular structure.
Note again, ***none of this*** requires changes to WP core. It's more
about just setting a standard to which plugin authors can write their
plugins. Of course right now any plugin author who chooses to can set
their plugin to use /wp-content/myplugin/ or /plugins/myplugin-data/
or what have you. The point here is to simply encourage them to be
tidy and place such things in the "official" location.
Down the road, we might be able to work in a plugin hierarchy system
by which users can activate/deactivate such items via an Ajax-enhanced
Manage Plugins screen. That is, imagine the Manage Plugins screen but
some plugins have a small "open" icon that opens up a submenu of that
But that last is for down the road, I think. (focus, Steve-o, focus!)
More information about the wp-hackers