Hey @fatcacky
I’ve checked your site and there are a lot of files in the wp-content/et-cache folder.
The issue is caused by your Divi cache. Please, disable it and reactivate the SG Optimizer plugin.
Regards,
Stanimir
Thanks Stanimir.
I think this setting in Divi is Static CSS File Generation. Do you know if this is correct?
I’m not sure what this does. It is conflicting with the SG Optimizer plugin? Does it need to be disabled or just cleared?
Thanks again.
Neil
Also would you recommend this is disabled on all the sites I look after that run on SiteGround with the SG Optimizer plugin. Three of my sites have this issue but at least one doesn’t.
OK. I’ve done some more testing and here is an update.
I have disabled caching in Divi as suggested (Static CSS File Generation).
When I make updates to the site in Divi for the first couple of times it shows on the live site as expected. However, it then begins to stop working as I described above and the only way to kick start it into action is to either deactivate and reactivate the SG Optimizer plugin or run a manual cache purge within the SG Optimizer caching settings.
In short the clearing and disabling of the Divi caching doesn’t seem to have resolved this.
Is there anything else I can try? Are there other reports of similar things happening with other people as this is affect 3 of my sites.
Thanks
Apologies for all the updates but I’ve just received this from Divi Support which may shed some light on this. I don’t pretend to understand so just passing on.
The screenshot I shared, points that your website is running on an NGINX server, and with the x-proxy-cache is equal to HIT means that it's loaded the cached contents from the server. As you can see that when editing the page in Visual Builder then the changes shows up and when logged out they don't appear. It shows that the contents are loaded from the server-side cache. If you could ask your host to disable the NGINX cache as that's hitting on every page load and then try to recheck this and see how it goes.
The server-side cache and Divi cache are different and Divi's cache doesn't conflict in general but sometimes the server-side caches are quite aggressive and they break things and changes don't show up unless you clear them from the server-side or disable them.
Please have them disable and then recheck, if still, that doesn't work then we can check it further from there.
Hope this helps.
Hey @fatcacky,
The SiteGround Optimizer plugin Auto-Flush functionality is listening for specific actions before cache is flushed. For posts – we are listening for save_post hook to be triggered. In order to avoid too many cache flushes, non public post types and statuses are excluded from cache – such as revisions, drafts, auto-drafts, e.t.c.
In this particular case, the builder is saving the post with an auto-draft post status, which is excluded from auto-flush. This is why the cache is not being automatically purged when making a change in the builder.
You can further discuss the case with the Divi support or manually purge the cache after changes are being made to the website.
Kind regards,
Ignat
Thanks Ignat.
I’ve passed this information on to Elegant Themes to see what they say.
When this started two or three weeks ago I initially had major issues when I updated SG Optimizer from 6.0.3 to 6.0.4. SiteGround support told me that there was a problem with 6.0.4 and so 6.0.5 was released very quickly. I’m clutching at straws here but is there any possibility that some of 6.0.4 is still hanging around even though it has since been updated to 6.0.5. The reason I ask this is that I look after a number of sites with very similar configurations and some work and some don’t. The ones that don’t were updated to 6.0.4 before then going to 6.0.5.
I notice that the SG plugin folder is completely removed when I delete the plugin but is that a 100% clean uninstall? If for example I have changed some settings from the default one in the plugin dashboard and then delete the plugin, if I then reinstall the plugin will it revert back to default setting or will it remember the old settings changes?
Thanks
Hey @fatcacky,
In the latest version of the plugin, there are no changes regarding auto-flushing of the cache, so this should be connected to any issues.
All sites should be using the latest version of the plugin.
Kind Regards,
Ignat
OK. Thanks.
With regards to the second part of my question, if the plugin is deleted is that a 100% clean uninstall i.e. there is absolutely nothing left behind that e.g. remembers settings etc. If not is there a way in which it can be 100% cleanly uninstalled?
Sorry if I’m going on but I’m paid to look after client websites and am still having issues with their sites but don’t know where the problem actually lies.
Thanks
Out of interest for the Auto-Purge setting should ‘When clearing the cache – purge the WordPress API cache too’ be ticked?
Hi again,
I’ve had a response from Divi regarding something you said in one of the above threads:
In this particular case, the builder is saving the post with an auto-draft post status, which is excluded from auto-flush.
They are asking if you can provide evidence for this as they are saying:
When the post is finally saved, its status will be “publish” and save_post hook triggers accordingly. So when the saving process is complete, the post/page status will be “published” and not “draft.” at that point the save_post hook gets triggered.
Thanks
For some reason support for this thread has stopped.
For anyone who is following this thread and has a similar issue I found that the only way to resolve this so that changes made in Divi are consistently updated instantly on the live site is to turn of Dynamic Caching in the SG Optimizer Plugin Caching page.
Note however that I turned this off on 3 sites a few days ago. I have just checked and for two of the sites it had turned back on again. I don’t know why but I’ll keep checking to see if it happens again.
Hello @fatcacky,
I have further investigated the case reported.
Allow me to explain a bit more how the cache flush is working for this particular case:
1. When you edit a page in the Divi Visual builder, there are several save_post hooks triggered.
2. We are fetching those hooks and create a Cron event with a delay of 90 seconds – this is being made in order to avoid too many cache flushes to be ran in short period of time which will basically prevent any cache being stored for the site.
3. When there are 90 seconds without any modifications made on the site, the cron event will be triggered upon any hit on the website. This is when you will see the post updated content on the website.
I want to confirm that I have also tested this logic on your website, and confirm that cache is successfully flushed when the cron event is being triggered.
Best Regards,
Elena
Thanks Elena.
Unfortunately I don’t really understand about flushing, the triggering of hooks and Cron events etc but I ‘sort of’ understand your explanation. All I know is that since I did updates on several sites a number of them began behaving differently to how they worked before. Before the updates any time I made a change in Divi it would be reflected instantly on the live site. As a designer this is vital. I can’t wait for 90 seconds to wait to see the live results of a change. It’s just not practical to work like that.
I don’t know what has changed i.e. whether it’s the SG Optimizer plugin or Divi as I keep getting passed back and forth between the two each saying it’s something the other one has done.
As I mentioned though. The fix for these sites is to turn off Dynamic Caching in the SG Optimizer plugin and it works how it used to before the updates. Seems crazy and also makes me wonder whether I need the plugin but from my testing if I remove it I have problems also. This is why I was asking (but was never answered) if by deleting the plugin it is 100% removed or are some remnants left behind.
I now have a new problem. Despite me turning off the Dynamic Caching in the SG Optimizer plugin on my site and two others it has somehow turned itself back on again. Is there something in the plugin that makes it do this periodically and if so how do I disable that feature permanently?
Thanks
There are some database options left in the database with the plugin deactivation, @fatcacky.
This is made to avoid setting it up from start and loosing important data such as excluded values from the optimization options.
We are planing on adding option in the plugin deactivation to choose all data to be erased, still I can not provide an ETA.
The plugin does not turn Dynamic cache by itself. It can be turned back on by enabling Automatic Purge and Browser-specific Caching options, but you will be warned about this as well.
Best Regards,
Elena
