[wp-hackers] Database Maintenance and Canonical Plug-ins

[Mike Schinkel]

On Jun 18, 2010, at 12:42 AM, Andrew Nacin wrote:
>> 1)  Track what options and tables are created by plug-ins on installation.
>> If the plug-ins are deleted, start a timer (maybe 1 month, but
>> configurable) and remove these deprecated values after they've aged
>> out. This would catch plug-ins with authors who fail to build in clean
>> uninstall functions.  I've seen far too many (and been guilty of it myself)
>> lazy systems that set up huge data structures and abandon them on uninstall.
> 
> When I'm asked to review or test a plugin, or inspect it for suitability,
> any plugin that leaves a mess behind will get very low marks. Unfortunately,
> it'd be quite difficult to determine which options and tables came from
> where. The only true solution here is to educate plugin developers to use
> deactivation and uninstall hooks properly -- "Leave No Trace" is an
> excellent mentality of any plugin or feature -- and do what it can to limit
> the number of options and tables needed.


Something to consider: if WordPress.org/extend were evolved to have some new mechanisms it's possible that people in the community could augment plugins, i.e. maybe there's a plugin that is otherwise great with many users but maybe it doesn't clean up after itself. If there was a way to allow community members to associate plugins as options to an existing plugin maybe the community to solve some of these issues?  

On Jun 18, 2010, at 12:42 AM, Andrew Nacin wrote:
> On Fri, Jun 18, 2010 at 12:38 AM, Otto <otto at ottodestruct.com> wrote:
> 
>> Thought: Perhaps we can check for uninstall code and flag plugins as
>> being known to be uninstallable? Just an idea...
> 
> Absolutely in support of that, both in the repo and in core.

It would be nice if we could extrapolate on that idea and go beyond uninstall to include other attributes that can be derived from automated inspection of code, i.e. "has shortcodes", "has custom post types", "has taxonomies", etc.?  It would be really nice if we could drill down to find, for example, all the plugns that offer custom post types.  

Again, something to consider (and it sounds like post 3.0 is exactly the right time to consider such things?)

-Mike