wordpress-seo
wordpress-seo copied to clipboard
Yoast
WP Super Cache cache directory gets entirely wiped after visiting admin page
- [x] I've read and understood the contribution guidelines.
- [x] I've searched for any related issues and avoided creating a duplicate issue.
Please give us a description of what happened
When Yoast SEO is present, the cache files from WP Super Cache get completely wiped when I log in the admin interface after ~24 hours of inactivity, even if the cache timeout is very long (several days). The entire cache directory itself (/wp-content/cache/supercache/your-domain) is deleted, along with the log file when debugging is enabled. This should definitely not happen, and it doesn't happen when Yoast is not present.
To Reproduce
Step-by-step reproduction instructions
- Install the latest WordPress
- Set up the permalink structure in Settings (for example Post name) - this is needed for WP Super Cache
- Install WP Super Cache and activate it
- Enable Caching and set the Cache Timeout to several days (for example 864000 seconds) - optional: enable logging
- Visit the homepage while logged out to generate the cache file
- Check that the cache file(s) have been created in
/wp-content/cache/supercache/your-domain/ - Wait for 24 hours
- Visit the admin dashboard
- Notice that the
/wp-content/cache/supercache/your-domain/directory is still there - Install Yoast SEO and activate it
- Go through the Yoast setup
- Clear the cache
- Visit the homepage while logged out to generate the cache file
- Check that the cache file(s) have been created in
/wp-content/cache/supercache/your-domain/ - Wait for 24 hours
- Visit the admin dashboard
- Notice that the entire
/wp-content/cache/supercache/your-domain/directory is gone
I've been able to reproduce the problem on my local sites (MAMP PRO) and on three separate live environments on the same shared hosting space.
Expected results
- The
/wp-content/cache/supercache/your-domain/directory and its content should always be preserved. Only the expired cache files should be removed when wp-cron runs.
Actual results
- The
/wp-content/cache/supercache/your-domain/directory is deleted, as well as the log file if logging is enabled in WP Super Cache.
Logs
This is a log of what happens when we visit the admin dashboard with Yoast enabled (step 16 above):
12:09:25 48168 /wp-admin/ wp_cache_get_cookies_values: Login/postpass cookie detected 12:09:25 48168 /wp-admin/ wp_cache_get_cookies_values: return: [redacted] 12:09:25 48168 /wp-admin/ In WP Cache Phase 2 12:09:25 48168 /wp-admin/ Setting up WordPress actions 12:09:25 48168 /wp-admin/ Not caching wp-admin requests. 12:09:26 48168 /wp-admin/ Clearing all cached files in wp_cache_clear_cache() 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/supercache/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: did not delete file: /wp-vanilla/wp-content/cache/supercache/index.html 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/supercache/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/.DS_Store 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/.DS_Store 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/index-https.html 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/index-https.html.gz 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/page-d-exemple/index-https.html 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/page-d-exemple/index-https.html.gz 12:09:26 48168 /wp-admin/ gc: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla/page-d-exemple, forced delete 12:09:26 48168 /wp-admin/ gc: deleted /wp-vanilla/wp-content/cache/supercache/wp-vanilla, forced delete 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/blogs/index.html 12:09:26 48168 /wp-admin/ gc: deleted /wp-vanilla/wp-content/cache/blogs, forced delete 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: did not delete file: /wp-vanilla/wp-content/cache/index.html 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/.DS_Store 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/supercache/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: did not delete file: /wp-vanilla/wp-content/cache/supercache/index.html 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/supercache/index.html as it's protected. 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/supercache as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/view_1ce35d849987f7ad53fb848ca474c38f.php 12:09:26 48168 /wp-admin/ prune_super_cache: deleted /wp-vanilla/wp-content/cache/1ce35d849987f7ad53fb848ca474c38f.php
At this point, the log file gets deleted and immediately recreated, and continues:
12:09:26 48168 /wp-admin/ wp_cache_replace_line: setting not changed - $wp_cache_debug_log = '1ce35d849987f7ad53fb848ca474c38f.php'; 12:09:26 48168 /wp-admin/ wp_cache_replace_line: setting not changed - $wp_cache_debug_username = '[redacted]'; 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/meta/index.html as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: did not delete file: /wp-vanilla/wp-content/cache/meta/index.html 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/meta/index.html as it's protected. 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/meta as it's protected. 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/.htaccess as it's protected. 12:09:26 48168 /wp-admin/ prune_super_cache: did not delete file: /wp-vanilla/wp-content/cache/.htaccess 12:09:26 48168 /wp-admin/ gc: could not delete /wp-vanilla/wp-content/cache/.htaccess as it's protected. 12:09:26 48355 /wp-json/wp/v2/ wpsc_get_auth_cookies: cookies detected: wordpress_logged_in_[redacted] 12:09:26 48355 /wp-json/wp/v2/ wpsc_is_caching_user_disabled: true because logged in 12:09:26 48355 /wp-json/wp/v2/ Caching disabled for logged in users on settings page. 12:09:26 48355 /wp-json/wp/v2/ wp_cache_get_cookies_values: Login/postpass cookie detected 12:09:26 48355 /wp-json/wp/v2/ wp_cache_get_cookies_values: return: [redacted] 12:09:26 48355 /wp-json/wp/v2/ In WP Cache Phase 2 12:09:26 48355 /wp-json/wp/v2/ Setting up WordPress actions 12:09:26 48355 /wp-json/wp/v2/ Created output buffer 12:09:26 48355 /wp-json/wp/v2/ wp_cache_get_cookies_values: cached: [redacted] 12:09:27 48355 /wp-json/wp/v2/ REST API detected. Caching disabled. 12:09:27 48355 /wp-json/wp/v2/ wp_cache_maybe_dynamic: returned $buffer 12:10:27 48141 /wp-admin/admin-ajax.php wp_cache_get_cookies_values: Login/postpass cookie detected 12:10:27 48141 /wp-admin/admin-ajax.php wp_cache_get_cookies_values: return: [redacted] 12:10:27 48141 /wp-admin/admin-ajax.php In WP Cache Phase 2 12:10:27 48141 /wp-admin/admin-ajax.php Setting up WordPress actions 12:10:27 48141 /wp-admin/admin-ajax.php Not caching wp-admin requests.
One possible culprit
I've also been able in several occasions to get the cache to be wiped in the same fashion by visiting Yoast SEO > Tools in the admin area, and by getting the SEO data optimization to run after installing Yoast. So I suspect this may be related to the SEO data optimization feature.
Related, but different, issues
https://wordpress.org/support/topic/wp-super-cache-and-yoast-seo-incompatible/ https://wordpress.org/support/topic/wp-yoast-seo-causing-wp-super-cache-cache-clearing-abnormaly/ https://wordpress.org/support/topic/yoast-updates-cause-wp-super-cache-purge/
Used versions
- WordPress version: 6.2.2
- Yoast SEO version: 20.12 (also tested with the previous version)
- WP Super Cache: 1.9.4 (also tested with version 10.10.0-beta)
Hey @A-Printer, Thank you for reaching out. This needs some investigation, so please allow us to check a few things. I did find a similar (open) issue with another caching plugin (W3TC) where we haven't been able to reproduce it - see https://github.com/Yoast/wordpress-seo/issues/18585
Hi Jeroen,
Thanks. I did see that issue while investigating my problem. In my case though, I don't even need to edit anything, just visiting the admin dashboard is sufficient to nuke the cache. But it doesn't happen every time, only after some time of inactivity, which makes reproducing and testing cumbersome as you have to wait. I've spent weeks to narrow it down to Yoast SEO since I'm using several plugins. But now I know that just having WP Super Cache and Yoast SEO triggers this behaviour, and that SEO data optimization is a possible culprit. Is there a way to trigger it manually?
On my live sites, just visiting the admin for any reason resets the cache for the whole site once a day, which is frustrating and hurts Web Vitals.
One thing I didn't mention: on my test and live environments, I'm using PHP 8.x since PHP 7.4 reached its EOL.
I can confirm that the problem persists with Yoast SEO 20.13 and WP Super Cache 1.10.0 on WordPress 6.3.
I just had the cache deleted by visiting the Yoast SEO > Tools admin page.
I have the same problem. When i logged cached files of various plugins are removed from the folder called «wp-content/cache». Profiler XHProf is enabled on my server function. I can drop access so you can see the call sequence or call graph.
It looks like our plugin uses the following hooks in several places (aside from activation and deactivation of the plugin, which should not happen often):
add_action( 'update_option_' . $this->option_name, [ 'WPSEO_Utils', 'clear_cache' ] );
add_action( 'add_option_' . $this->option_name, [ 'WPSEO_Utils', 'clear_cache' ] );
This clear_cache() method is set to call both wp_cache_clear_cache() and w3tc_objectcache_flush() if they exist.
wp_cache_clear_cache() is WP Super Cache's method to clear its cache folder.
So this means that these caches get flushed on any option additions or updates in our plugin. And from https://github.com/Yoast/wordpress-seo/pull/17363 , we can already tell that this happens too much.
As a workaround, it might be possible to remove this action after the plugins have initialized, by calling remove action() . However, I have not tested this in any way, so I'm not a 100% sure.
I'm pretty sure this is the same: https://github.com/Yoast/wordpress-seo/issues/18585#issuecomment-1737347746 with some backtraces.
Is there a possible workaround for this at the moment?
Apparently not. At least I temporarily moved to another plugin. My website has 80,000+ pages. Deleting the cache several times a day and crawling by bots caused a wild load on the server, so the hosting threatened to transfer to a corporate plan of several thousand dollars.
@einleid2506, sorry to hear that. This has a lot of impact on my sites as well.
I'm testing a workaround at the moment by setting the 'Cache-time-out' to 0, which will disable the 'garbage collection'. Aka; disabling the deletion of the folder. Not sure if this works. Of course this is not ideal, but my sites are not constantly slowing down and requesting a lot of resources.
Why not just add an option to Yoast to enable/disable its interfacing with any caching-plugins all together?
On 16 Oct 2023, at 16:32, Paul Wijnberg @.***> wrote:
@einleid2506, sorry to hear that. This has a lot of impact on my sites as well.
I'm testing a workaround at the moment by setting the 'Cache-time-out' to 0, which will disable the 'garbage collection'. Aka; disabling the deletion of the folder. Not sure if this works. Of course this is not ideal, but my sites are not constantly slowing down and requesting a lot of resources.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
A workaround is to comment the line that calls the function wp_cache_clear_cache() in file inc\class-wpseo-utils.php
The problem is that you have to do it everytime you update the plugin
/** * Clears the WP or W3TC cache depending on which is used. * * @since 1.8.0 */ public static function clear_cache() { if ( function_exists( 'w3tc_pgcache_flush' ) ) { w3tc_pgcache_flush(); } elseif ( function_exists( 'wp_cache_clear_cache' ) ) { //wp_cache_clear_cache(); } }
Thank you. I don't want to sound rude, but this is also a 'W3 Total Cache' problem by viewing that code snippet....?
Thank you. I don't want to sound rude, but this is also a 'W3 Total Cache' problem by viewing that code snippet....?
Yep (https://github.com/Yoast/wordpress-seo/issues/20554#issuecomment-1737357065 and https://github.com/Yoast/wordpress-seo/issues/18585#issuecomment-1737347746)
Thank you. I don't want to sound rude, but this is also a 'W3 Total Cache' problem by viewing that code snippet....?
And not only him. I deactivated Cache plugin. But Yoast keeps deleting ALL cache from the folder of the same name /cache/. For example, cache from plugins: «Autoptimize», «Get Use APIs — JSON Content Importer», etc.
Just discovered this is affecting me too.
Why not ditching WPSEO_Utils::clear_cache and all the associated calls to it?
I think it's the user responsibility to take care of their eventual cache.
Right now, it obviously causes unexpected issues (cache being cleared just by visiting admin), it has been reported as problematic multiple times since a long time, it supports only two cache plugins, and it moreover operates a bit sneakily without any mentions of that mechanism to users.
Like @StSaens suggested, informing and offering a way to disable is a minimum, but that would also require to prevent these unexpected cache clears.
Anyway, I would totally prefer that Yoast stays away from any third party cache system, like probably a vast majority of Yoast users, especially if it's buggy (but I might be wrong :))
Does this issue have any priority? Imagine running a webshop in for example Woocommerce. The admin is viewed multiple times per day for checking and managing orders. Each time the cache is whiped out and has to be rebuild again. Caching plug-ins are especially useful and needed for hightraffic webshops. I think it's a very common senario that this plug-in is installed with the popular caching plug-ins like WP Super Cache.
A workaround is to comment the line that calls the function wp_cache_clear_cache() in file inc\class-wpseo-utils.php
The problem is that you have to do it everytime you update the plugin
/** * Clears the WP or W3TC cache depending on which is used. * * @since 1.8.0 */ public static function clear_cache() { if ( function_exists( 'w3tc_pgcache_flush' ) ) { w3tc_pgcache_flush(); } elseif ( function_exists( 'wp_cache_clear_cache' ) ) { //wp_cache_clear_cache(); } }
It would be great if the only need to make changes when updating the plugin was. In fact, commenting out this line will break your site if you use caching and site optimization plugins or critical style embedding services. There was no time to figure out the specific reason, but after commenting on the line, the visual design of the pages broke. Therefore, I had to uncomment the lines. Whether this affects all sites is a big question. In my example it does.
A workaround is to comment the line that calls the function wp_cache_clear_cache() in file inc\class-wpseo-utils.php The problem is that you have to do it everytime you update the plugin
/** * Clears the WP or W3TC cache depending on which is used. * * @since 1.8.0 */ public static function clear_cache() { if ( function_exists( 'w3tc_pgcache_flush' ) ) { w3tc_pgcache_flush(); } elseif ( function_exists( 'wp_cache_clear_cache' ) ) { //wp_cache_clear_cache(); } }It would be great if the only need to make changes when updating the plugin was. In fact, commenting out this line will break your site if you use caching and site optimization plugins or critical style embedding services. There was no time to figure out the specific reason, but after commenting on the line, the visual design of the pages broke. Therefore, I had to uncomment the lines. Whether this affects all sites is a big question. In my example it does.
This doesn't make sense to me. Commenting out this line just prevent yoast from clearing the cache, something that IMO is not its responsibility so it shouldn't affect any other plugins or functionalities of the web site.
This issue needs fixing asap but work around to disable it as follows.
I couldn't get it to unhook with remove_action and its not important to our site so I just unset the global filter for it. Someone should be able to work out what I'm missing on the remove_action lines to do it properly
add_action( 'admin_init', function() {
unset($GLOBALS['wp_filter']['update_option_wpseo']);
//None of these works
remove_action('update_option_wpseo', 'WPSEO_Options::clear_cache', 10);
remove_action('update_option_wpseo', [ 'WPSEO_Options', 'clear_cache' ], 10);
remove_action('update_option_wpseo', [ WPSEO_Options:class, 'clear_cache' ], 10);
}, -1);
Please inform the customer of conversation # 1106823 when this conversation has been closed.
