Enqueue scripts and styles with automatic versioning

Once you’ve gotten past the point of inserting stylesheets and Javascript directly into your header or footer by enqueuing them, you’ve taken a huge leap forward in terms of putting things where they belong in WordPress.

However, no matter whether you’re inserting the files directly, or enqueuing them, one issue you’ll face is that once you change the file, caching can mean that the old version of the CSS/JS continues to get loaded unless you remember to change the version number of the file.

If you don’t supply a version parameter to either wp_enqueue_style() or wp_enqueue_script(), WordPress will default to enqueuing the file with a version number equivalent to WordPress’ version number which probably makes no sense. Your changes to these files are unlikely to be in sync with updates to WordPress, so either they’ll change unnecessarily when WordPress updates or they’ll not change when you need them to.

What you really want is to change the version number when you update the file. And one thing that we know will be unique each time you edit these files is *drumroll please*… the time.

Yes, every time you save your file the time is different from the last time you did it. So, I’ve started enqueuing my scripts and styles based on the time the file was last modified.

PHP has a handy function for this purpose: filemtime(). It returns the UNIX timestamp for the time the file was last modified.

I used to use YYYYMMDD as my version number for enqueued files, which was reasonably good, but caused issues when it changed more than once in a day and still meant having to remember to update the version number when changes were made to the file. An example of an enqueue might have looked like this:

My revised approach starts by creating a variable for the path of the CSS/JS file and then using filemtime in the version number instead of YYYYMMDD:

Now, instead of my enqueued files containing the WordPress version number, like this:

They look like this:

And I need never worry about the right version of the file showing up again.

Oh sorry lost track of this page. I made the original comment because i saw caching as well, but couldn’t find much information about the behavior in terms of how long it cached or how predictable that was. It happened enough for me to see that the version number wasn’t always updating.

I have a slightly different approach that i got from wpengineer, that uses a unix time stamp to continually update (up to the second) the version number whenever the page refreshes but only when debug mode is on, so that its only used when in development.

When debug is off it then reverts to static number i can manually update. Though i imagine the conditional statement that has the manual version number could be changed to just draw on php to generate the current date (or some other source) so that each time you turn off debug and push your site to a test environment or live you would have a new version number without having to manually intervene.

Wish your site was as fast as this?

Do It With WordPress is proudly hosted by WP Engine, the very best WordPress hosting that money can buy.

Aside from being blazing fast, it's very secure, has a staging area to test changes before making them live, automated daily backups, malware scanning, stellar support from WordPress experts... It's just everything that you would want from your host, and more.