5 ms·
Ask HN: Dealing with WordPress wp_options table
The WordPress wp_options table can quickly get filled with a copious number of rows causing page load time to increase and server/db load to increase.
There are several plugins for clearing the entire wp_options table and generally clear all of the posts, pages, comments, etc and return your installation to a vanilla WordPress install; however, I'm looking for a way to remove only the rows in wp_options that are not used anymore.
For example: removing old theme data stored in wp_options, plugin data/configurations, etc.
Does anyone have any tips for even identifying which data can be removed?
- cjmosure 11y agoI'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.