[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