-
Notifications
You must be signed in to change notification settings - Fork 879
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin invalidates entire cache with (W3 Total Cache) #18585
Comments
Any news? |
@iamazik Any updates on this issue? |
Apologize for the delay in getting back to you. Can you please confirm how you validated the cache after saving your changes on a post that all the caches were cleared? I want to ensure that I follow the same steps you did to reproduce the issue. On the other hand, I found the relevant function
Lastly, when looking into the W3 Total Cache plugin's Luckily, an additional function is available |
Yes I can confirm that the whole cache gets invalidated if we change the SEO-Settings (YOAST Metabox) of a single product. If we just change the content or for example the price, only that specific post/products gets invalidated. |
I am confused. The entire cache becomes invalidated to ensure that we both are on the same page when changing settings from the Yoast SEO global settings page (on the left navigation bar on the dashboard). When changing the content or price of a page or product, only that specific page/product cache becomes invalidated. Did I get that right? If so, what's the issue then? |
No, not at all 😊 If you are on a single product/post in WooCommerce (/wp-admin/post.php?post=1234&action=edit) and editing the title or the content, everything is fine and just the post with the ID 1234 is invalidated but if you're editing some data in the MetaBox "Yoast SEO Premium" for this specific product with ID 1234 the cache for all other products and categories gets invalidated as well. Do you understand what I mean? |
Thanks for explaining everything @E1NSER. In that case, can you please clarify how did you verify the cache status and whether the entire site cache was invalidated so that I can follow the same steps to reproduce the issue? |
We're using a custom bash script to call every product/post url from a text file with cURL if the request takes longer than a few milliseconds the requested URL is not served from cache. We do this every 15 minutes to ensure that every url is in cache. POC:
This method is much faster than the primer which comes directly via "W3 Total Cache" and works independently of the cache plugin used at a specific website. |
Thanks for clarifying your test method. I tested the issue on our end using a typical method by revisiting pages while on incognito mode in the browser and could not reproduce the issue.
If you use the same method that I used, are you still able to reproduce the issue? |
It only happens if you change data in the YOAST Metabox like the seo title (Appearance in Google) not if just change the content or the title of the product in WooCommerce. If you like I could try to do a screen record to show you what I mean and the further process where you can see what happens afterwards. |
That's right. I indeed changed the title using the Yoast SEO meta box but forgot to mention it in the last comment. |
Just to be sure, you are also using the premium version of YOAST with the WooCommerce Extension? |
No, I haven't used WooCommerce, nor WooCommerce SEO. It was a fresh WordPress installation with W3 Total Cache and Yoast SEO on it. |
@iamazik Thank you for the link to the related topic. We will test this out in combination with "w3 total cache". Do you have the possibility to check our topic in combination with the following Plugins?
|
We have tested it. It is not the same problem. |
Wired issue but not related to this problem. |
@iamazik do you have any news? |
Unfortunately, I am struggling to reproduce the issue on our end. I have used Yoast SEO, Yoast SEO Premium, Yoast WooCommerce SEO, and WooCommerce (the latest version of everything) and still couldn't reproduce the issue. Once I activated W3 Total Cache, I enabled the Yoast SEO extension from the W3 Total Cache Extensions page, updated a post, checked a page, and can confirm the relevant page was still loading from the Disk cache (based on the output shown in the page source code.) If any of you knows a better way to reproduce the issue, I am also open to that. |
I too noticed my full cache getting cleared. But not in a predictable manner. And I suspect this issue is very old, but it's hard to notice unless you have strict checking going on. Background: I added a custom piece of code to w3tc's PgCache_Flush.php file. In public function flush() to be precise. Et voila, when I receive the notification that my cache is not warm I see in my logging file the following:
Now how to reproduce. Sadly I do not know. There is at least one scenario which sometimes triggers this, which is just logging into the backend. And not doing anything else. But it cannot be predicted if a login will trigger this scenario. |
Hi, are there any updates on this? I think, I've same issue. W3TC offers a "page cache purge log", I can see entries like this triggered by cron job:
Why is cache flush called for option updates? Currently my only workaround is to not change anything in seo menu (also not open it!) and disable cron indexing: |
Hello all, I monitored the cache logs and i see that Yoast init a flush_all on the cache, each time we click on a Yoast menu or when a Yoast cron is started. Please advice the cache logs
|
Hi @mctwistyup Thanks for sharing the cache log. We're now looking into this issue with our development team and will keep you posted. |
Hopefully there will be a solution in the near future. We always have to implement our workaround after updating the plugin. |
Please give us a description of what happened.
As soon as a post is saved or updated, the complete cache is invalidated in connection with the plugin "W3 Total Cache".
wordpress-seo/inc/class-wpseo-utils.php
Lines 431 to 443 in 8c16039
Please describe what you expected to happen and why.
Only the cache of the post that is currently being edited should be invalidated.
How can we reproduce this behavior?
Used versions
The text was updated successfully, but these errors were encountered: