MediaWiki 1.17 engine released. My extension replacing jQuery is still working in it. But in the future (for MediaWiki 1.18) a more elegant solution will appear.

On June 22, 2011, the Wikimedia Foundation released another stable version of the MediaWiki engine - version 1.17. You can easily find the corresponding news in English in the mediawiki-announce mailing list, which includes hyperlinks to a detailed list of changes and instructions for upgrading.

One of the main (and even key) news of this version was the emergence and implementation of a unique ResourceLoader engine, the purpose of which is to automatically build “resources” (javascript conglomerates and CSS, from which one common CSS file and one common javascript file are assembled), taking into account their mutual dependencies (for example, jQuery UI depends on jQuery) and followed by minification. Two resources containing the MediaWiki service scripts and the jQuery 1.4.2 library are connected automatically in any case.

Those of you who want to use a newer version of jQuery can still use for this purpose my method and extension, which I told you about 12 days ago in the same blog. Oddly enough, I didn’t have to change any of the letters in his PHP code to work in MediaWiki 1.17 - this is good luck, despite the fact that (due to the complexity of ResourceLoader), the former ability to “bite out” the jQuery library embedded in MediaWiki, disappeared completely. So now my extension “wins” just because it inserts a call to a new jQuery a bit earlier than ResourceLoader starts loading the old one. Apparently, the jQuery 1.4.2 library is reasonable enough not to replace the new version of itself. However, it is sad that now (unlike 1.16) my extension does not allow loading one version of jQuery (my own) instead of another version (built into the engine): in 1.17 they are loaded together, which is uneconomical.
')
I'll warn you that as the ResourceLoader adapts, some extensions and components of MediaWiki will surely learn (and some have already learned) to rely on that (old) version of jQuery, which is built into the MediaWiki engine - and with a noticeable jQuery update, many of them will fall off without fail. In particular, the next version (MediaWiki 1.18) will be delivered (according to the jQuery page on its wiki) with a not-so-updated jQuery library (version 1.4.4 instead of version 1.4.2 going to MediaWiki 1.7) - all because UploadWizard is dead when trying to update jQuery to version 1.5.2, being incompatible with the new behavior of the $ .ajax () function , so jQuery involuntarily rolled back to 1.4.4 . Keep this incident in mind if you wish to place an excessively new version of this popular javascript library on the MediaWiki: jQuery.js page.

To all this we must add (and add) that fans will not need to use the updated jQuery library in MediaWiki 1.18. In this future version of MediaWiki, fortunately, there is a new ResourceLoaderGetStartupModules anchor point, on which you can attach a PHP script that elegantly replaces jQuery from within ResourceLoader. Last night and tonight, the developer Timo Tijhof (this is the one who, by the pseudonym Krinkle, hung the “inspected” flag on the ResourceLoaderGetStartupModules diff ) kindly agreed, at my request, to write an extension using this feature - so that its “ Local jQuery ” extension can be further (and need, need!) will certainly use my instead, immediately after switching to MediaWiki 1.18, since it saves on code size, causing one version of jQuery instead of another (and not one after the other, as I had to do in 1.17).

Finally, a little about the sad.

The $ wgParser-> disableCache () method, which worked fine in MediaWiki 1.16, causes PHP to crash into “Fatal Error: Call to a member function setCacheTime () on a non-object” in module / includes / parser / Parser .php (which indicates some lack of thought of the logic of this method in the new version). In particular, the EmbedVideo extension suffered from this, which was invented by Jim R. Wilson in 2007 and which was then finished for a long time and upgraded by me and Alexander Mashin. It is now used in Tradition , Wikireality and Cyclopaedia . The method had to be simply commented out - in the end, you can allow the media players to be cached - but it’s scary to think about what crunches the authors of those extensions will have to invent, in which the lack of caching of the final page is essential.