wp_options over 100Mb of _transient_wpsso_

WPSSO uses the WP transient cache to store its meta tags and Schema markup – there are generally 1-2 transients per post and term, so there can be many transients, but they should be fairly small. You can view the number of transients used on the SSO > Dashboard page, and clear the WPSSO cache on the SSO > Tools page. You can hook the ‘wpsso_cache_expire_head_array’ filter and return 0 to disable the head meta tag cache, and ‘wpsso_cache_expire_schema_json_data’ for the Schema JSON cache. Pro version users can also fine-tune cache settings from the SSO > Advanced settings page.

js.

Was the tone of my reply aggressive? I’m surprised at the tone of your follow-up.

So when you click the “Clear All Cache” button, the counters are not returned to 0 (or near 0)?

Here is some information on how to hook filters, but if the “Clear All Cache” button is not working on your site, I’m guessing that would be the issue to focus on.

https://www.google.com/search?q=how+to+hook+a+wordpress+filter

WPSSO runs a “select” command from the database to get a list of its transients and delete them – I’m not sure why your database is not returning that list (or an incomplete list) – it’s a pretty straightforward function that hasn’t changed in a long time. You could give the https://wordpress.org/plugins/artiss-transient-cleaner/ plugin a try and see if that helps.

js.

I appreciate your feedback, and I would definitely be interested in finding the source of this issue on your site, but it would help if you could work with me – it sounds like you may have ignored my earlier suggestions.

I don’t know what the “Optimize Database after Deleting Revisions” plugin does, but considering that WPSSO does not create transients for revisions, and that WPSSO refreshes 1-2 specific transients when a post is updated (specific to that post ID), which should not create any fragmentation in the database, I’m not sure what there is to optimize (optimizing in database terms usually refers to defragmenting), unless that plugin decides to clear all transients, which could cause significant performance issues (transients a created to improve page load times by minimizing redundant code execution).

1-2 transients are created for every post ID, term ID, user ID, and archive page URL (one for meta tags, and one for Schema JSON markup). Generally, depending on the number of posts, terms, users, and archive page URLs, this would be a few thousand (depending on the number of posts / page on a site). Each transient should only be a few KB since they’re only meta tags and Schema markup.

There is one condition that could create more transients, which is for incorrectly registered custom post types, where the post ID is always 0. In that case, WPSSO must use the sharing URL to create a unique transient index ID. If the URL changes a lot, with many different URL query arguments, this can create many more transients. Their size still wouldn’t change – still a few KB, but there may be many more since WPSSO cannot use a valid post object ID.

When using the “Clear All Cache” button from the SSO > Tools page, WPSSO executes a background task to clear all its transients (as the notice would have indicated). That task would create another notice when it ends, unless there’s a significant performance issue with the database, and PHP terminated the task prematurely.

The transient cleaner plugin I mentioned earlier would clear transients in a foreground task, so you would get more immediate feedback about possible database performance issues and timeouts.

I’m happy to help figure out the issue on your site, and if you could work with me, and provide feedback on my suggestions, we could narrow down the source of this problem.

js.

It’s hard to predict all the “creative” ways some sites generate webpages, which is why the $wp_query->query values were includes in the transient array index keys, but I believe this may not be necessary for 99.99% of sites, and may create more index keys than necessary (leading to larger meta tag and Schema json transient arrays), so I’ve removed those values in the latest WPSSO Core v4.18.1-rc.1 release. You can download the latest development / trunk ZIP to give it a spin, or see the SSO > Update Manager settings page to select the development version filters (if you’re using WPSSO Core Pro).

js.

I assume you’re running WPSSO Core v4.18.1-rc.1?

js.

BTW, I see you’re using the WPSSO RRSSB add-on as well – you should install the current development version of that add-on, which has the same $wp_query->query fix as WPSSO Core.

js.