not sure about this since i'm not familiar with how DBs work, but garbage in the database as a result of removed plugins, options, etc. has always bothered me
i'm thinking like auto-cleanup, compacting and removing dead options
How would the code know which options are dead, and how would it know which options belonged to which plugin? I think if this was feasible with the current core/plugin architecture it would have been done already.
i'm not a db wiz so i can't provide a technical answer, and maybe orphaned options can't be cleaned, but i'm thinking of various other things like Advanced Database Cleaner - some of this isn't doable because it would require human review, but much of it may be
As @zigpress noted, there's no way for ClassicPress to know what is a dead/orphaned option. Unfortunately, we must rely on developers to clean up after themselves...which they often don't do, under the excuse of "you just may reinstall the plugin someday."
In case you're not aware, ClassicPress does have the internal database optimization/repair tool which may help with at least some cleanup.
Optimizing the database is not a good idea, as it can easy corrupt the DB. it's best to leave the garbage (those plugins leave behind) in place.
Even a minor entry that appears harmless, if removed, can have irreversible effects. Based on my own experience and client experience, I would not recommend this.
If CP already has this tool built in, then it is already well thought out and I think would be sufficient.
This is something I have been thinking about today.
I need to write down the logic I have in mind in order to design the blueprint.
We need a stand-alone table that logs
These data should be at avail in a unique subpage, for example under Settings so users can navigate in there and check which data are considered orphaned or abandoned.
It's not an easy task to implement, it's quite challenging...but we desperately needs this.
The WP Optimize plugin provides the ability to clean out a lot of the expired or irrelevant gunk.
What do you mean, "options"? Actually, everything being asked for in this thread IS doable, first, as a plugin in ClassicPress.
I'm not the guy to program it but I've worked a lot with databases, primarily mysql. Everytime a plugin is installed or uninstalled or "options" are modified -- or deleted, the database tables themselves are WRITTEN into by standard sql queries. Depending on the change made in the Admin panel different queries are employed to update particular values in dedicated fields in dedicated tables.
Routines could be written when such a plugin (as discussed in this thread) is activated to create a new table that tracks the time when certain queries are initiated as the Administrator "adds options, or activates or deactivates plugins, etc.
Internally, also, mysql triggers could set off a series of queries everytime there is a change made to any of the tables and the query results could be saved in this auxiliary table or tables created by this enhanced, reader-friendly LOG plugin.
Then the data is called up in another view in the ClassicPress Admin dashboard and is seachable for different purposes with export custom searches highlighted.
ClassicPress does not have to "know" anything on its own. Anything the Admin does that involves clicking here or there to Save a setting immediately makes changes in the database that mysql already "knows about" and can be scripted to do things all on its own in the mysql server that hosts your ClassicPress tables.