Wikitech-l February 2011

wikitech-l@lists.wikimedia.org

111 participants
73 discussions

Farewell JSMin, Hello JavaScriptDistiller!
by Trevor Parscal 01 Feb '11

01 Feb '11

For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on "ext.vector.simpleSearch" * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. The code was committed in r80656. - Trevor (and Roan)

18 31

Accessing the toolserver from WP using Ajax
by Daniel Kinzler 01 Feb '11

01 Feb '11

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 :)

3 2

Re: [Wikitech-l] Planned 1.17 deployment on February 8
by bawolff 01 Feb '11

01 Feb '11

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2011