Last modified: 2014-07-14 20:51:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48956, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46956 - HTML versioning information needed in skins to be able to cleanly make incompatible CSS changes
HTML versioning information needed in skins to be able to cleanly make incomp...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Bartosz Dziewoński
Depends on:
Blocks: 27292 46947
  Show dependency treegraph
Reported: 2013-04-06 17:25 UTC by Bartosz Dziewoński
Modified: 2014-07-14 20:51 UTC (History)
11 users (show)

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


Description Bartosz Dziewoński 2013-04-06 17:25:48 UTC
In the Wikimedia setup generated page HTML is cached for ~30 days regardless of skin HTML changes, while CSS&JS is purged at most a few minutes after a change is deployed. 

This is a highly suboptimal situation, as this means that in every change that modifies both the HTML and the CSS, the CSS must be backwards-compatible with old HTML. This requires a lot of care and additional awkward testing and causes major issues when not done carefully enough (e.g. bug 42452), and sometimes just isn't possible at all unless some transitional hacks are inserted (e.g. bug 46947).

Luckily this isn't an issue for most third-party wikis, as `php update.php` after upgrade purges the cache entirely.


I'm proposing adding another class to <body>, "skintimestamp-YYYYMMDD", where YYYYMMDD is the year, month and day of the time that given skin's HTML was last modified in an incompatible way. Day should be enough granularity to avoid conflicts while keeping the class name short enough.

This can be easily done using the addToBodyAttributes() method of the Skin class. The timestamp would be updated manually by whoever is making those changes, and the class could be used in the CSS to only apply new styles to newly generated HTML. Older styles could be simply left intact, and then removed after enough time has passed.

If multiple incompatible changes are ever done in overlapping time periods, the successive ones would include updates to the "old new" styles to use both the new and old class.

Comment 1 Bartosz Dziewoński 2013-04-07 11:13:32 UTC
[Mailed wikitech about it, let's discuss there: .]
Comment 2 Krinkle 2013-04-10 06:44:58 UTC
I don't believe this is a feasible or viable way to solve this problem.
Comment 3 Bartosz Dziewoński 2013-04-11 09:36:30 UTC
It's certainly more feasible than reimplementing it every time we make incompatible changes. I agree it's a little unclean, but IMO it's the best we can do with the caching setup at WMF. Have you got any better ideas?
Comment 4 Roan Kattouw 2013-05-10 18:44:50 UTC
(In reply to comment #2)
> I don't believe this is a feasible or viable way to solve this problem.
It seems reasonable to me. Could you be more specific about your objections? Right now this just reads as "No, and I won't tell you why, just no."
Comment 5 Isarra 2013-10-08 05:51:06 UTC
What Roan said.
Comment 6 Isarra 2013-10-08 05:51:38 UTC
Wait, wrong bug, nevermind.
Comment 7 Jon 2014-07-14 20:51:19 UTC
I think this idea has a lot of merit and although I'm not a 100% sure I think it could potentially. Although rather than using timestamp, I wonder if it would be better done as a version number of the skin itself.

This way if someone needs to make a change that supports something in an old skins they can do:

.skin-vector-v2 h2 {
 // old skin styles

h2 {
  // new skin styles

Krinkle would be interested in a reply to Roan..

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