jamieburchell

I’m pretty sure that you are not hallucinating @dylandawg I’ve observed the disk cache files remaining in place for example when disabling page cache and then clearing all caches. I would imagine the code probably clears the cache of the feature enabled, so by switching method and clearing caches the caches only for the selected method are cleared.

You could switch method and then manually delete the contents of the cache directory to stop the web server from picking them up.

Hi @vmarko

Here’s mine

Are you regenerating Elementor’s CSS before you clear the W3TC caches? That’s what appears to be causing the issues.

It will definitely cause an issue for us because the stylesheets referenced in that old HTML are no longer available. However, I don’t think that’s the only issue here. I did try removing the code responsible for serving the old HTML and while it “fixed” the problem for that 30 second window I still encountered the broken page issues outside of that window. I will try again if I get some time.

@schwipps What I said about the old version of the HTML being served for 30 seconds is not quite correct. The old version of the HTML is served if it is no more than 30 seconds old. So, the old version of HTML could be served for you for 30 seconds if it is still quite fresh. Of course, when I was testing things by repeatedly clearing caches I was triggering this behaviour.

I’m not quite sure why W3TC does this. It was said that it was done to keep the website online. Perhaps it’s to allow enough time for a new HTML page to be generated while visitors can continue to get the older page. But, a new page would need to be generated and served if the old version was created more than 30 seconds ago anyway, so I’m not sure that reasoning stacks up?

@schwipps @vmarko

One issue I can definitely reproduce is this: When Elementor’s CSS files are “regenerated” by default that means they are removed until a page comes along and requests them. Immediately after a “regeneration” if we clear the W3TC page cache and that cache is fresh enough, for the next 30 seconds W3TC serves us the “old” version of the HTML which now includes links to missing stylesheets.

I know that Elementor’s “flush-css” command removes the stylesheets from wp-content/uploads/elementor/css and also clears some entries from the database but I have no idea why asking it to generate the files fresh and then clearing the W3TC cache still causes the issues but not flushing Elementor’s cache at all appears to work fine.

I have tested with the object cache completely disabled (and the object cache PHP file removed) and with it enabled and it doesn’t seem to make any difference to this issue.

@schwipps I think the same, it’s something like that.

Then I had an idea – what if I add the “–regenerate” switch to the command I am using:

wp elementor flush-css --regenerate

Which not only removes the old files, but creates the new ones immediately, before I flush the W3TC page cache. I really thought I’d cracked it, but then the issue persisted. So now I am just trying without the flush at all. The problem is that flushing Elementor’s CSS is often a way to cure other problems.

Sidenote in case it’s useful to you, Elementor has acknowledged that the placement of linked stylesheets in the HTML from initial page load to subsequent page load differs.

Hi @schwipps

I thought you already regenerated Elementor’s CSS files as part of your deployment process.

What I have found is that not doing so is helping.

@schwipps Are you able to remove the “Regenerate Elementor CSS” from your deployment process to see if that resolves the issue with the pages breaking after deployment? This is something I am trying and so far, it’s looking good.

@schwipps

I figured out this is something Elementor is doing. After regenerating CSS the styles mostly appear in the footer and then subsequently they are added to the head. W3TC isn’t the cause of that, but because it caches “the first page load” it’s more noticeable.

@schwipps @vmarko

After a deployment sometimes the styles are all present, but there’s a flash of unstyled content (FOUC) as the page is rendering. When I clear the caches and refresh, everything renders as expected.

I took a copy of the “glitchy” HTML page and the “stable” HTML page and compared them and found that the glitchy page had inserted most of the stylesheet links at the foot of the page. That explains the FOUC but not the reason for linking them there.

@vmarko Nevermind, I think I answered my own question. It looks like a key is incremented for the object cache, rather than a data flush.

@vmarko Would you expect the memcache data to be removed when the object cache is cleared?

I just checked with memcached-tool before and after using W3TC to trigger the object cache clear and the data still appears to be present?

  #  Item_Size  Max_age   Pages   Count   Full?  Evicted Evict_Time OOM
  3     152B        71s       1       1      no        0        0    0
  4     192B     19812s       1     116      no        0        0    0
  5     240B       108s       1     116      no        0        0    0
  6     304B       124s       1      52      no        0        0    0
  7     384B     15094s       1      20      no        0        0    0
  8     480B       108s       1      21      no        0        0    0
  9     600B       476s       1      33      no        0        0    0
 10     752B     19937s       1     104      no        0        0    0
 11     944B     19937s       1      29      no        0        0    0
 12     1.2K     19937s       1      41      no        0        0    0
 13     1.4K     15091s       1      10      no        0        0    0
 14     1.8K     15093s       1      42      no        0        0    0
 15     2.3K     15089s       1      19      no        0        0    0
 16     2.8K        47s       1       4      no        0        0    0
 17     3.5K       108s       1      11      no        0        0    0
 18     4.4K       108s       1       4      no        0        0    0
 19     5.5K       108s       1       3      no        0        0    0
 20     6.9K        95s       1       2      no        0        0    0
 21     8.7K        80s       1       1      no        0        0    0
 22    10.8K        46s       1       1      no        0        0    0
 23    13.6K         0s       1       0      no        0        0    0
 24    16.9K         0s       1       0      no        0        0    0
 26    26.5K        42s       1       1      no        0        0    0
 27    33.1K        71s       1       2      no        0        0    0
 29    51.7K        96s       1       1      no        0        0    0
 31    80.9K         0s       1       0      no        0        0    0

To be honest, I’ve encountered so many seemingly random issues with it. It’s possible.

I’ve had it magically correct itself, I’ve had it where clearing all the caches still gives a broken page until I keep clearing the caches, I’ve had it resolve itself only by restarting the memcached service.

I just disabled W3TC completely before deploying and had a broken page until I restarted memcached. Now I think that’s because the object-cache.php file still existed and was being used even though the W3TC plugin was disabled. Usually the plugin would remove that file, but I keep it around. So now I’m looking at testing some steps along the lines of:

• Disable W3TC plugin
• Restart memcached
• Manually remove page_cache files
• Deploy
• Restart memcached
• Enable W3TC plugin

Just to see what I can figure out.