Versions and Cache

In development, we all have small tricks to make our lives a little more comfortable. Solutions for issues we’ve learned a long time ago. Something we use without thinking about them anymore. We assume everyone knows these tricks but they don’t. And that’s okay, you probably use some tricks that I don’t know yet. That’s why I think it’s important we share these tricks with each other. Hopefully all our (development) lives will become a little more comfortable.

Could You Please Clear Your Browser Cache?

Just the other day I shared one of these tricks regarding browser cache with one of my customers in Never5 support. I’ve lost count on the amount of times I’ve asked clients to do this. Before I created products, I used to create websites for clients. And whenever I changed something and asked them to check, they wouldn’t see the changes I made due to their browser cache. I knew I wasn’t the only one with the issue because there are complete websites dedicated to explain how to delete your browser cache.

How WordPress Handles Versions

When I started getting more serious into product development, I noticed something after a while. I didn’t have to ask the users of my plugins to clear their browser cache after they’ve updated my plugin. When looking in why this was the case, it was beautifully simple.

You see, if you enqueue your assets correctly in your plugin or theme, you pass a version with it. The version you should pass is your plugin’s or theme’s version*. When WordPress loads your assets, it adds the following GET parameter to the asset URL ?ver=the_version_you_passed

* It’s good to keep this version in a variable somewhere so you don’t have to update it in a ton of places every time you release an update.

Because the asset with this GET parameter isn’t set in the browser cache yet, you force the user’s browser cache to reload the asset. I remember doing this before I was using WordPress to invalidate caching while testing. By adding GET variables like ?t=1 to the URL, I’d force to load an uncached version of the page. It’s so simple, yet so effective.

Start Using Versions

Now that I, as a plugin author, need to use proper version is something that hopefully does not require much explanation. But many people that create websites for clients never update the version of their custom developed theme. I notice we’re getting at the point where a lot of people are using child themes instead of editing the theme itself, which is great! But they give the child theme version 1.0(.0) and just leave it at that.

Using proper versioning for the child themes you develop for your clients not only saves you the trouble of having to ask them to clear their browser cache after every change. It also makes sure their visitors see the latest and correct version of the website. Because if the visitor been on the website before, their browser might have cached parts of it. Not having proper versioning might display an outdated website to them, or worse break it completely.

Related Posts

Powered By Related Posts for WordPress
Click Here to Learn More About Related Posts for WordPress

6 thoughts on “Versions and Cache

  1. So if you change the version fo your child theme, your website get’s ‘auto-cache-cleared’?

  2. Another great way to clear cache is to append a hash of the file as a get parameter. That way a new version of the file only gets requested once the content actualy changes. Especially nice if you’re dealing with async dependancies.

  3. Great articles, first of all Thanks for writing such lovely Post! Earlier I thought that posts are the only most important thing on any blog. But here a Shout me loud found how important other elements are for your blog.Keep update more posts..

  4. That’s a great point, Barry!

    I noticed that WordPress isn’t adding the Last-Modified header which would allow browsers to re-use the cached HTML. Probably because it’s hard for WordPress to know if anything has actually changed or not (dynamic content, widgets, etc).

    So my idea was to introduce a global content version number which is increased every time a post, page, comment, term or menu item is updated. I have implemented this in the Cache Version plugin.

    It is important to note that the web server has to be able to respond with the appropriate 304 status code which should normally happen when any kind of full page caching is used. This is also why I’m keeping the plugin on GitHub 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *