On Wed, Nov 28, 2012 at 11:40 PM, Samat samat78@gmail.com wrote:

On Wed, Nov 28, 2012 at 11:31 PM, Bináris wikiposta@gmail.com wrote:

...

2012/11/28 Samat samat78@gmail.com

...

Hi,

I am the only one, who see this (in attachment) on the top of WMF's Main Page (https://wikimediafoundation.org/wiki/Home)?

The same thing is happening in Wikidata, see https://www.wikidata.org/wiki/Wikidata:Project_chat#Dafuq.3F and the main page.

-- Bináris

Thanks!

Something happened, because it works well for me now.

Samat

But Meta-Wiki doesn't... https://meta.wikimedia.org/wiki/Main_Page

Samat

Is there a reason not to use the Yahoo championed approach of embedding a version number in all static file names so you can set a very long cache expires time and just add new versions to the CDN when a change is made?

I don't know how often our CSS, branding images, scripts, and other static content change, but there would not be much effort in adding that to a deploy process and there must be developer overhead being incurred in trying to keep new code backwards compatible.

Luke Welling

On Wed, Nov 28, 2012 at 5:52 PM, Platonides Platonides@gmail.com wrote:

Code was updated to use <h3> while the (cached) skin CSS still had <h5>

See

http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/0000...

Note: code was reverted to wmf4, so the problem will appear now in the reverse.

We should use an intermediate CSS with rules appliying to portlets no matter if they are h3 or h5. Then migrate again in a few days.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Wed, Nov 28, 2012 at 4:21 PM, Chad innocentkiller@gmail.com wrote:

On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling lwelling@wikimedia.org wrote:

...

Is there a reason not to use the Yahoo championed approach of embedding a version number in all static file names so you can set a very long cache expires time and just add new versions to the CDN when a change is made?

That's what we used to do for CSS/JS--but we don't serve individual files like that anymore--they're all served together via the resource loader.

ResourceLoader actually uses a somewhat more advanced version of the

version-number-in-filename approach: it dynamically computes the last modified timestamp of the collection of resources it's requesting, and puts that timestamp in the query string. If the timestamp is not available dynamically, we omit the timestamp, and RL automatically serves the resource with a short cache timeout (5 min) in that case.

Also, it wouldn't have helped much in this case--the problem was that the HTML/CSS output changed in an incompatible way and we had old (or new, during the rollback) versions of the HTML still being served via Squid (they're cached for 30 days, unless something purges them like an edit).

"Don't change the HTML in incompatible ways" is probably a good general rule to live by--but having an easy way to say "start purging all pages on $theseWikis from Squid/Varnish" would also be nice.

Yes, the HTML and CSS changed in incompatible ways. The CSS cache

invalidated quickly (5-10 mins probably), but the HTML cache didn't. Platonides probably misspoke when he said "cached (skin) CSS had <h5>"; I'd imagine it was the Squid-cached HTML instead.

Either way, the CSS should be backwards-compatible with the old HTML, and in this case it wasn't. That's the core of the problem.

Roan