Last modified: 2011-02-08 21:56:02 UTC
Changes to system message articles MediaWiki:common.css and MediaWiki:common.js (and all similar articles) should go "live" immediately for all users when the article is saved. Right now, due to browser caching, changes aren't seen by users potentially for hours or days. Asking thousands of people to hard-refresh their browsers isn't a good solution. Could this be solved easily by appending the article revision ID to the style tag, e.g., changing this: @import "/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000" to: @import "/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000&revision=123456" or some such trick, to tell the browser to reload the CSS or JS?
That fix would require us to invalidate every single page cached in Squid. This is not acceptable. The only possible option is to not cache the site CSS/JS and have the client check for a 304 on every request. This is what we do for images -- I don't know if it would be worth it for site CSS/JS.
Any other implementation is fine, as long as the end result is the same (JS & CSS changes go live immediately). Also, if it's a problem for Squid, then make the feature optional with a default value of "disabled" (e.g., $wgCssJsCacheUpdatesImmediate = false). Not all MediaWiki sites run Squid... we don't.
(In reply to comment #2) > Any other implementation is fine, as long as the end result is the same (JS & > CSS changes go live immediately). Well, it's not clear if any solution other than the present one is desirable for Wikimedia, at least. > Also, if it's a problem for Squid, then make the feature optional with a > default value of "disabled" (e.g., $wgCssJsCacheUpdatesImmediate = false). Not > all MediaWiki sites run Squid... we don't. That's a fair point, yeah.
This change might not have immediately value for Wikimedia (due to squid), but I can tell you, after running several MediaWiki installations for several years, this issue causes so much trouble. We release a change that relies on (say) MediaWiki:Common.js, and it breaks for everyone who hasn't hard-refreshed their browser. The alternative is never to use MediaWiki:Common.js... but it's such a convenient feature, if only it could be relied upon.
Versioning in the URLs as suggested would be an improvement over current refreshing practice, if not necessarily a complete solution for every page view ever (eg, if you load an old cached page it still references the old cached CSS). Edit timestamp or revision id for the page might work; check that it can be done without extra DB queries.
What about using a BagOStuff as a write-through cache for the greatest revision id on any *.css or *.js in the MediaWiki namespace? That way, sites employing memcache would avoid the DB hit. > > Edit timestamp or revision id for the page might work; check that it can be > done without extra DB queries. > Do you mean, the article being viewed, or the *.css/*.jss "page"?
See also bug 8433.
This is fixed in ResourceLoader. Changes to MediaWiki:Vector.css take effect immediately after saving on my dev install, and should take effect within 5 minutes after saving for other users.
