Divi – Not auto flushing cache.

Hello Sean,

Thank you for the report.

Based on the provided information I was able to recreate the issue on my end. Indeed the SG Cache must be purged manually while the File-Based cache is enabled(pre-heat and logged in users cache enabled as well) when you perform changes to the website content via Divi. The changes are visible only once the cache is purged.

I will pass the case down to our plugin developers for further review.

Best Regards,
Simeon Boev

Great stuff. In the meantime I’ve gone ahead and enabled those features on the sites where I’m the only admin. These sites also don’t get updated for months on end anyway, but they still need to perform as best as possible. It’s the sites where I can’t really expect the other less tech savvy admins who update on an almost daily basis to keep flushing the cache.

Otherwise, the admin dashboards do seem a lot snappier with these features on ??

• This reply was modified 2 years, 9 months ago by Sean.

Are you on 7.0.1 because we tested a lot on Divi and everything flushes just right? Maybe disable their own caching / CSS combination stuff since it doesn’t make much sense using both?

I am on 7.0.1, on most of my sites. The one still on 7.0.0 has a different problem. I see the changes when logged in, but not logged in on another browser the changes are not seen unless manual cache purge.

7.0.1, no changes seen logged in or not, so the problem seems to have gotten worse. I even turned all Divi optimisations off, and still the problem persists.

I’m curious to know how css conflicts can inhibit auto cache purge, and I’m not seeing any display/layout problems.

Hasn’t Simeon just admitted there might be a bug?

I’m going to keep playing around. Do we keep this thread unresolved? Can I post any further findings in here? unless there is in fact a bug in the plugin, and I can continue with my weekend Netflix binge ??

• This reply was modified 2 years, 9 months ago by Sean.
• This reply was modified 2 years, 9 months ago by Sean.

Ok, here’s what I’ve found. All sites now updated to 7.0.1.

Even if all Divi optimisations are off, as soon as I turn file based caching on, changes made with the builder don’t show. I also tried with pre-heat and user cache each unchecked one at a time, same problem.

So I think I’m going to leave file caching off, for now, unless we can figure out what I might be missing.

If it’s useful to know, I’m using Safari as my main browser, and Chrome as my test browser not logged into WP on an M1 Air running Monterey. Mind you, the Music app is currently doing weird things. When building playlists in Apple Music cloud I often have to close and re-open it as it tends to choke. You think it’s maybe my laptop? as Monterey has had its fair share of bugs.

• This reply was modified 2 years, 9 months ago by Sean.
• This reply was modified 2 years, 9 months ago by Sean.

Since the update to 7.0.2, with pre-heat and logged-in users cache checked, changes made with the Divi builder are still not showing for users logged in, but they are showing in another browser not logged in.

In other words, changes made with Divi builder are triggering a cache clearing, but only for users not logged in.

However, this isn’t much of a problem for us as we are only 2 admins on 2 sites, and the sites are fast enough while logged in to WP (dynamically loaded), but even faster not logged in. ?? So logged-in users cache remains unchecked, for now.

• This reply was modified 2 years, 9 months ago by Sean.

Hello Sean,

Could you please let us know the website on which you are encountering this error, as well as step-by-step instructions on how to recreate it on our end so that we can check it further?

Thanks for your cooperation in advance!

I’m busy checking all my sites (only 8 of them) so far liveloula.eu is doing this, and also for not logged in users. I have flushed everything, repeatedly.

Basically, go to any page, > Enable Visual Builder > make a change (add a nice random word to the heading, or something) > click save, bottom right > exit builder. When the page refreshes the change is not there. Go back in to the builder, there is the change, exit the builder, no change. This will go on until I purge SG cache manually, or disable cache logged in users.

The above site is also my newest site, yet my 2 oldest and biggest sites both with 22 plugins seem to be working fine, and both with WPML, of all plugins.

All of my sites have exactly the same Divi performance and SG Optimiser settings. I have checked, a few times now.

• This reply was modified 2 years, 9 months ago by Sean.

mufasabackpackers.co.za, tag.org.za and juliesmithbelton.com are all auto flushing the cache, but for non-logged in users only.

• This reply was modified 2 years, 9 months ago by Sean. Reason: added extra sites

But, the last 3 sites never actually change, so this is mostly a non-issue. There are 2 other sites in my account not mentioned as they are just holding pages. Livelula is under live active dev right now, slowly, but a very easy fix is to just turn user cache off.

• This reply was modified 2 years, 9 months ago by Sean.

Hello @sean-h ,

The behavior in question happens due to the logged in user cache. By default, we do not cache content for logged in users however, once this option is activated there is a cache header sent which actually caches the page for that particular user.

This is the main reason why the change is not visible for the particular user that applied the modification through the front-end builder interface.

If you inspect the headers of that page through your developer tools you will notice that it will return as HIT https://prnt.sc/26tklsz

When the cache is purged the response changes and the content is visible:
https://prnt.sc/26tkmgd

Those tests are performed on a staging website not affecting your actual live application. The change immediately reflects once the cache is purged. This is actually expected functionality when the logged-in user cache is enabled.

You can keep that part disabled if you would prefer to see the changes made by a particular user and without the need to purge the cache once changes are applied through Visual Builder.

Best regards,
Georgi Ganchev

Hi @georgiganchev Thanks for the clarification. It would seem that this is in fact expected behaviour, but not really what I’m after. So I think I will leave user cache disabled, but I will still use file based caching and pre-heat, and every other feature of the SG Optim plugin ??

What I still find odd is that the cache appears to auto purge on 2 of my sites, but that could be because the page wasn’t cached in the first place, as a logged in user, for whatever reason.

Ok, now I think we can consider this ‘issue’ finally resolved.

I take it I can delete the staging copy you created? But isn’t that something you should have done?

@sean-h ,

This was indeed done by me when I replied the last time. However, I have reported the issue to our senior developers and they decided to conduct some tests and consider how to improve the way the logged-in users are been cached.

If possible, could you please keep the staging until next week we will delete it once the tests are completed? Of course, if the staging deletion has to happen right now, let us know and I will do it for you.

I’ve actually already deleted it because I didn’t know you still needed it, and because it wasn’t password protected. But feel free to create another copy if still needed which can then stay as long as necessary, I have plenty space and resources. Just please be sure to password protect it so Google doesn’t see it. Duplicate content is a problem.

• This reply was modified 2 years, 9 months ago by Sean.
• This reply was modified 2 years, 9 months ago by Sean.
• This reply was modified 2 years, 9 months ago by Sean.
• This reply was modified 2 years, 9 months ago by tobifjellner (Tor-Bjorn “Tobi” Fjellner).