Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
A mirror of MediaWiki's Subversion repository produced with git-svn(1)
branch: CentralNotice-…

This branch is even with brion:CentralNotice-delayed-load

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
CentralNotice.php
NoticePage.php
README
SpecialNoticeLoader.php
SpecialNoticeText.php

README

Proof of concept for the moment fiddling with an alternative sitenotice
loading architecture. At the moment there's no backend logic or caching
logic, I'm just testing the three-level loading.


Wiki page HTML contains an unchanging bit that just sets JS variables about
what site this is, then calls an external <script> to fetch site notice text.


That second level can be a stable URL which can be heavily cached within squids
*and* cleanly purged on sitewide updates.

It itself is small, just calling out to a third <script>, this time with the
site info (project and language) and a cache validation epoch / version marker
in the query string.


The third level is the bit that would provide the actual site notice text, and
could be cached arbitrarily long in both squids and final user agents, since
changed versions will get a new URL with a version number one level up.



The theory here is that it should interact better with big-site caching.
A user agent's first hit to the wiki will look something like:

* Load wiki page HTML
* Load Special:NoticeLoader JS
* Load Special:NoticeText JS

A hit to another page on the same wiki can skip the third hit:

* Load new wiki page HTML
* Load unchanged Special:NoticeLoader JS
* skip cached Special:NoticeText JS

Then if the site notice changes, the system only has to purge that constant
Special:NoticeLoader URL from squids, and right away at the next hit the user
agent sees:

* Load new wiki page HTML
* Load new Special:NoticeLoader JS
* Load new Special:NoticeText JS

We could spare hits on the notice loader by letting clients cache it for a
shorter term as well, so a typical second hit looks nicely like:

* Load new wiki page HTML
* skip cached Special:NoticeLoader JS
* skip cached Special:NoticeText JS

This could delay visibility of changed site notices until the allowed age
runs out, but if we manage *scheduled* site notices, we could send cache
headers which will run out at the expected changeover time.

It might be nice to allow for quick corrections though, so caching for weeks
at a time might not be wise. ;)



This experimental branch attempts to load the notice loader JS in an onload
event handler instead of during initial page load, so the whole page won't
get held up while waiting for the JS.

Unfortunately, while it seems to work fine in Firefox, Opera, and even iCab,
I had trouble in Internet Explorer and Safari.

Safari 2.x and 3.x mysteriously fail to load the NoticeLoader JS when it's
cached (with using maxage > 0), so you see the notice only on first load
or after the maxage expires.

IE 6 and 7 fail to load the loader JS at all, and further they explode when
I try to load in FireBugLite to help debug it. Sigh.

Safari 3.x (tested beta on Windows) also renders the page without the notice
before loading it, causing visible UI jiggery-pokery even on a fast local
network, which is mildly annoying.

Safari and IE 6 also don't grok the <style> when done this way, so I redid
it to pull the style separately via a proper <link>, which would have to
be separately maintained and cache-cleared.

This test branch has some FireBug console calls in the JS for testing.
Something went wrong with that request. Please try again.