Persistent Cache

Hi @leodefaveri

Hope this message finds you well.

Thanks for the detailed information, but let me breakdown to get things clear.

Persistent Cache

This is usually known as Object Cache or Mem Caching, which is related to database caching, Hummingbird doesn’t have such a feature, since this needs to run on the server side or from a 3rd party service like Redis. Would you let us know if your site uses Object caching?

This price will only be updated to 10 dollars if that visitor reloads the page (F5).

This is a very odd behavior indeed, Hummingbird >> Caching >> Page Caching will maintain the page cached until it is clear from the WP Admin area, it does not clear by refreshing the page.

If the browser cache is 1 year old, a frequent visitor will not be able to see new assets on the website until he updates his browser

Hummingbird >> Caching >> Browser caching is for temporarily storing assets like CSS, JavaScript, and images on the visitor’s side, but not the content, if you update a price it should reflect as it is not part of the assets.

The HB cache is sensational, the fastest in my opinion, but this problem prevents it from being used in e-commerce.

Thank you for the feedback, are you using the WooCommerce plugin for e-commerce?

What you described sounds like Object/Mem caching, maybe the server does have Static Server Caching, are you using a 3rd party caching service like Cloudflare?

Also, some theme builders might create their caching, which Hummingbird will not be able to re-generate.

Let us know your comments.

Best regards,
Laura

Hi @wpmudevsupport3 thanks for your response.

I think you didn’t understand or I couldn’t explain it clearly. When I say persistent cache, I don’t mean the object cache, but rather that the cache remains active in the browser even after clearing.

I’m not using object caching, and even if I was, my report wouldn’t make sense. And yes, I’m using woocommerce and I don’t use Cloudflare.
There is no other caching layer, I am using a VPS server with NGINX. Do the test yourself as I said and you will understand the problem.

Understand one thing, the problem only occurs with your plugin, any other one I tested (there were several) works correctly.
I can simply disable your plugin and the browser will continue to show the cached version.

Hi @leodefaveri ,

I tested in my system in the NGINX server but I’m not able to replicate such a behaviour when updating the price of an already cached product page.

Could we know if the issue is only specific when using WooCommerce? Or do you face issues in general with updating random cached posts/pages?

Could you also check whether you have “Clear full cache when post/page is updated” option enabled under Hummingbird > Caching > Page Caching? If not, please check how it behaves with the above setting enabled.

Possible to check whether you face such behaviour if you temporarily switch to a default WP theme and will all the plugins be disabled except Hummingbird?

If the issue is still the same even after the above then possible to provide a URL to the page on how the cart loads so that we could have a better idea to see what might be causing such behaviour?

Looking forward to your response.

Kind Regards,

Nithin

Hello @wpmudevsupport11

Thanks for the support. Well, to make it easier to understand, I made a video showing what happens. It is at this link below.

https://go.screenpal.com/watch/cZ66l9VWZ6d

Note that as long as I don’t update the browser, the price doesn’t change even after clearing the cache. In the video I didn’t close the browser, but if I close it and open it again the next day (example), the price will be there unchanged (9.50) until I update the browser or the browser cache expires.

When clicking on clear all cache, the client browser needs to understand that there has been a change and when entering the product page again, the price needs to be updated immediately for that user. It is important to say that if a new user accesses the page, it will open with the updated price and generate the new cache, but the user who is already on the page (or another page) in with the old price will continue to see the old price. So I’m absolutely sure that the problem refers to the browser’s cache, which needs to be forced to update after clearing the cache, and so when you leave the page and return, the price should already appear updated, as well as on the product showcase page (shop). This does not only occur on woocommerce pages, any changes to any part of the site remain in the same condition.

To complement the information, I have already done the test in an anonymous tab, in clean and different browsers too. I have done all possible tests to understand the reason for this, and I am convinced that it is the browser cache that should be updated immediately.

Hi @leodefaveri

Thank you for the video.

I can see the error there.

Based on your video I could see your website and noticed you are using the varnish cache as well, though the clear option is enabled in Hummingbird we still need to narrow down the problem:

– Is it the browser cache
– Is it a varnish cache
– Is it page cache

We can test each of them:

– Is it possible to temporarily disable the varnish and see if the problem is gone?

If not,

– Access the wp-content > wphb-cache folder, are the files gone when you flush all caches via the Hummingbird interface? ( We are testing the page cache here )

– If you select the “disable cache” https://monosnap.com/file/fGHT8YbSSASFrUZGvJlit4w1c0RCOL keep the browser console enabled and navigate between the pages, is it gone?

Let us know the tests results.
Best Regards
Patrick Freitas

Hello @wpmudevsupport12, answering your questions

“– Is it possible to temporarily disable the varnish and see if the problem is gone?”

At the time of testing when I made the video, varnish was disabled. If you accessed the url and found it activated, it is because this site is not in production, just in testing. It is currently deactivated.

“– Access the wp-content > wphb-cache folder, are the files gone when you flush all caches via the Hummingbird interface? ( We are testing the page cache here )”

Even after clearing the cache, two files remain in the folder, index.html and wphb-cache.php

– If you select the “disable cache”?https://monosnap.com/file/fGHT8YbSSASFrUZGvJlit4w1c0RCOL?keep the browser console enabled and navigate between the pages, is it gone?

Sure. If I disable the browser cache, the price changes immediately. That’s why I said before that the problem is specifically the browser’s cache, which doesn’t seem to understand that it needs to be renewed after cleaning. See the video: https://reccloud.com/pt/u/vc941yy

Thank you for your support!

Hi @leodefaveri

I took a closer look at this conversation and details and I think we should narrow this down to Firefox browser, which is your primary browser based on the video. Please correct me if I’m wrong.

Please note all of the tests I have made were done in incognito mode in Firefox, Chrome, and Safari. My separate Firefox browser (not incognito mode) window was the one where I was logged in to WP admin.

I made a test with Static Server Cache and Object Cache disabled all the time.
I have tested Hummingbird, W3 Total Cache, and WP Fastest Cache plugins and I had the same results all the time.

With all of those 3 plugins Chrome and Safari in incognito mode acted like you want them to act, or maybe we should say: they acted like they should -> as soon I move around other items from the top menu and then get back to the shop page and product page the price is updated (before navigating item from the menu I clear the cache from that specific browser).

But only Firefox, again using those 3 plugins separately, is not able to update that price while you move around items from the menu. So this makes me think in the first place that this is related to the Firefox update from a couple of years where there is a little bit harder browser cache. I think this was around 2019 but cannot recall in which version of Firefox this was changed.

So the questions is now:

I did the same test with most other known caching plugins and none of them have this problem

Can you replicate this also In Safari, Chrome, or any other browser that is not Firefox? I was not able on my side, which led to Firefox settings and that update.

Kind Regards,
Kris

Hi @wpmudevsupport13 Wow! First I need to praise this answer you gave me. This shows how committed you are to the quality of your plugins. Congratulations on that.

Well, the video test was done with the Brave browser, not Firefox. But to be able to give you a correct answer, I did the test with Firefox and it also happens, but I noticed that at times the price changes on the storefront but does not change on the product or vice versa.

So I decided to do the test on the following browsers: in addition to Brave, which I mentioned, Firefox, Edge, Chrome and Opera GX. Surprisingly the only one that works perfectly is Edge. In all others the behavior is exactly the same with the exception of Firefox as mentioned above.

So if I clear the cache and open the page before it is cached, I won’t find the hummingbird-served header. From the second visit he will be there. So without closing this browser, I clear the cache, go back to the browser, go to any other page and return, it shouldn’t have this header, because I just cleared the cache and it hasn’t been formed yet. But it will be there as served (without using preload). If I keep the browser open, go to the panel and change the entire website theme, I can continue browsing the cache with the old theme normally, while I open any other browser and I will have the new theme.
So I have two browsers open with one cached and the old theme and the other with the new theme. As long as I don’t refresh the page (f5) I will be using the browser cache with everything (except dynamic pages obviously), and it is this behavior that could not occur.

I sincerely apologize if it seems like the problem is on my side, but it’s not, I’ve actually tested all the plugins you mentioned as well as others, such as Breeze, WP Rocket, WP Optimize, Super Page Cache and Powered Cache. The problem does not occur in all of them, only with HB. I could actually just ignore it and choose any other plugin, but at the same time I’m a contributor to the WordPress community and I exceptionally enjoy your excellent work, so I wanted to pass on this information. But I also don’t want to cause you and the users too much concern, as I’m sure you’ll find something in the future. As in another user’s topic that I mentioned at the beginning of the post, I also tried using plugins that prevent the browser cache, but it didn’t work for me either.

Once again, I thank you for your commitment and dedication to excellent quality support that enriches our ecosystem!

• This reply was modified 5 days, 17 hours ago by leodefaveri.

Complementing information, Edge, after some extra tests, also sometimes experiences the problem. I was curious to understand why it worked before, but it actually happens too.

View post on imgur.com

• This reply was modified 5 days, 16 hours ago by leodefaveri.

Hi @leodefaveri,

Thank you for your continued effort in testing this issue and providing feedback.

I understand your concern and have escalated this to the QA team for a thorough investigation. We will keep you updated as soon as we have more information.

Kind Regards,
Nebu John

@wpmudevsupport14 Thank you for your support and interest in understanding the problem. I’m sure they will find a solution for this and I would like you to send me that information when that happens. I’m available if you need anything.

Hi @leodefaveri,

I wanted to inform you that the QA team successfully replicated the issue and has escalated it to the Hummingbird team as a confirmed bug. A fix will be included in one of our upcoming updates, though we cannot provide an exact timeline at the moment.

Further details will be shared in our changelog once the fix is released. Thank you again for your ongoing effort and feedback regarding this issue.

Kind Regards,
Nebu John

@wpmudevsupport14 It’s great news and I knew they would find the problem. Sometimes it’s difficult to listen to the user, but congratulations for listening to me and looking for a solution. I will be waiting for a correction and, if you want, I can give you new feedback.

Thanks!