Set $wgLegacyJavaScriptGlobals = false by default
OpenPublic

Description

Per ResourceLoader Migration guide, there are plans to remove the global JavaScript variables (such as wg* ).

I'm opening this bug (similar to T35836) 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).


Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70366

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz33837.
He7d3r created this task.Via LegacyJan 20 2012, 12:51 PM
Nikerabbit added a comment.Via ConduitJan 20 2012, 6:30 PM

According to my testing in translatewiki.net it is now way too early to do this.

Krinkle added a comment.Via ConduitJan 20 2012, 9:08 PM

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.

Lupo added a comment.Via ConduitJan 31 2012, 11:46 AM

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?

Krinkle added a comment.Via ConduitSep 30 2012, 12:34 AM

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.

Fomafix added a comment.Via ConduitMay 7 2014, 6:09 PM

How many extensions still use the JavaScript globals?

matmarex added a comment.Via ConduitMay 7 2014, 7:27 PM

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

MZMcBride added a comment.Via ConduitMay 14 2014, 1:59 AM

(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.

Perhelion added a comment.Via ConduitJun 21 2014, 1:52 PM

I don't understand why. Is

Perhelion added a comment.Via ConduitJun 22 2014, 10:32 AM

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

Krinkle added a comment.Via ConduitJul 3 2014, 7:39 PM

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.

TheDJ added a comment.Via ConduitJul 3 2014, 8:14 PM

Potentially, we could set this explicitly in Wikimedia config and then flip the DefaultSettings value.

If extensions are 'reasonably' clean that is.

Technical13 added a comment.Via ConduitJul 7 2014, 11:55 PM

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.

Krinkle added a comment.Via ConduitJul 8 2014, 12:01 AM

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' ) {

..

}

Krinkle added a comment.Via ConduitJul 8 2014, 12:06 AM

@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.

Technical13 added a comment.Via ConduitJul 8 2014, 12:46 AM

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.

Krinkle claimed this task.Via WebNov 24 2014, 10:27 PM
Krinkle edited the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l.
Krinkle removed a project: Future-Release.
Krinkle set Security to None.
Jdforrester-WMF added a comment.Via WebNov 24 2014, 10:43 PM

Can we do this for MW1.25 or should we wait for MW1.26? Given we're also getting rid of jQuery-Migrate, maybe it's good to get it all done at once? (…or maybe we should be conservative in the number of major breaking changes we make at once?)

Krinkle added a comment.Via WebNov 26 2014, 1:36 PM

@Jdforrester-WMF We'll first implement proper deprecation flags for the globals (T58550; land in MediaWiki 1.25?) then remove in MediaWiki 1.26 or 1.27.

Schnark added a subscriber: Schnark.Via WebDec 5 2014, 11:49 AM
Ricordisamoa awarded a token.Via WebJan 3 2015, 12:35 PM
Ricordisamoa added a subscriber: Ricordisamoa.
RandomDSdevel awarded a token.Via WebJan 12 2015, 11:22 PM
Technical13 added a comment.EditedVia WebJan 17 2015, 12:19 AM

@Krinkle @Jdforrester-WMF @matmarex Does the foundation support me cleaning these old uses up? Please see https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions#Global_editinterface_for_Technical_13 and comment as you see fit. Thank you.

matmarex removed a subscriber: matmarex.Via WebJan 17 2015, 12:19 AM
Technical13 added a subscriber: matmarex.Via WebJan 17 2015, 12:20 AM
zhaofengli added a subscriber: zhaofengli.Via WebJan 25 2015, 6:13 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.