I've now centralized this in a single global
config var, $wgStyleVersion. Bump
this whenever making changes to .css or .js files in the core distribution. When
adding new such files, don't forget to include "?$wgStyleVersion" on the
link.
For those not familiar with the technique, this is an easy way to make style
updates cache-friendly. Newly rendered pages which depend on the new styles will
include the links with the bumped number -- the query string is ignored by the
server (which is reading a static file) but the client will consider it a new
URL and so pull the file fresh instead of using the previous cached version.
We had been using this haphazardly; now just bumping that one var in
DefaultSettings.php will bump all imported styles consistently, so it's harder
to forget something.
Just thinking aloud here, but what if the $wgStyleVersion string was determined
automatically by MediaWiki?
For example, for a stable release, it could use the $wgVersion string as the
$wgStyleVersion (and even though there'd be some
erroneous cache-misses on a stable version upgrade, it wouldn't be a big deal, because
stable version updates happen relatively
infrequently). And in an SVN-tracking environment it could perhaps do something like '
max( "committed-rev" string in .svn/entries
for skins/common/wikibits.js, "committed-rev" string in .svn/entries for
skins/monobook/main.css, and so forth for the list of
CSS/JS files) '. ( In other words, something sort of semi-similar to the way that the
version string in [[Special:Version]]
automatically displays the SVN revision number for a development tree, or just the
$wgVersion for a stable install. )
The upside is that there'd be one less thing for us fallible humans to have to
remember (and predictably forget).
The downside though is doing it in a way that doesn't kill performance.
All the best,
Nick.