Chris Worner
Well-known member
- Joined
- Apr 15, 2016
- Messages
- 630
- Points
- 28
Spent an hour last week convinced a deploy had not gone out, when the file on disk had been correct the whole time. Four separate things were holding the old version and each one cleared differently.
OPcache is the first and the one that catches people, because it fails silently. With validate_timestamps off in production, PHP keeps serving the compiled copy of the old file until the process restarts or you clear it on purpose. Nothing in the site tells you that is what is happening.
Then whatever the application caches itself. On WordPress that can be a page cache plugin writing static HTML, an object cache in Redis, and a separate CSS cache if a page builder is in play. Three different clear buttons, and clearing one does not touch the other two.
Last is the CDN, and that is the one that makes you doubt your own eyes, because someone on another connection sees the new version while your nearest edge keeps handing you the old one. I settle it now by requesting the page on the server itself over 127.0.0.1 with the Host header set. If that comes back new, everything from the application down is fine and the problem is purely edge.
Order matters on the way out: innermost first, or you refill the outer cache from a stale inner one and get to do the whole thing twice. Has anyone automated this across a mixed fleet, or is it still a per-stack script for everyone?
OPcache is the first and the one that catches people, because it fails silently. With validate_timestamps off in production, PHP keeps serving the compiled copy of the old file until the process restarts or you clear it on purpose. Nothing in the site tells you that is what is happening.
Then whatever the application caches itself. On WordPress that can be a page cache plugin writing static HTML, an object cache in Redis, and a separate CSS cache if a page builder is in play. Three different clear buttons, and clearing one does not touch the other two.
Last is the CDN, and that is the one that makes you doubt your own eyes, because someone on another connection sees the new version while your nearest edge keeps handing you the old one. I settle it now by requesting the page on the server itself over 127.0.0.1 with the Host header set. If that comes back new, everything from the application down is fine and the problem is purely edge.
Order matters on the way out: innermost first, or you refill the outer cache from a stale inner one and get to do the whole thing twice. Has anyone automated this across a mixed fleet, or is it still a per-stack script for everyone?
