renesis4 wrote:

Shouldn't there be a MediaWiki namespace way of updating this, so we don't have
to persuade a developer to change the parameter every time?

titoxd.wikimedia wrote:

That's the issue - looking at the HTML source of a rendered page, the CSS does not have any way to be purged
remotely, even by developers.

robchur wrote:

An alternative would be to append the timestamp of the current revision of the
CSS page to the URI which causes it to be included. This would be similar to how
$wgStyleVersion works, and wouldn't require administrators to remember to update
a second message with each customisation.

titoxd.wikimedia wrote:

That works, although I worry about issues with admins modifying whitespace or doing other trivial changes. Those
could have a harsh impact on server load... :(

robchur wrote:

Something I didn't mention, of course, is something which Brion phrased
effectively: "that implies you know it, in which case you're doing several extra
database lookups for every page view".

titoxd.wikimedia wrote:

Hmm... that implies you know the timestamp of the latest version? (I'm not sure
if I understood)... that could be written on memory somewhere. In a way, it
seems ok that if a change to a skin CSS file was done within a wiki, the number
should be changed manually only if the impact to the appearance of the site is
bad enough...

ui2t5v002 wrote:

Shouldn't this just happen when someone edits [[MediaWiki:Common.css]]?

mets501wiki wrote:

Definitely. It's worth the extra server load for everyone to see the same
display. It should happen when [[MediaWiki:Common.css]],
[[MediaWiki:Monobook.css]], [[MediaWiki:Common.js]], and any of the other
skin-specific css's and js's are updated.

robchur wrote:

(In reply to comment #7)

Shouldn't this just happen when someone edits [[MediaWiki:Common.css]]?

The problem is *making it* happen.

titoxd.wikimedia wrote:

Again, can't the timestamp be stored in the message cache? Or another message
stored in the cache, like I suggested originally?

md5 wrote:

This ticket has been open for quite a while, so I'm wondering if there is still interest in getting this to happen. I would definitely love to see this happen since the Wikimedia caching strategy can make any site-wide style changes a time-consuming process. I've seen multiple instances on both Wikipedia and Wiktionary where inline styles were left in templates to force client displays to look correct for the month or so that we have to wait to be sure that all users caches have caught up.

If we can come to some agreement as to the mechanism, I have no problem providing a patch for this.

md5 wrote:

Just following up on this ticket again, it seems like Titoxd's suggestion would be workable. Is there a reason that solution wouldn't work?

Should work, in theory.

Note a general issue with the use of version markers on style URLs like this: the updated version marker bumps the URL to ensure that any *newly* rendered page, with the new URL, will show up with a fresh copy of the new external resource.

Older cached HTML (eg, cached pages for anonymous visitors) will still include the older URLs as long as they remain in cache, so will get the older resource as long as _that_ also remains in cache.

So while this will guarantee bumps for logged-in users who are always bumping their own cache invalidation timestamps, and for newly-changed pages, it *won't* push the updates to every page everywhere at once.

emil wrote:

a patch to purge site css after edit

A simple patch that causes a skin css to be purged after an edit.

Note that there may be required some changes in your Squid config too.

Attached:

See also bug 17524

ResourceLoader takes care of this, see also bug 17524