The below isn’t really about WPPizza in particular but WordPress in general, and I feel the need to state why removing version numbers from WordPress javascript or css files – either by some custom filtering, using some plugin or even having this kind of thing in-built into your theme – is just a very bad idea in my opinion.

The 2 main arguments are usually as follows:

Removing version numbers makes my site more secure as nobody knows what version of WP is running

• Sorry, but this simply isn’t the case. Maybe it was once upon a time in ancient times, but with the tools available these days it really is childsplay to find out what version of WP you have running, regardless of whether or not you have removed the version number. Furthermore, security by obscurity never was and never will be the right approach to securing anything.

It will allow browsers to cache the javascript and css resources

• First of all – though that may not be true for *all* browsers on the planet – browsers these days are clever enough to serve cached resources if the full source url (incl any parameters appended) has not changed. Even more so, if the server has been set up to explicitly set an expiration time for those resources via .htaccess or via other means.

  More importantly though, YOU DO NOT ACTUALLY WANT js/css files to be served from cache when they have changed.

Consider the following:

• – “User A” goes to site the first time and does his/her thing. While he/she is there the js/css files are being cached in the users browser and served from cache while the user is navigating the site. That’s all good.
• – At some point, after the visit of “User A” previously, the administrator of the site, being on top of things, saw there are updates for plugins/themes available and therefore updated the plugins/themes to the latest version to know the site is running the latest and greatest.
• – A few hours later, “User A” returns to the site to do some more research or buying more products or whatever the site offers.
• – However, version numbers were removed from the css/js files, so the browser of “User A” says: “Cool, I just use the css/js from my cache as it’s still the same file”, except, it isn’t the same file anymore as the plugin was updated and there’s a good chance the js/css files were too, so the cached js files will not work with the functionality of the updated plugin and it all falls over and things break. If the version number would have still been appended, the browser would have known it’s a different/changed file and would have downloaded – and subsequently cached – that new file…..

You might even break styles/scripts entirely (depending on how version numbers are removed)

• There are various jquery-ui and other components that are inbuilt into WP and you can load as required.
• So you could do this, to load the ‘jquery-ui-spinner’ $ui = $wp_scripts->query('jquery-ui-spinner');
• If I want to use the associated ‘smoothness’ theme, i’d additionally want to load the following css //ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/themes/smoothness/jquery-ui.min.css
• The problem is, that, to get the right associated version in practical terms – in this case 1.11.4 – you would write something like the following//ajax.googleapis.com/ajax/libs/jqueryui/".$ui->ver."/themes/smoothness/jquery-ui.min.css
• However, as version numbers were removed, that css url will now look like this //ajax.googleapis.com/ajax/libs/jqueryui//themes/smoothness/jquery-ui.min.css which will produce nothing but a 404 and an entire stylesheet is missing from your site

Of course, I do not claim to be the ultimate reference regarding the above and there may well be ways to remove version numbers more selectively or other ways to avoid the above scenarios.
The above is only a summary as to what I have seen being done countless times and wanted to share this here to make people think twice about doing this or if they choose to do so to be aware of the possible consequences.

Thanks for reading…..