5 ms·
I've had to do this a couple of times with some sites having 10s of thousands of records in their wp_options. Most records are prefixed with a plug-in name, you
by cjmosure 11y ago
I've had to do this a couple of times with some sites having 10s of thousands of records in their wp_options. Most records are prefixed with a plug-in name, you can just search %pluginname_% and in my experience it's only a handful of plugins that write such a volume of records to wp_options.
- gburt 11y agoThis 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.