Last modified: 2014-09-05 22:44:44 UTC
Per [[mw:ResourceLoader/Migration_guide_(users)#wg.2A_Variables]], there are plans to remove the global JavaScript variables (such as wg* ). I'm opening this bug (similar to Bug 33836) mostly for tracking the progress on this regard. If anyone knows if this is already scheduled to be done in some specific future version of MediaWiki, please inform us below (and update the Target milestone from "Mysterious future" to something more appropriated).
According to my testing in translatewiki.net it is now way too early to do this.
These variables are currently deprecated and superseeded by mw.config. Toggling $wgLegacyJavaScriptGlobals to false will keep them out of the global scope also. Removing link to bug 9968 which is PHP oriënted.
Is there _any_ pressing reason to remove these wg* variables at all? (Besides it looking cleaner?) Doing so will just cause problems for scripts that should run on both old (MW <= 1.16) and new (MW >= 1.17) installations. What's the plan for such code?
Keeping compatibility with 1.16 and 1.20 with the same code is somewhat crazy as there is a huge amount of development in between. wg* globals are probably the least of your worries (localization, dependencies, new APIs, different HTML markup, ...). So I'd recommend to branch or tag your script. Keep the old version as-is for < 1.17, and the new version for anything new. Or if you really do only have this one specific problem and everything still works as-is, it is easily worked around with a small wrapper like: var mwConf = window.mw ? function (key) { return mw.config.get(key); } : function (key) { return window[key]; }; They will be removed because they haven't been relevant for 4 major versions, and any script still using them is definitely overdue for a review (if it hasn't broken already). Also note that they wouldn't be really "removed". In a way they are already gone. Toggle $wgLegacyJavaScriptGlobals to enable/disable the compatibility layer. If it was just this on itself, it could be kept for a long while, but it is part of the whole "legacy / 1.17+" deal (ResourceLoader, Vector, jQuery, WikiEditor etc.). It is a one-time turning point in the history from one era to another.
How many extensions still use the JavaScript globals?
You could probably get reasonably accurate results by grepping for something like /\Wwg|window\.wg|this\.wg/ Personally I'd be more interested by how many gadgets/site scripts use these. :)
(In reply to Krinkle from comment #2) > These variables are currently deprecated and superseeded by mw.config. For the curious, adding deprecation notices for these variables is being discussed at bug 56550. This wasn't immediately clear to me when reading through this bug report, so I thought I'd make note of it.
I don't understand why. Is
It was a 50:50 chance that I'm a pro and the text field "Save Changes" button is the same as above. Sorry but we can't delete messages here. An high on the bugzilla software. Would be not there a simple user option to made JavaScriptGlobals(true) ?
Update on this front: Gadget authors have not yet been given a fair chance to migrate their scripts. Disabling this now will needlessly upset users and break actively deployed user applications on mediawiki.org. Given the complex nature of our user scripts (cross-loading from different wikis), we'll definitely need a phase where these emit deprecation notices so that developers have the chance of migrating their scripts *before* we boldly remove it hoping they'll quickly fix it. That's counting on breakage as the means to communicate change and I dont like that. Right now we have about a dozen other highly visible migrations going on in the front-end. These legacy globals is not one of them. They haven't been announced very publicly, have no deprecation warnings for developers either. They're also cheap to maintain compatibility for. I wouldn't prioritise pushing for the removal of these in the current MediaWiki release cycle.
Potentially, we could set this explicitly in Wikimedia config and then flip the DefaultSettings value. If extensions are 'reasonably' clean that is.
FYI: I asked the users to test their personal scripts on test2wiki now that bug 65011 was fixed: https://en.wikipedia.org/wiki/WP:VPT#No_more_.22wg....22_globals_in_JavaScript https://en.wikipedia.org/wiki/?oldid=616015267#No_more_.22wg....22_globals_in_JavaScript
I'd like to note that there are a LOT of gadgets and userscripts that are unmaintained and I'm not finding a clear replacement table anywhere to be able to update scripts as I find them. This should not be done until there has been a table that offers a "replace wgXX variables with YY" available to make it easier for all script writers to comply with the change. This table should be available for at least three months before this change is implemented. I was entirely unaware of this change until just now despite the fact it has apparently been in progress for years since 1.17. Why has it taken so long to announce this, and why is it only being announced last minute? Now that I'm aware, I'd be happy to personally start going through every userscript and making edit requests on the talk pages to get the script writer to update their script or get an admin to do it, but I'm going to need some time to do this. Thanks.
A replacement table is not needed for there is no individual migration or deprecation related to this matter. The deprecation here is about all mw.config values. They are currently exposed as global variables in addition to their place in mw.config. In the future, the global equivalents will be removed. So basically: Stop using wg globals that come from mw.config, and use mw.config instead. e.g. instead of: if ( wgCanonicalNamespace === 'User' ) { .. } You'd use: if ( mw.config.get( 'wgCanonicalNamespace' ) === 'User' ) { .. } Or, more likely in a larger script: var conf = mw.config.get([ 'wgCanonicalNamespace', 'wgUserName' // ... ]); if ( conf.wgCanonicalNamespace === 'User' ) { .. }
@Technical 13: It's good that you're starting to migrate this. However don't feel like you're rushing at the last minute. These were deprecated years ago but they're very easy to continue to support for the time being. And there isn't a real big gain in removing them (other than 2 lines of code that exposes them). There are enough other deprecations going that do provide valuable progress when finished that this was never announced in a "panic" manner. I intend to let this continue for a while and instead have it be picked up by developers over time. There's no need for rush behind this one. It affects practically every script ever written. Breaking that is not going to be worthwhile for a long time. Probably best combined with a major change sometime in the future. Meanwhile, continue migrating away but don't feel pressured in a negative way. This is not a last-minute call.
Thank you for the clarification Krinkle. I do believe all my scripts already use mw.config.get('wgXX'). Thank you for also assuring me there will be some time to find and fix all the instances without feeling like it needs to be done this week. I'll start by trying to find all the documentation and updating that so people can find the proper way to call the variables. Then I'll dig through gadgets and userscripts.
