Miraculously, there are magical variables you have access to (like your ENV vars) including one called $BUDDY_EXECUTION_ID which is a unique ID per deployment, so it’ll work great for cache busting. Within the settings for Find & Replace, we get to tell it what file to run it on, what to look for, and what to replace it with. I do recommend the Cloudflare plugin though and paying for the WordPress-specific optimizations they do though as they are pretty rad. It’s just for good measure, but weirdly, not that relevant here, as changing the HTML is enough to break the cache we’re talking about. The purge cache at the bottom there is for Cloudflare. But here we’ll add a Find & Replace setup first. A lot of times, I’ll have one action: just deploy the dang site. Just something fairly unique that I’ll have Buddy replace. So here’s my actual line of code in my header.php file on a WordPress site. I tend not to have a build process for WordPress sites ³. There is no processing there other than PHP itself ². So when do we need this?īut here’s my #1 use case: WordPress websites.Ī WordPress website produces HTML from PHP templates. Or even if there is some kind of HTML processor in place, it doesn’t have an auto-incrementing cache buster automatically in place. I have worked on lots of websites that don’t have anything processing the HTML. To me, assuming that HTML (via PHP or not) will be processed is a fairly big assumption. At the end, I'll do a Find & Replace on the cache busting string in the PHP file. Then I'll do a bunch of stuff to them when they change.ĬacheBust("./parts/footer-scripts.php", "./parts/") Gulp.watch(LOCATION_OF_SCRIPTS, doScripts) For example, I'll set up a watch task for scripts That’s bad.Ī classic easy way to break cache is to add a query parameter: That’s worse than a failed deployment, it’s almost like a half/broken deployment because it’s likely HTML has also changed that no longer correctly corresponds to the updated CSS. So when I need to change that file, I need to break that cache, otherwise, users’ browsers that have already been to the site will hang onto their old version of file. ![]() So if I check the response headers on a file like that, I’ll see something like: cache-control: public, max-age=31536000 ![]() That’s a no-brainer day-one kind of performance requirement. I’ve got my server/CDN set up to cache the living bejesus out of that file. That’s all we are doing here, and Buddy offers that feature. But it always requires a little more technology than I would like, like setting up Gulp or the like. I’m quite chuffed with this! I’ve been solving this in different ways for a heck of a lot of years, in situations where asset cache busting isn’t part of whatever site building situation I’m in provides so I need to do it myself.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |