4 ms·
This is an ok angle for dealing with well-behaved (prefixed) plugins that are no longer in use. Perhaps a better solution is to write a custom implementation o
by gburt 11y ago
This is an ok angle for dealing with well-behaved (prefixed) plugins that are no longer in use.
Perhaps a better solution is to write a custom implementation of get_option (and update_option, etc. if you feel necessary) which logs uses -- run this temporarily and remove anything that hasn't been used in X days. I'd then go through and browse all the admin. pages by hand just to ensure something rare isn't missed.
In that case, "remove" should probably mean "copy to a different database" just in case it turns out it had value.
- gburt 11y agoAlso, a thought: if you have a huge amount of records in that table, they're probably transients or other cache material from a somewhat misbehaved plugin. A way to "handle" that (other than the obvious and important technique of identifying and fix whatever is creating them) is to install an in-memory caching plugin that will store transients in RAM instead of in the database.