On Sun, 25 May 2014 00:53:09 +0200, Daniel Friesen <[email protected]> 
wrote:

On 2014-05-24, 10:49 AM, Bartosz Dziewoński wrote:
I'm sorry, but this is very silly reasoning. Cache is not forever
anyway, and ResourceLoader includes cache-busting timestamps in URL
queries for each resource that goes through it (including the ones
that are not embedded in CSS, and the fallbacks for data: URIs).
Changing the URL is not a problem at all as long as we're not doing it
every other day.

It's not my most important point, but just a few notes since you replied.
 * Just a few strict fact corrections:
      o The .htc doesn't get cache busted.
      o addStyle, etc... are cache busted by $wgStyleVersion not RL.
      o CSS contents in RL get cache busters, but the load.php calls
        themselves for skin resources don't.
  * The "cache" problem isn't just an issue of things unnecessarily
    being purged. Remember WMF's 30 day cache issues. Unless the wmfX
    number is already something that would be changed with two copies
    being simultaneously deployed the vector -> Vector path change
    triggers the issue of old cached pages pointing to

A few notes of my own, then, if you're nitpicking. :)

Yes, some resources do not include the timestamps in query. I've only mentioned 
the ones loaded via ResourceLoader. load.php calls would not be affected by the 
directory name changing and thus are not relevant.

WMF hosts each deployed version in a separate directory, changing 
$wgStyleDirectory (or doing some similar magic) to change the references in the 
pages. (Here's an example link to a resource: 
https://bits.wikimedia.org/static-1.24wmf5/skins/common/images/poweredby_mediawiki_88x31.png
 – note the version number is included, this will go down in a few weeks as the 
versions are cycled.) This way old cached pages will never point to new version 
of resources and vice versa. (The old directories are kept long enough not to 
break anything – at least 30 days, like you said – and generally deleted in 
bulk every few weeks.)

--
Matma Rex

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to