donfloyd

@jchambo It still exists – you can find it in options – builder – advanced . I think it’s good to try to turn off the lite speed inline / combine feature as it’s possible to have issues with the divi dynamic css ( and does not provide any benefits when using HTTP/2). See if you have the divi option turned on and if not try it.

• This reply was modified 2 weeks, 6 days ago by donfloyd.

@jchambo I just tested and on the latest version Divi does not wipe the taxonomy folder in et-cache as before when you update a product / category. You can check if this is so on your installation but I think currently this particular issues should be resolved – you might have a different one. Do you get similar broken css on category pages like me – when you check the source do you get broken dynamic css links? If not it might be something else as the files should not be deleted on post changes as before. Verify within your et-cache folder if any files or dirs disappear when you make changes. I think LiteSpeed should flush on Divi manual cache flush – but you might check if this is true.

For a long time I used a mu-plugin with a code to prevent the Divi cache clearing on any product / page or other kind of change that worked kinda ok. The other solution was as the one suggested by LiteSpeed to flush it each on every page / post change which kinda defeats the idea behind the cache in the first place. Anyway – Divi introduced a change that I think fixed that – I don’t remember which version it was but it was still in the beta version. I did tests after that and the bug looked fixed. I don’t know if any of the recent versions introduced it again – I will make some tests to verify it.

Here is the code that I used before the fix but I think they managed to resolve it…or maybe they

<?php
/**
 * Plugin Name: Divi 5 Strict Cache Protector (Clean & Specific)
 * Description: Prevents cache clearing on Products, Posts, Widgets, and Plugins by targeting specific callbacks.
 * Version: 5.2
 * Author: StackOverflow
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'wp_loaded', function() {

    // =========================================================================
    // TARGET 1: THE LOOPHOOKS (Products & Posts Fix)
    // =========================================================================
    $loop_hooks_class = 'ET\Builder\Packages\Module\Options\Loop\LoopHooks';

    if ( class_exists( $loop_hooks_class ) ) {
        // Unhook Post Status Transitions
        remove_action( 'transition_post_status', [ $loop_hooks_class, 'invalidate_cache_on_post_change' ], 10 );
        remove_action( 'wp_insert_post',         [ $loop_hooks_class, 'invalidate_cache_on_post_insert' ], 10 );
        
        // Unhook Deletions/Trash
        remove_action( 'delete_post',     [ $loop_hooks_class, 'invalidate_cache_on_post_change' ], 10 );
        remove_action( 'wp_trash_post',   [ $loop_hooks_class, 'invalidate_cache_on_post_change' ], 10 );
        remove_action( 'trashed_post',    [ $loop_hooks_class, 'invalidate_cache_on_post_change' ], 10 );
        remove_action( 'wp_untrash_post', [ $loop_hooks_class, 'invalidate_cache_on_post_change' ], 10 );

        // Unhook Terms and Users
        remove_action( 'created_term',  [ $loop_hooks_class, 'invalidate_cache_on_content_change' ], 10 );
        remove_action( 'delete_term',   [ $loop_hooks_class, 'invalidate_cache_on_content_change' ], 10 );
        remove_action( 'user_register', [ $loop_hooks_class, 'invalidate_cache_on_content_change' ], 10 );
        remove_action( 'delete_user',   [ $loop_hooks_class, 'invalidate_cache_on_content_change' ], 10 );
    }

    // =========================================================================
    // TARGET 2: STANDARD PAGE RESOURCES (Widgets & Customizer)
    // =========================================================================
    $resource_class = 'ET_Core_PageResource';

    if ( class_exists( $resource_class ) ) {
        
        // Remove Standard Post Save (Backup safety)
        if ( has_action( 'save_post', [ $resource_class, 'save_post_cb' ] ) ) {
            remove_action( 'save_post', [ $resource_class, 'save_post_cb' ], 10 );
        }

        // Remove Customizer Save Clear
        if ( has_action( 'customize_save_after', [ $resource_class, 'customize_save_after_cb' ] ) ) {
            remove_action( 'customize_save_after', [ $resource_class, 'customize_save_after_cb' ] );
        }

        // Remove Widget Update Clear
        if ( has_filter( 'widget_update_callback', [ $resource_class, 'widget_update_callback_cb' ] ) ) {
            remove_filter( 'widget_update_callback', [ $resource_class, 'widget_update_callback_cb' ] );
        }

        // Remove Widget Delete Clear
        if ( has_filter( 'delete_widget', [ $resource_class, 'widget_update_callback_cb' ] ) ) {
            remove_filter( 'delete_widget', [ $resource_class, 'widget_update_callback_cb' ] );
        }
    }

    // =========================================================================
    // TARGET 3: PLUGINS & THEMES (Specific Targets)
    // =========================================================================
    
    // Divi historically uses this specific global function to clear cache 
    // on plugin activation/updates.
    $func = 'et_core_page_resource_auto_clear';

    remove_action( 'activated_plugin', $func );
    remove_action( 'deactivated_plugin', $func );
    remove_action( 'switch_theme', $func );
    remove_action( 'upgrader_process_complete', $func );

}, 100 );

Ok I think I finally got it – When I edit a product or post – Divi wipes out the whole taxonomy folder (this happens on Divi 4 too). This DOES not trigger Litespeed purge. Editing a category does purge Litespeed but it’s not purging Divi’s taxonomy cache folder. So I guess their code that triggers Litespeed purge or their purge is not working (at least on the current Litespeed version) or this change is not supposed to wipe this cache anyway (as editing a post only removes the taxonomy folder – not the ones located in the upper directory). I will write to them to investigate and fix this behavior.

The code they are referring to in the Divi/core/components/int.php file: (image was not pasted)

	// LiteSpeed Cache v3.0+.
		if ( '' !== $post_id && has_action( 'litespeed_purge_post' ) ) {
			do_action( 'litespeed_purge_post', $post_id );
		} elseif ( '' === $post_id && has_action( 'litespeed_purge_all' ) ) {
			do_action( 'litespeed_purge_all' );
		}

Hi again! Some updates on the issue:

I’ve been in touch with the Divi support and I’ve provided them with the information that I have and I am expecting some response soon.

What I’ve learned so far: Most likely the bug scenario is: LiteSpeed caches the page with link to the dynamic.css – Divi meanwhile has cleared the file – variant 1 Lite speed loads a cached version of the css – Everything is ok –variant 2 – the bug happens – LiteSpeed loads cached page but do not load cached css but requests the missing file. (Please tell me when this scenario can happen – why LiteSpeed might serve a cached page but no cached css file)

Reasons for divi taxonomy deletion without any edits of posts or any backend activity

I’ve included currently a script that detects when the dynamic css is cleaned – it looks it is purged on any post change – which by itself will cause issue as LiteSpeed will not clean the cache on those occasions (that’s the reason why your solution to purge all on change will work on this scenario). This is not very practical though. The dynamic css purge happens even on unrelated posts like orders.

The problem with my setup is that Divi dynamic css is cleaned even without any edits – probably cause is some 3rd party plugin triggering in through some cron / scheduled action or other automatic method. Main suspect right now is BeRocket Ajax Filters – I will report if this is confirmed.

Conclusion and questions

Even if I resolve the cache clearing that is not based on manual change the fact that Divi cleans its cache on every change is a bit of a problem when LiteSpeed does not do that by default. Moreover even if I set up the purge all action on post update Divi has an automatic purge that occurs in 6 days or something. So even than this purge can happen and LiteSpeed will not know or purge its cache.

Questions: Do you know what can cause LiteSpeed to have missing dynamic css cached file when loading a cached html containing the broken dynamic css and can this be prevented is some way. If this is not happening the bug will not occur as usually even if the cache folder is missing Litespeed serves the cached one and it’s ok. Once this fails the broken page gets cached and stays broken until purge.

I have added post_updated (Should I add edit_post too?). I’m running with no critical and inline css – with combine and minify enabled + the new purge. So far I haven’t encountered the bug but as it happens quite rarely I will continue testing (last time it took quite a lot of category opening to appear with the combine). I checked and it looks the constant purging of those items in the taxonomy is not unique to Divi5 and it looks that on Divi4 they are randomly refreshed even with no updates on posts / products. I suspect some race conditions occur at times when Litespeed caches the page before or at the moment of the css generation but I’m not a developer so my insight is very limited. It’s weird that refreshing the page still produces the broken layout as what it looks in the code there are checks that run to verify and re-create it. I still can’t grasp the logic behind the dynamic and the dynamic-late regeneration in the code I pasted from the DyamicAssets.php and the relationship between those two. As I was running the website on an apache server for quite some time with no issue I have to believe that Litespeed comes in to play somewhere. As I mentioned I have tried to exclude the directory from caching but that didn’;’t help (I guess this has to do more with the page caching rather than the css files themselves) . Thanks for help.

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).

• This reply was modified 6 months ago by donfloyd.