WMF's webpage

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

WMF's webpage

Samat-2
Hi,

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

Best regards,
Samat

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

wmf_webpage.png (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Bináris
2012/11/28 Samat <[hidden email]>

> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Samat-2
On Wed, Nov 28, 2012 at 11:31 PM, Bináris <[hidden email]> wrote:

> 2012/11/28 Samat <[hidden email]>
>
> > 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Samat-2
On Wed, Nov 28, 2012 at 11:40 PM, Samat <[hidden email]> wrote:

> On Wed, Nov 28, 2012 at 11:31 PM, Bináris <[hidden email]> wrote:
>
>> 2012/11/28 Samat <[hidden email]>
>>
>> > 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Platonides
In reply to this post by Samat-2
Code was updated to use <h3> while the (cached) skin CSS still had <h5>

See
http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/000093.html

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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Krinkle
In reply to this post by Samat-2
On Nov 28, 2012, at 11:29 PM, Samat <[hidden email]> wrote:

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

Looks like that one got purged in the mean time. I currently see it on:

https://wikimediafoundation.org/wiki/FAQ/en

This is caused by the recent change to the headings in the Vector skin.
They were changed from h4/h5, however the CSS used those tags to identify them (instead of using css classes). Which means, as expected, that the page layout breaks for up to 30 days.

Page cache is controlled by the wiki page content. Unless the page is modified, the cache is kept for up to 30 days for anonymous users.

Resource modules, however, are served by ResourceLoader which has its own much more efficient and deployable cache mechanism. However this means that the resources for the skin are deployed globally and site-wide within 5 minutes. Whereas the html isn't for another 2 weeks.

This is why client resources must always be backwards compatible.

-- Krinkle

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Luke Welling WMF
In reply to this post by Platonides
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 <[hidden email]> 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/000093.html
>
> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Chad
On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling <[hidden email]> 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.

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.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: WMF's webpage

Roan Kattouw-2
On Wed, Nov 28, 2012 at 4:21 PM, Chad <[hidden email]> wrote:

> On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling <[hidden email]>
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l