Missing stylesheets referenced in HTML – race condition?

Hello @jamieburchell

Just letting you know that wea re still trying to replciate the problem and understand this because from the point of page caching it does not make any scense.
Thank you for your patience.

@jamieburchell

Can you tell more about the server setup under which you face this behavior?

We’ve already narrowed it to the use of W3TC’s page cache only (amongst W3TC caching options). And in my case, after a deployment.

Here are the steps of our CI/CD process. I think there’s something there since only our environments running this CI/CD face this broken pages issue. And in case it helps, these are both Plesk servers.

a. Server stop

1. Activate maintenance mode
2. Flush all W3TC caches (through wp-cli)
3. Stop php-fpm daemon
4. Flush php Opcache
5. Clear nginx cache (which is used as reverse proxy for the assets
6. Deploy the code changes (mostly plugin updates)

b. Server restart

1. Clearing wp-cli cache
2. Start php-fpm daemon
3. Flush php Opcache again (just in case)
4. Updating WordPress core database // wp-cli core update-db
5. De-activate maintenant mode
6. Adjust folder permissions and ownership
7. Flushing W3TC caches again (just in case)
8. Deleting Opache directory content
9. Flush WordPress cache // wp cli cache flush
10. Running pending WordPress Crons

Then W3 Total Cache starts preloading pages through a server cron job (instead of WP Cron, which is deactivated)
ps -eo pid,ppid,args | grep pgcache_prime | grep -v grep > /dev/null || (test -e /var/www/vhosts/[…]/wp-cli.sh && /var/www/vhosts/[…]/wp-cli.sh w3-total-cache pgcache_prime)

Then we get Elementor broken pages after every deployment, both on our live website, and on an IP restricted staging environment (so no external trafic).

This never seem to happen when there’s no cache preload is disabled.

• This reply was modified 4 weeks ago by T4ng.
• This reply was modified 4 weeks ago by T4ng.

We use PHP Deployer, which is a symlink based deploy tool. We also use Roots Bedrock for the WordPress installations, but that’s not particularly relevant here other than the file paths are slightly different and there’s a nice .env file to manage configs.

The deployment task goes something like this:

• Connect to the server (SSH)
• Checkout the source code repo of the website in to a new release directory
• Run composer install in that directory (brings in WordPress core, plugins, etc.)
• Symlink shared directories like wp-content/{uploads, cache, upgrade, wflogs} etc.
• Symlink shared files like .env (wp-config.php basically)
• Swap out the “current” release with the new release, which basically means changing the symlink to point to the new release
• Clear opcache and stat cache (uses cachetool)
• wp core update-db (WP-CLI)
• wp elementor-pro update db (WP-CLI)
• wp elementor flush_css (WP-CLI)
• wp w3-total-cache flush all (WP-CLI)

Then voilà! A broken website (sometimes).

Edit: I notice that you mention clearing the Opcache directory. Incidentally, we ran in to segfault issues with PHP when enabling Opcache files, so we don’t use that feature anymore. We still use Opcache though.

Anecdote two, I spent half a day (of leave) fighting with another cache related issue – nonce values output in the HTML being cached by the page cache which outlive their expiry. That was a fun issue to track down.

Hi @vmarko ,

Does it help?
Are these feedbacks informative, or do they give you research directions?

@schwipps One thing I noticed recently when the page was broken was that restarting the memcached service resolved the issue. I don’t think it was a coincidence as I encountered this a couple of times. Even when the memcache component is disabled in W3TC, I still have the object-cache.php file present (because I don’t allow plugins to remove files here) so it’s possible it’s still getting used. Might be the same for you if you are using Redis for object cache?

@jamieburchell,

Thanks for investigating further.

Interersting. I’ll ask our developer. But if there’s something to clear here on our side, I will check how the cache behaves when preloading the pages again. I’m afraid I get some more broken pages again (same as when I clear the cache).

One more question for you: sometimes (not always, of course…), when I face broken pages, another issue is that purging specific pages has no effect. So that I just can’t solve my broken pages, unless I purge ALL pages. But then I get other broken pages. Nightmare…

Do you also have this issue?

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

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.

OK I see.

Please keep me posted with your findings ??

@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

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

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

Surprizing, indeed…

I have no idea what happens under the hood. Only @vmarko might know…

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

Hi @jamieburchell,

I’m not sure to understand what you suggest.

Do you ask if I can request Elementor’s CSS regeneration, during the deployment process?

With something like this?

• This reply was modified 2 weeks ago by T4ng.