• ImageT4ng

    (@schwipps)


    Hi there,

    @jamieburchell, it’s been a while πŸ˜…

    I’m opening a new topic about this non resolved issue.

    Long story short: when using W3TC’s page cache functionnality, after updating Elementor, or deploying a new website version (which wipes out the cache and non-repository saved files, some Elementor pages miss the related CSS, thus look broken. After a couple hours, clearing caches back and forth, things seem to resolve by itself.

    Last week, I updated W3TC and Elementor to their latest versions, after not updating the plugins for a too long period. While reading changelogs, I noticed W3 Total Cache, in its latest version, claims adressing caching issues with Elementor. So I though: “Yay, they finally soved it!”. Unfortunately, the results is even worse than before. Now, after deploying, when using page cache, ALL my Elementor pages are broken.

    I tried one earlier W3TC version: same results.

    So I went for further testings, again (interesting since I now have a more consistent behavior), and found this:

    1. Right after a deployment (everything is purged), all my Elementor pages are broken.
    2. If, a few seconds after loading a broken page, I “Purge all caches” (W3TC) and then reload a page I just attempted to display, then it renders correctly (A page I didn’t just attempt to render will be brocken though).
    3. However, if I also purge the Elementor CSS, the same page is broken again.
    4. I checked by switching to Elementor CSS file mode (instead of inline): the CSS is generated quite quickly as well, visible in the /uploads/elementor/css/ folder, with the expected content. The problem is that this files seems to be always created just too late (not SO late but still too late), right after the page’s HTML is cached, so with the missing inline CSS, or no CSS filepath declaration, since it’s probably not provided if the file is not yet generated; thus after the HTML page cache is saved, again.

    I did them back and forth: my tests are now consistent. So I’m quite confident this explanation makes sense.

    One solution could be to use the Elementor CSS file method + keeping the content of the uploads/elementor/css/* folder when deploying. So that the files are still ready to serve.

    Unfortuntately, this won’t be sufficient, for 2 reasons:

    • Elementor wipes out the CSS during each Elementor update. Considering Elementor’s high update frequency, we can assume we’ll still often face the issue…
    • There’s a chance Elementor needs to regenerate the CSS files after the update, so that the maintained files might be outdated, or break the pages.

    So… The real solution, would be leveraging an Elementor signal which would tell: “Hey Cache plugin! It took a bit, but my CSS is now ready >> you can now render the page and cache it!).

    Considering you W3TC and Elementor both count amongst the most used WordPress plugins, is there a chance you guys team up to build such a process? So that we can take advantage of a powerful pagebuilder + a lightening fast cache plugin ?

    Thanks

Viewing 15 replies - 1 through 15 (of 23 total)
  • ImageJamie Burchell

    (@jamieburchell)

    Hey @schwipps. Happy 2025 πŸ˜€

    The W3TC plugin now calls Elementor’s regenerate CSS function when purging all caches, so this makes the problem happen every time for me on deployment now. Unless that change is rolled back, I’ll need to change the deployment to manually call each of the purges (object, minify, page) I think.

    You’re right that Elementor flushes its CSS during database upgrades, which usually then also causes the issue.

    Like you, I need to keep purging the page cache after this has happened, then visit some pages until they render correctly. Almost all of the time now one page will look fine, and another will be missing styles, and it’s just a case of keep purging the page cache until every template renders correctly.

    I have tried both internal and external embedding – it makes no difference.

    What I do not understand is how it’s possible that the final HTML cached by W3TC is missing the stylesheet links or inline CSS. That same HTML delivered to the browser without going through W3TC would have the missing entries, so why doesn’t W3TC capture the same?

    Anecdotally, I no longer use Elementor for new projects – have moved to Bricks. The same setup on Bricks works flawlessly, but then Bricks generates its CSS ahead of time (or at least, the option to do so works properly, unlike Elementor’s “–regenerate” switch which randomly misses some CSS like custom fonts).

    Thread Starter ImageT4ng

    (@schwipps)

    @jamieburchell you say W3TC now calls Elementor’s regenerate CSS function when purging all caches. That’s pretty bad.
    Do you know since which version?

    By the way, we’re also moving away from Elementor, but I need a solution to keep the website fine untill we switch for real. We’re moving to Gutenberg/custom blocks. Bricks seems great, but we didn’t want to rely on an external page builder. We’ll see how it goes.

    ImageJamie Burchell

    (@jamieburchell)

    @schwipps

    It was introduced in W3TC 2.8.11

    Enhancement: Flush Elementor cache when all caches are flushed

    The code change is here discussion here.

    Off topic but I think producing websites in MS Word would be better than using Elementor πŸ˜€

    ImageJamie Burchell

    (@jamieburchell)

    Reading through the discussion / reason why that change was made in 2.8.11 it actually sounds like the original author is just running in to this same issue we’ve been having for years. Certainly the methods used to fix the issue are the same:

    • One is disable W3 Total Cache and everything works again.
    • two is run the following command in command line: wp elementor flush-css –regenerate
    • Three is disable Page Cache in the W3 Total Cache Settings.
    Thread Starter ImageT4ng

    (@schwipps)

    It was introduced in W3TC 2.8.11

    Enhancement: Flush Elementor cache when all caches are flushed

    The code change is here discussion here.

    Thanks!

    Off topic but I think producing websites in MS Word would be better than using Elementor πŸ˜€

    Yeah… Projects evolve, plugins as well. Elementor was promising at first but seem to have lost themselves in adding useless functionnalities, rather than fixing what’s essential. At least for what I need now.
    V4 seem to address some of these issues, but it’s just way too late.
    Now we just value structure and reliability over shine.

    ImageJamie Burchell

    (@jamieburchell)

    Hey @schwipps I may have a rudimentary patch/fix for Elementor to solve this. Would you mind testing it?

    Replace elementor/core/files/css/base.php with this:

    https://pastebin.com/raw/Z2NdizSE

    I’m reproducing the issue without W3TC enabled at all now – Elementor returning the HTML without the references to the stylesheets until the second page load. This crude fix seems to be working. If it works for you it could help pinpoint the issue.

    ImageJamie Burchell

    (@jamieburchell)

    @schwipps Digging a bit deeper as to why the workaround patch posted above works and it comes down to this: When this meta update happens, when it is subsequently read here it’s not pulling the information that was just saved. Even with object caches disabled, the saved data is just not fetched and it becomes necessary to retry the operation. I have no idea why, and to be honest I’m not even going to bother trying to open this as an issue with Elementor since it’ll get immediately closed or ignored.

    ImageJamie Burchell

    (@jamieburchell)

    @schwipps Note that also unfortunately the object cache needs to be disabled in addition to the above patch.

    Thread Starter ImageT4ng

    (@schwipps)

    I’m not even going to bother trying to open this as an issue with Elementor since it’ll get immediately closed or ignored.

    Thanks for taking time digging this issue. Let’s hope Elementor takes a look at it as well.

    ImageJamie Burchell

    (@jamieburchell)

    @schwipps The good news is the combination of disabling W3TC’s object cache and this patched Elementor file fixes the problem. I’ve updated the patch to be less crude. It would be great if W3TC/Elementor devs look at this, but at least for Elementor that’s highly unlikely to happen in my experience.

    I’m not too bothered about disabling object cache. There’s not much point using it with full page caching anyway.

    @schwipps I had an hour to waste so opened a ticket πŸ™‚

    Did the combination of the Elementor patch and disabling the W3TC object cache resolve the issue for you too?

    Good news @schwipps I came up with a one-line Elementor patch that will fix this even when using object cache. I have this patch being applied during composer install and so far it’s fixed!

    --- web/app/plugins/elementor/core/files/css/post.php.old	2025-08-12 16:45:30.350894002 +0100
    +++ web/app/plugins/elementor/core/files/css/post.php 2025-08-12 16:42:10.490082245 +0100
    @@ -112,6 +112,7 @@
    * @return array Post CSS file meta data.
    */
    protected function load_meta() {
    + wp_cache_delete( $this->post_id, 'post_meta' ); # https://github.com/elementor/elementor/issues/32226
    return get_post_meta( $this->post_id, static::META_KEY, true );
    }
    Thread Starter ImageT4ng

    (@schwipps)

    Hi @jamieburchell,

    Great you came up with a working patch πŸ™‚

    Unfortunately, I won’t be able to test it by the end of the month.

    I’ll keep you posted

    Plugin Author ImageJoe Cartonia

    (@joemoto)

    We see success when flushing the object cache after flushing the Elementor cache. Feel free to test the fix in pull request #1158 and let us know if there are any issues.

    Unfortunately it’s a bit more complicated than that @joemoto due to the race condition encountered during simultaneous requests. The patch at the end of my Elementor ticket resolves it however. I have updated that ticket with a full deep dive in to what’s going on.

Viewing 15 replies - 1 through 15 (of 23 total)

You must be logged in to reply to this topic.