Last modified: 2008-05-05 03:34:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12775 - Changes in global CSS/JS do not apply - unable to purge site CSS/JS
Changes in global CSS/JS do not apply - unable to purge site CSS/JS
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: High major with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks: javascript css
  Show dependency treegraph
Reported: 2008-01-24 13:30 UTC by Danny B.
Modified: 2008-05-05 03:34 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Danny B. 2008-01-24 13:30:36 UTC
If any change done to site CSS or JS it does not apply at all.

I've tried to do all the purge methods I know, cleared all caches, tried in 10 different browsers, nothing worked.

So far I seen on #mediawiki, #wikimedia-tech and some other channels, other users have similar problems as well.

This is pretty big problem because it causes users can't use new CSS/JS features, which is really way so annoying. It used to be able just to simply reload the CSS/JS page to load the new script and it was available at the moment.
Comment 1 Splarka 2008-01-24 13:39:39 UTC
This is due to 27456 forcing a server-side cache (set to 5 minutes on Wikimedia) to all raw pages (all User/Site Css/JS). This was apparently done by domas so that anonymous users who shift-reload pages all the time (why??) would not re-request all the raw pages from the apache back-ends every time.

Due to this, it is impossible to reload a squid-cached URL before it expires, and it also cannot be purged. The only way to guarantee a cache miss is by changing the URL.

I've seen a dozen user complaints about this already, and personally experienced a frustrating edit session of my user/monobook.js, taking 5 minutes to load each change.

This should be reverted until a solution is found to address the agressive caching of user and site-wide css/js. Perhaps a dummy URL parameter reflecting the last edit of the page, or a squid parameter fragment like &purgeme that would purge the preceeding URL minus the fragment, or a rawpurge=true sent via POST.
Comment 2 Splarka 2008-01-24 13:41:04 UTC
> This is due to r27456 (linky)
Comment 3 Splarka 2008-05-05 03:34:18 UTC
Someone did something sometime in February that pretty much fixed this bug at the squid level (tim, brion or domas IIRC).

The problem was in a hack that prevented the servers recognizing "Pragma: No-cache" headers from clients, making all pages hard-cached for up to 5 minutes. Or something.

Note You need to log in before you can comment on or make changes to this bug.