T4ng

Hi @vmarko,

Here is my page cache config page screenshot.

Can you please clarify why these 30 seconds?

Thank you

• This reply was modified 1 year, 4 months ago by T4ng. Reason: Adjust screenshot link

Hi @jamieburchell,

What you’re explaining here makes sense: if after clearing the W3TC page cache, the old html version is still served for 30 seconds, then there’s a good chance this leads to problems.

@jamieburchell , have you tryed remonvend this 30 seconds availability instruction from the code, to see if it makes any difference at all?

@vmarko we haven’t heard from you for a while on this topic, while your input could be really useful.

• Can you please explain why the HTML remains available for 30 seconds after clearing?
• Do you think, based on our finding, there’s a chance this is what causes this issue?
• If so, is there an option/solution/idea of a workaround, to suspend it?
• Maybe there’s something here, that’s worth a chat with Elementor?

Thanks

OK. Then, one thing that’d worth a try, would be to maintain Elementor’s CSS, which is obviously cleared along the object cache?

• This reply was modified 1 year, 4 months ago by T4ng.

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 1 year, 4 months ago by T4ng.

OK I see.

Please keep me posted with your findings 🙂

@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 1 year, 5 months ago by T4ng.
• This reply was modified 1 year, 5 months ago by T4ng.