[wp-trac] [WordPress Trac] #29201: File versioning should not use query strings, but rename the filename to allow caching
WordPress Trac
noreply at wordpress.org
Fri Aug 22 10:12:17 UTC 2014
#29201: File versioning should not use query strings, but rename the filename to
allow caching
---------------------------+------------------------------
Reporter: benoitchantre | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Script Loader | Version: 3.9.1
Severity: normal | Resolution:
Keywords: | Focuses:
---------------------------+------------------------------
Comment (by fsvm88):
Hello,
I am a systems administrator and programmer.
I spent the last three days helping my girlfriend (web designer) working
out issues with CSS and JS file loading.
In my opinion a CMS is not a cache, proxy or VCS, that's why I think
*versioning* static resources *is conceptually wrong*. It makes effective
cache use and configuration much more troublesome, which causes more
complexity, and thus (in general), problems.
Another common approach to solve the "make the new file available to
users" is by cachebusting. This is done by generating some sort of
fingerprint to identify the file, and publishing the file with the
fingerprint in its name (not the extension).
Usually, a hash or a timestamp is used. An hash is preferable because it
is based on content rather than filesystem metadata like a timestamp
(which can, at times, be incorrect, since some systems disable access time
updates for example).
Rather than requiring an .htaccess/nginx configuration change, it probably
would require some sort of server-side caching to be available in order to
avoid copying/hashing the files at each page request.
I honestly don't know if WP already has some sort of internal caching
(temp directory?), but in that case it could be effectively leveraged,
copying the already-named files in place. It would be necessary then, to
implement an automatic cache flush whenever a style/script gets updated
(either by WP editor or by FTP, for instance).
I also think that such a feature should be allowed to be disabled until
it's implemented correctly (which I think it's the shortest road to put
users in control).
Anyway, there are already well supported and maintained plugins (like W3
Total Cache), that handle the cache problem very well. It may be worth to
let these handle the task instead.
I digressed only because I think the current approach is conceptually
wrong. It's not about versioning, but rather about publishing the latest
file, which is a different thing. Versioning should be done with a proper
VCS.
Thank you for reading through this. :)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29201#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list