the prevent caching of objects after settings change sets a consistent query string for all assets using a datestamp rather than the varying system used by different plugins and WP itself – disabling it doesn’t remove the query string at all, it just doesn’t override the default set by WP or other plugins
Anthony, thanks for your response.
Then how would I removed the query strings?
Specifically, my query strings look like this:
/wp-content/plugins/jetpack/modules/sharedaddy/sharing.css?ver=2.5
/wp-includes/css/admin-bar.min.css?ver=3.6.1
/wp-content/plugins/anti-spam/js/anti-spam.js?ver=1.9
…etc.
EDIT: Also, doesn’t that go against what the author already pointed out here?
http://wordpress.org/support/topic/plugin-w3-total-cache-remove-query-string-from-static-content
I,m wondering about this as well, I have never seen this issue before on any of my sites might have to do something with the recent update. Anyways I have looked everywhere trying to solve this issue but no luck..
those will be set in a variety of places
- core wordpress
- plugins
- themes
You would have to modify the various plugins and hookin to the core javascript embeds to disable the JS/CSS includes, then manually re-add them without the version headers
or take a look here for a quick fix: http://www.sharepointjohn.com/wordpress-remove-version-query-strings-from-javascript-js-and-css-stylesheet-files/
its not really worth the time and energy IMHO – query strings don’t pose as many issues for caches as they used to do – and a question to ask, how many of your sites users are likely behind proxies where this “might” be an issue?
what Frederick pointed out in the other post is related to the query string W3TC sets – when that option is enabled W3TC will set a single consistent query string for as many static resources it can (if not all) which is very good when working with CDN’s – especially those that charge for purges (like cloudfront)
