morphiaz

This is extremely frustrating and I am lost for words……….. I simply dont understand where the problem ist to tell us which value we have to change to stop this 24 hour madness.

Hello!
This is Alain from the T3 team. Thank you for reporting this situation.

In this case, I must let you know that we are aware of the situation you have described before. This is a common behavior with some cache systems that create/server static files to visitors.
The feature you mention (automated task) from Elementor is supposed to regenerate those CSS files based on a next visit. This avoids regenerating all files at once, which will cause server resources spikes... The conflict comes when a cache system that had already cached the HTML and CSS files for every post/page, won’t be able to serve the new file because a different time expiration (this trying to serve an expired file).

For cases where the cache system and Elementor get into this conflict, we encourage users to change the Elementor CSS Print Method from “External file” to “Internal Embedding” (read here -> Performance). This way, the necessary CSS will be stored into every page HTML instead of external files, so the cache system will always be serving the styles (everything’s inside a single document, instead of multiple).
I must state that Elementor only loads the specific CSS for every post/page, not the whole site CSS on every page/post. So, don’t worry about the internal CSS and the document size, this shouldn’t affect the site performance (the final size will still be optimum).

In case that switching from External to Internal CSS serving causes a similar/new conflict, please test by disabling your cache system, or any optimization feature/plugin, to see if it helps. In such a case, please contact the service provider for more help.

I hope this can clarify the situation.
Let me know if you need any further help.

Regards,|

It’s really frustrating when posts on the official Elementor Facebook forum keep getting deleted — especially when all I’m trying to do is explain this exact problem. That’s not a very customer-friendly approach, dear Elementor team.

The fact is, something changed in the version Elementor released on September 15, 2025, which is causing this exact issue for users of WP Rocket, WP Fastest Cache, WP-Optimize, and similar caching solutions.

As I mentioned before, rolling back the update to September 14, 2025 fixed the problem — it’s completely gone on my test site. But on every other site running a version from September 15, 2025 onwards, the issue persists and the sites are broken.

@philapho @denstrk @quoup here is the Github Ticket: https://github.com/elementor/elementor/issues/33057

@adalov @miloss84 this is the ticket ID:

Case #TSM6UOY4X7FV

@philapho let’s be clear: this has nothing to do with incompatibility with other plugins or any new feature. This is definitely a bug. There is absolutely no reason to delete all CSS files on a scheduled basis — and the user can’t disable it, even if the Element Cache is turned off — when nothing on the site has changed (no edits, no plugin or core updates, etc.).

This is simply insane and it’s breaking all caching plugins that thousands of users have been relying on for years. I see countless posts online from people confused about why this is happening, and I honestly don’t understand why no one has dug deeper into it yet.

@naou same for us. We dont update automatically anything without doing our QA on a stage website to check if the update breaks something. All auto updates are disabled by default.

I am also working on a mu-plugin to stop the regular automatic purge from Elementor that works this way:

If someone edits any page, templates etc., or makes updates of core / plugins, or even if someone clicks the button “Clear Files & Data” then yes; allow it -> go ahead and let Elementor purge automatically – but just dont do it on a regular basis every 12+ hours when no one made edits / updates / etc.

I am testing it on a website and for now, it seems to work fine.