Talk:ResourceLoader/Legacy JavaScript

Previous page history was archived for backup purposes at Talk:ResourceLoader/Legacy JavaScript/LQT Archive 1 on 2015-07-10.

depracation page declares these methods depracated, and claims that mw.loder replaces them.

however, there is no method in mw.loader that can replace these. of course, one can always use mw.util.wikiGetlink(page) and append the "?action=raw&ctype=text/javascript" manually, but this seems somwewhat pointless - this is exactly what importScript() and importStylesheet() do for you...

mw.loader.load() replaces both importScriptURI and importStylesheetURI() successfuly, but not importScript() and importStylesheet().

on a completely different note, i would love it if mw.util.wikiGetlink() would accept an additional, optional parameter of type "object" that would add parameters: so if i want to get a page with "?action=edit", i would use mw.util.wikiGetlink(pageName, {action: 'edit'}); etc. if the first parameter is an object, this means i want the current page (just like mw.util.wikiGetlink() with no parameters), but still append the parameters.

this would be in the spirit of most or all of jQuery, calls, and very much in synch with the way to do ajax in jquery.

Hi!

You may want to vote/watch the following bugs:

• 25845 - Support loading wiki pages through mediaWiki.loader.load()
• 27281 - Add support in the front-end for loading wiki pages as resources
• 34743 - mw.util.wikiGetlink should accept URL parameters in its second parameter

I've added a link to the first two of them on the documentation page.

Thanks for pointing me to the first 2 bugs, and doubly thanks for opening the 3rd one per my comment.

however, i do believe that until the loader actually supports importScript()/importStylesheet(), we should not have them in the depracation list.

peace.

See also ResourceLoader/Migration_guide_(users)#mw.loader.

If you are looking to update your scripts to not use deprecated functions, and come across calls to "importScript" and "importStylesheet", you are free to just keep using those the way they are. You don't have to fear them being removed, that will not happen until after a better replacement exists.

mw.loader.load does not and will not support loading of wiki-pages directly. The whole concept of ResourceLoader is modularity. Right now that is only available to core/extensions and on wikis via Gadgets. User scripts cannot create modules directly, therefor it's currently not possible to migrate a non-Gadget user script to fully use mw.loader.

Advise:

• Either make your script into a Gadget (in which case you shouldn't ever need to use importScript, since you either list other files in the Gadgets-definition or you use "dependencies" to load common/shared code).
• Keep using importScript

Current replacement is mw.util.tooltipAccessKeyPrefix but you get also a Deprecation warning: "Use of "tooltipAccessKeyRegexp" is deprecated. Use jquery.accessKeyLabel instead." But this is completely undocumented I found nothing how can this be used. It seems you must first select a mystic jquery object.

See https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/jQuery.plugin.accessKeyLabel and w:en:Special:Diff/611652439 / w:en:Special:diff/611652528 for an example of use.

Ok, hm you removed concrete correspondence. I found this after several trial and error $("#wpWatchthis").updateTooltipAccessKeys.getAccessKeyPrefix(). (There stays only somewhat updateTooltipAccessKeys_getAccessKeyPrefix( [ua] ) : string Exposed for testing. ...) I mean this is much more complicating as it was!?! Thanks

Another point, the var tooltipAccessKeyPrefix (give alt-) is not the same as mw.util.tooltipAccessKeyPrefix (give "alt-shift-"). Sorry for the detailed question, is this so intended? So I must also set a new KeyPrefix for my Button (the alt- seems default)

I changed mw.util.tooltipAccessKeyPrefix to $(btnOld).updateTooltipAccessKeys().getAccessKeyPrefix

See ResourceLoader/Legacy JavaScript#ajax.js.

Is there a replacement for sajax_do_call? I couldn't find one in MW1.17

Deprecation of legacy functions are listed on ResourceLoader/JavaScript Deprecations.

sajax_do_call should still work fine in MW1.17, it has not been removed, just deprecated.

ResourceLoader/JavaScript Deprecations lists jQuery.ajax (and helper functions such as $.post, $.getJSON) as recommended replacements.

Yeah, I know that. The problem is that sajax_do_call is a MW specific wrapper, not just a simple ajax call, you have to call index.php with action=ajax with rs=FunctionName and rsargs[]=arguments. This is more complicated than sajax_do_call, and this information is hidden in a footnote on Manual:Parameters to index.php

Edit: Ok, it can be found on Manual:Ajax too. Anyway, I've added an example to this page, is that ok?

See T35836 and T122755.

See also bugzilla:33836 and bugzilla:29753

---

The original plan (as somewhat documented on pages like ResourceLoader/JavaScript Deprecations) was as following:

1) Deprecation

• Baptize scripts in /skins/common deprecated (wikbits.js, ajax.js etc.; "legacy JS")
• Start working on mediawiki object library
• Work step-by-step on removing any and all references to legacy JS in MediaWiki core by either superseding/rewriting/modernizing them with new utilities in the mw object or by replacing them with calls to jQuery core or plugin methods.
• End up in a situation where there are no references to legacy JS in MediaWiki core anymore. At this point all of it's functionality will be redundant or made possible by other means (jQuery core, plugins or mediawiki object). However at this point, all of the legacy functionality should still be available and work like it did before.

2) Migration

• At this point users should start en-mass with migrating scripts (1.17 deployment). It will be highly encouraged to switch to more modern implementations of legacy features as soon as possible.

3) Quarantine

• After a few releases (around 1.20 branch?) the legacy JS will be moved from the global scope into a quarantined scope in mw.legacy. Remapping may be used as a stop-gap until for example pending bugs in mediawiki lib are being fixed or other issues solved. Stop-gap being replacing calls from foo with mw.legacy.foo etc.

4) Removal of legacy code entirely.

There are many scripts using things like addPortletlink, sajax_*, updateTooltipAccessKeys, checkboxShiftClick and more. While I agree that having code like this, code that is not used in core, has a future version that is said to be better and mostly compatible, etc, sounds weird.

But removing a legacy method as soon as there is a better version and telling users to fix their scripts doesn't like a plan either, see the above.

Also note that legacy scripts don't have unit tests, and likely never will because they are pending to be removed, will never change anyway, and are (ab)used in so many different ways due to lack of documentation or examples, so it wouldn't represent usage of the methods in the real-world.

Legacy code that is no longer being actively used by core should be removed entirely.

Where there are legacy function & variable APIs that we can cleanly make shims for, it's very nice to be able to make available. Where there aren't, keeping the old code as-is in a "legacy quarantine" doesn't make much sense to me, as anything attempting to call them will still have to jump through hoops to find the quarantine module and use it in the first place... and then much of the time they may end up failing as they're out of date with the rest of the interface.

Our current situation per bugzilla:29753 is that "legacy" code in wikibits.js is still:

• included in core
• always loaded
• actively used by core

and there's "new code" to replace it which is:

• not loaded at all
• not used at all

ergo, it's not a case of legacy code that's been superseded -- it's active live code still in active live use.

The course of action I recommend is to finish that job: load and use the new code, remove the old code, and supply a compatibility shim for the old var/function if anything needs it.

I love a man who uses "shim." What a great word.

The killEvent() function was deprecated. No direct replacement is needed because it's functionality is obsolete with jQuery's event.preventDefault. In addition, you can also simply return false; from any event handler to achieve the same effect, which is supported in all JS-enabled browsers.

In wikibits.js, killEvt() is used to kill window events so that, for instance, a link's onClick doesn't also trigger navigation to its href target. Is there a replacement for killEvt? I haven't yet seen how newer MediaWiki code deals with event killing without this. -Memethief 01:33, 12 November 2010 (UTC)

This post was posted by Krinkle, but signed as Memethief.

jQuery provides event.preventDefault() for any browsers that ignore w3 standards and returning false from a jQuery event handler will also stop the default action from happening, which presumably means killEvt() isn't needed any more to kill window events. ATM I think they haven't completely stopped using it yet. --Darklama 00:12, 4 December 2010 (UTC)

This post was posted by Krinkle, but signed as Darklama.

The name of the event object is different per browser and the way to stop the default action (ie. following a link) is also different per browser. However jQuery takes care of this since it maps it all to event.preventDefault. Meaning something like the following works in all browsers (IE 6.0+, FF 2+, Safari 3.0+, Opera 9.0+, Chrome)

$( 'a#mw-veryspeciallink' ).click( function(e){
  e.preventDefault();
  alert( 'Hi, we just hijacked this link.' );
});

Also, don't use return false unless there is a specific reason you want to do that. It stops other handlers from being triggered and has other downsides. Use e.preventDefault() when all you want is stopping the browser from doing it's own thing.

wikibit's killEvt() was a (fairly complete) function that takes care of a lot of variations in different browsers but does exactly what e.preventDefault() does in jQuery it is therefor redundant and not ported to the new ResourceLoader code, since jQuery is now available on all pages by default.

Also I'd like to emphasize here that wikibits and the new mw resources are not mutually exclusive. There will be a period of time in which both are available (read also the intro paragraph on ResourceLoader/JavaScript Deprecations). Krinkle 13:07, 11 December 2010 (UTC)

insertTags() was deprecated, but the new mw.toolbar module covers all its functionality.

How can you deprecate major features like insertTags with no replacement listed? What's the purpose of this page, to just tell us that we're screwed and should give up on ever using our scripts again? UncleDouggie 09:58, 18 February 2011 (UTC)

This post was posted by Krinkle, but signed as UncleDouggie.

It is deprecated not removed. The function is still there and used by:

• MediaWiki core's default editing toolbar
• Extension:Charinsert

Note that the actual insertTags function has in fact already been replaced in 1.18 with a call into the jquery.textSelection module; but it's kept available for internal API compatibility.

The direct callers are on the way (though not yet 100%) to being superseded by Extension:WikiEditor's editing & toolbar widgets, which have more tightly integrated (and more flexible) ways to list things to insert into your editor (ultimately using jquery.textSelection as the actual implementation).

addPortletLink() was deprecated, but a replacement mw.util.addPortletLink() is also provided.

If addPortletLink() is going to be deprecated, I really hope that an equivalent function will be provided to replace it. Adding links to navigation menus is an extremely common task in user scripts, and I really don't want to see us going back to the bad old days when every script writer would roll their own, often half-assed implementation of it. --Ilmari Karonen 22:15, 10 October 2010 (UTC)

This post was posted by Krinkle, but signed as Ilmari Karonen.

+1. I don't really understand why we are deprecating the wiki-specific functions of wikibits. I could understand re-implementing things like addPortletLink, jsMsg in terms of jquery where appropriate, but the functions are useful and should stay. It doesn't make sense (imho) to just totally ditch all pre-existing wikibits js. Bawolff 01:25, 11 October 2010 (UTC)

This post was posted by Krinkle, but signed as Bawolff.

Its being deprecated apparently in favor of mw.util.addPortletLink() so an equivalent function will be provided. I wish a skin independent way to get at portlets and to delete portlet links were provided too though. A jsMsg replacement isn't needed at all because of the skin independent way to get at the content body that will make it as easy as mw.util.$content.prepend('<div>your message here</div>'); --Darklama 23:56, 3 December 2010 (UTC)

This post was posted by Krinkle, but signed as Darklama.

mw.util.addPortletLink() is not the same as mw.legacy.wikibits's addPortletLink(). The new one is in fact skin independant for all skins supported by core. It adds them to the known portlets when the skins supports it (such as in chick, modern, monobook, myskin, simple and vector), and otherwise it falls back to other locations that are used by the skin to place handy links. Such as #quickbar in the skin 'cologneblue' and 'standard'. And the area before #searchform in 'nostalgia' skin. See also mediaWiki.util.addPortletLink(); Krinkle 12:58, 11 December 2010 (UTC)

By skin independent I was thinking of something more along the lines of 'toolbox' or 'lang' being passed and it maps it to the correct id for the skin being used. Having looked at the js file, I see that addPortletLink ignores the passed id for some skins and checks if the passed id exists for all other skins. --Darklama 22:03, 11 December 2010 (UTC)

This post was posted by Krinkle, but signed as Darklama.