Hi all!
what's the best way to get around the same original policy to fetch data from
the toolserver with a XMLHTTPRequest in a Wikipedia gadget? Is there a best
practice, a nice and easy, generally usable method? what would it take to make one?
I know that some gadgets have been doing this, but I also know that it's a bit
tricky. I think a general solution to this, documented somewhere, would make
life a lot easier... does something like this exist? if not, why not?
-- daniel
PS: while i'm at it, is there a wrapper function for XMLHTTPRequest in the
standard MEdiaWiki JS? I don't want to re-invent a sucky wheel :)
Rob said
> --Hi everyone,
>
> Just repeating something I just posted to
> http://techblog.wikimedia.org/2011/02/planned-1-17-deployment/
>
> The engineering team is busy working on the deployment of the 1.17 branch of
> MediaWiki[1]. We plan to roll this out next week to all languages and
> projects, Tuesday, February 8, with work starting at 07:00 UTC (which is
> 11pm on Monday, February 7 for San Francisco).
>
> If all goes well, you should only notice the improvement. If it doesn’t go
> well, that’s because there’s something we missed, and that’s where we’d love
> your help. Please help us test this release! We have a test instance of the
> software we plan to deploy available at http://prototype.wikimedia.org/. If
> you find issues, please report them in Bugzilla:
> http://www.mediawiki.org/wiki/Bugzilla
>
> There are many, many little fixes and improvements that have gone into 1.17
> (see the draft release notes[2] for an exhaustive list) . There isn’t much
> that’s visible to users of the site, but one under the hood improvement that
> should result in some speed improvements: Resource Loader[3]. Resource
> Loader optimizes the use of JavaScript in MediaWiki, speeding up delivery of
> JavaScript by compressing it sometimes, and cutting down on the amount of
> unused JavaScript that gets delivered to the browser in the first place.
> Much of the work in this development cycle has been centered on ensuring
> compatibility with the new system. Since it makes such a large shift in the
> way that JavaScript is delivered to the browser, it’s also an operational
> aspect we’ll be keeping a close eye on, as load shifts between servers in
> our infrastructure.
>
> Note that this isn’t a release for download, yet. On and after February 8,
> the “latest” version of MediaWiki will still be 1.16 as listed on
> mediawiki.org. We plan to update this to 1.17 sometime after the deployment
> of the 1.17 branch, after we’ve had time to run it in production for a while
> and fix the issues we’re likely to find.
>
> So please, help us test this release, and if you find bugs, please report
> them in Bugzilla. Thanks!
>
> Rob
>
> [1] http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17
> [2]
> http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/RELEASE-N…
> [3] http://www.mediawiki.org/wiki/ResourceLoader
> [4] http://www.mediawiki.org/wiki/Download
>
>
Is there any plan to deal with all the JS in mediawiki:Common.js that
RL is probably going to break? Admins at wikimedia sites (other then
enwikipedia)
tend not to really know what they're doing in terms of customizing JS,
thus there is a lot of really sketchy js in mediawiki:Common.js that
gets copied from site to site and messed around with until it works.
Several of the smaller wikis already have broken JS. I imagine that
many more will break with the RL, and local admins probably won't know
whats wrong/how to deal with it.
Cheers,
-bawolff
p.s. Can I get three cheers for 1.17 :D