LiteSpeed deleting Divi 5 taxonomies dynamic css folder bug
-
Hi! I have a weird issue with the current version of LiteSpeed and Divi 5 beta (latest version).
Website is running ok but than at some time (I cannot discover what is triggering this) when opening a Woocommerce category the page fails to load with few 404 errors – it cannot find the dynamic css files located in the wp-content/et-cache/taxonomy directory. I checked and they are indeed missing – in fact the whole directory was absent. When I clear the LiteSpeed cache it is populated again and the website works. Clearing the browser cache before clearing the LiteSpeed one does not seem to fix it. I have to assume this is some conflict with Divi and LiteSpeed.
I tried to exclude the whole et-cache directory from the settings, including adding no-cache headers for the css files located there via .htacccss but the problem still occurs at a random time. (I checked the headers for the files and they were showing private, no-cache, must-revalidate). I have excluded those files from combining. This issue appears to be happening only on Woocommerce categories which dynamic css files are located there.
Any help in resolving this will be greatly appreciated! If you need any info feel free to ask. Thanks!
-
Sorry but I have to update the topic with some bad news – this bug is happening even with the combine enabled! For some reason on the bugged category it loads the same combines css name but its content is different from the one loaded on the other pages. I don’t know how this is possible but maybe the combine is adding them on the fly – it does not find the dynamic css for this page and skips it (there are no 404 errors just broken css this time ). I’m really out of ideas – please advice me on some solution to mitigate this.
Here are links to the files (strangely enough its the same name and version) – https://limewire.com/d/kwvAZ#fmIfPCy3bv as you can see the bugged one is missing around 200kb of css – probably the one from the dynamic one.
*My last hope now is to disable the critical css from Divi (I don’t think it matters as it’s combined) and the display styles inline (without this option I got a broken style on the home page – probably due to the critical css not being rendered). I have to say that the bugged one happened after I browsed many categories so it triggers on some specific moment – once it triggers it’s fixed when cleaning the divi static css cache or Litespeed.
I see that on cache clean Divi is includes/builder/feature/DoNotCachePage.php feature to create such file to stop the caching. I’m not sure this has anything to do with this but they mentioned some issues with some plugins in the previous version which they say are fixed. I will continue to test with the current setup with no inline and no critical but I don’t have much hopes. If you have any idea if there is a way to fix this trough Litespeed please share as I am getting desperate. It’s such a bummer that they removed the dynamic css disable feature and I think there is really no adequate option that will keep working css on the website.
Here is the code they have in this file regarding LiteSpeed if you think this can help.
// Disable LiteSpeed Cache. $reason = esc_html__( 'Generating CSS', 'et_builder' ); do_action( 'litespeed_control_set_nocache', $reason );Looks as it applies only when you regenerate manually not sure if it triggers on their random regeneration / removals.
Since the beta Divi have actively recommended the version for live websites so this issue will probably be affecting a lot of people.
Thanks! I added post_updated – should I add also edit_post or this is enough?
I have to say that the removal of the dynamic css folders in the et-cache/taxonomy does not happen only when a product or category is edited. When it’s edited the whole folder is removed and after visiting a category is regenerated – but the individual category dynamic css folders inside are removed at some point, even if there is no editing – so I guess the problem can still occur even if the cache is purged when a product is edited. I don’t really know the logic behind those dynamic.css purges as they happen very frequently – I can have let’s say 20 folders inside but after some time I can get 3-4 in it. Really weird behavior – If this is not resolved I will write to Divi to see if they can do anything about it. I will report if I encounter the bug again with this fix – if you have any other suggestions please write. *I will monitor the number of folders and date of modification to see if they reduce without any action in the backend (maybe the critical css or the inline styles generator forces the clearance of the category folders for some reason or might be some other inner Divi logic to remove them even if they are not manually purged or changed).
What makes this weirder is that all those dynamic css files are identical for all the categories (at least in my case) which is making their generation even more unnecessary. If everything fails I will have to brute force disable it in some way and add it as a static file…
*Edit – With AI I analyzed the DynamicAssets.php and among other things is said that this code is responsible for the et-divi-dynamic.css and et-divi.dynamic-late.css located in those taxonomy folders.
$files = (array) glob( "{$this->_cache_dir_path}/{$this->_folder_name}/et*-dynamic*{$this->_tb_prefix}*" );
foreach ( $files as $file ) {
if ( ! et_()->includes( $file, '-late' ) ) {
$generate_assets = false;
break;
}
}
if ( $generate_assets ) {
// Regenerates if files are missing
$this->generate_dynamic_assets();
}If you think something in it can conflict with the Litespeed or can be easily fix please share. Thanks!
This one has something to do with the taxonomy handling
// In get_folder_name()
if ( DynamicAssetsUtils::is_taxonomy() ) {
$queried = get_queried_object();
$taxonomy = sanitize_key( $queried->taxonomy );
$folder_name = "taxonomy/{$taxonomy}/" . $this->_object_id;
}Response from Divi Support:
I took a quick look at your site, and I was able to see a similar issue on the first view of the website.
Here’s a short video:However, at the same time, using ?nocache in the URL, the same page shows fine.
Indeed, this is just caching for Litespeed, which still has old Divi files where Divi’s CSS files got updated, and didn’t clear the LiteSpeed plugin cache serving the old CSS files, which gave 404.
It’s hard to tell at the moment what exactly triggered the Divi’s CSS file to change.
When Divi’s Cache is cleared, it will also clear the cache of Litespeed based on this script used on the Divi5
Divi/core/components/int.php file:
And the Litespeed cache cleared is called from the Divi’s native “et_core_clear_wp_cache” function.
Based on the function, if the Post_ID is sent while clearing cache, it will only clear cache of that post; else, it will clear all Litespeed cache.
According to the issue that you are having which is only happening with the taxonomy pages, I’m afraid that the Support team doesn’t have any information to share.
However, I’ll share all the information I have gathered from this conversation with our dev team and will request to review the Litespeed cache clearing system along with Divi’s cache and investigate on possible causes for this kind of issue.
// As I expected pretty much the issue is that Divi does not force LiteSpeed to clean when it cleans. They provided a code that supposedly should this but I guess it does not work as expected. Can you tell what might cause it to not function?
You must be logged in to reply to this topic.
