Missing Elementor CSS pages when using page cache

  • ImageT4ng

    (@schwipps)


    4 months ago

    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 8 replies - 16 through 23 (of 23 total)
1 2
  • Thread Starter ImageT4ng

    (@schwipps)

    3 months, 2 weeks ago

    Hi @jamieburchell,

    Ready to test your fix!

    So to my understanding, it basically consists in patching Elementor with the aforementioned modification, isn’t it? No modification required on W3TC?

    Thanks!

    ImageJamie Burchell

    (@jamieburchell)

    3 months, 2 weeks ago

    Hi @schwipps

    Yup

    --- 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' );
     		return get_post_meta( $this->post_id, static::META_KEY, true );
     	}
    Thread Starter ImageT4ng

    (@schwipps)

    3 months, 2 weeks ago

    Hi @jamieburchell,

    We gave it a try yesterday, and it seems to work. I noticed zero Elementor broken pages while all of them were without this patch 🙂

    This was tested with W3TC 2.8.10

    Therefore, we pushed this live, and… get broken pages again :((

    ImageJamie Burchell

    (@jamieburchell)

    3 months, 2 weeks ago

    @schwipps Are you certain that the patch is applied in production?

    There could be something else going on in your case, but so far this patch has cured the issue completely. Even with the W3TC object cache and CSS minification.

    Thread Starter ImageT4ng

    (@schwipps)

    3 months, 1 week ago

    Hi @jamieburchell,

    Yes the patch is applied, for sure.

    Couple of days after, here is what I can notice :

    • The bug actually also happens on the test website. Less, but still happens. I suspect this is because this environment is faster/has more resources for each request. Which is possible since this website get no real trafic, besides cache priming and… me.
    • I tweaked the setup a bit:
      – I can’t purge a page individually when Always cache Pro extension is enable: I’ll get a “Failed to handl page url” message.
      – Clearing redis from the cli solves it… only for the pages that have already been callded, the other one, not yet cached, will render broken.
      > So got rid of this extension.
    • I enabled the Late Initialization setting. Can’t harm much, IMO, considering the bug we face.
    • From my testings now, with this setup, iwhat seems consistant is that, as long as I call pages individually, wait for these to render, I’ll be fine. As soon as I call too much pages too quickly, I’ll start getting Elementor pages missing their CSS.

    May I know which Elementor CSS rendering method you use? I also believe you’re on W3TC 3.8.12?

    Thanks

    Imageacwporg

    (@acwporg)

    3 months, 1 week ago

    I feel like this is issue is worse than ever now.. all the cache flushing in the world leaves Elementor sites broken. Turning off W3TC resolves it.. It used to take half a dozen cache flushes which was bad enough..

    ImageJamie Burchell

    (@jamieburchell)

    3 months, 1 week ago

    @acwporg It’s got worse recently because W3TC now calls the Elementor Regenerate CSS routine when W3TC runs its flush all routine.

    @schwipps I’m running Elementor and Pro 3.31.2, W3TC 2.8.12. I use External Embedding (in my testing it didn’t make a difference which one I used), Memcached (object cache only), Minify (not combine), Disk Enhanced Object Cache. Your observations about fast parallel access and a race condition are consistent with the issue that exists in Elementor, but I’m not sure why my patch hasn’t worked in your case.

    ImageJamie Burchell

    (@jamieburchell)

    3 months, 1 week ago

    One further thought @schwipps I don’t have HTML browser caching enabled. The only browser caching I have enabled are CSS, JS, images, fonts etc.

Viewing 8 replies - 16 through 23 (of 23 total)
1 2

You must be logged in to reply to this topic.