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

[Andrew Nacin]

>
> 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.

2) If a post hasn't been revised for a significant period of time (again,
> configurable) its revision history will either be deleted or archived (moved
> out of the database and into a static text file . maybe XML?).


Our philosophy is plugin over core option, of course, and this seems like a
perfect candidate for a plugin.

Generally speaking, core plugins will come not only out of a need, but
proven demand. While I don't see it here, it could of course gain traction
over time.