Wether you are building a theme or plugin for WordPress, you will typically need to register and load your own Javascript or CSS file at some point. You do this by using the functions provided by WordPress core:

  • wp_register_style – Registers a CSS file
    wp_register_style( string $handle, string $src, array $deps = array(), string|bool|null $ver = false, string $media = 'all' )
  • wp_register_script – Registers a Javascript source (either local or external)
    wp_register_script( string $handle, string $src, array $deps = array(), string|bool|null $ver = false, bool $in_footer = false )

Defining a version

Both of these functions allow you to define a source URL and a few other arguments, but today we’re going to focus on the $ver argument. The $ver or ‘Version’ of your script or style allows you to append a version of your choice as a query string, for instance, these are a few examples from this site:


Both of the above examples have version numbers appended that reference the currently installed version of those plugins.

Why do we version our assets?

Versioning your assets is super useful for ‘busting cache’ when you release a new version. Modern browsers will cache CSS and JavaScript files locally to the visitor if the URL to the file is the same as it was the last visit. By appending a new version number when you update your theme or plugin, you’re effectively telling all visitors to the site that a new version of the asset is available, and it should re-download it. This prevents you from having to ask the dreaded question of “Did you clear your cache?”

What if I don’t define a version

You may also, from time to time, see plugins and themes have their scripts or styles contain a version that match the currently installed WordPress version, like this:


In this case, the developer would have chosen to not define a version when registering their styles or scripts. By providing no version, WordPress will append it’s own version.

Should we version external resource?

So what about assets that are external to your server? Things like 3rd party JavaScript resources. For example the Stripe payment gateway has store owners include a JavaScript file directly from their own servers. In this case you want NO version to be appended. Not your plugin’s, theme’s, or WordPress’s version. In this case you must pass in null as the version.

Ways do define your versions

  • String (Ex: ‘2.7.9’) – Results in ../style.css?ver=2.7.9
  • false – Results in ../style.css?ver=4.7.5 (where 4.7.5 will be the current WordPress version)
  • Not defined – Results in ../style.css?ver=4.7.5 (where 4.7.5 will be the current WordPress version)
  • null – Results in ../style.css

Why not use something other than the version?

There have been a few times that a person has asked me why not use something like a timestamp or the last time the file was changed to allow for version busting. While these do work to make sure the user isn’t getting a cached version, there are a few issues that arise.

Using Timestamps

When you use the current timestamp to set your version, that means every time someone visits your page, they’ll have to re-download your assets, since even 1 second later, your timestamp has changed from the last visit. While this helps by never having a cached version of the file, it can hurt your performance by making the user’s browser download files it’s previously downloaded, even though they have not changed.

Using file modification time

In the current space of hosting and multi-server configurations (even in some of the shared hosting world), file modification time could cause similar issues to timestamps. PHP has a function that allows you to get the last time a file was modified, and therefore, that would be the last time the CSS or JS file changed, in theory. All it really means is that’s the last time the file was modified on your servers. If you have a multi-server environment, each server could have a slightly different time that the file was modified, and therefore it’s possible that on subsequent visits to your site, a visitor would request the file from a different server and thus get a different ‘last modified’ time, requiring them to download the file again, even though it’s the exact same file they just requested.

Posted by Chris Klosowski

Chris Klosowski is the Director of Technology at Sandhills Development, LLC, creators of fine WordPress plugins, and ecommerce solutions.

One Comment

  1. I still see browsers like Chrome ignoring version numbers appended to the end of assets. Until recently they even recommended removing query strings from assets in their PageSpeed stuff, which makes me think they tend to ignore it since they’re encouraging people to use other methods. Personally I think Chrome’s cache is so aggressive it should be considered a bug.

    Anyway, one thing I think we should consider that I don’t see anyone doing is putting the version in the filename itself. When you release version 2.0 of a plugin, and the JS has changed, why not bump the filename? For example, stuff-2017-01-01.js. It would stay at that name until a change is made and when that is released it’s bumped to the release date, for example stuff-2017-06-09.js.

    While that’s a mildly annoying way to manage it, since you have to rename the file and update the filename in the register/enqueue calls, it ensures that browsers like Chrome don’t ruin your day with their buggy cache.

    It’s also worth mentioning Google recommends using this method, in addition to other caching techniques… which, along with my own observations of Chrome’s behavior, makes me think they’re purposely ignoring appended version strings as a reliably cache buster.


Leave a reply

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