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

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

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

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

Any progress on this task? As T35836: Set $wgIncludeLegacyJavaScript = false by default will break old scripts anyway it seems a good opportunity to disable the globals by default now.

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Change 452843 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on all group0 wikis, not just test2wiki

https://gerrit.wikimedia.org/r/452843

Change 452843 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on all group0 wikis, not just test2wiki

https://gerrit.wikimedia.org/r/452843

Mentioned in SAL (#wikimedia-operations) [2018-08-14T23:13:50Z] <catrope@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Disable wgLegacyJavaScriptGlobals on all group0 wikis (T35837) (duration: 00m 54s)

So this is now live on Wikimedia's group0 wikis. Maybe we should put something in Tech/News?

Interestingly enough, globals usage has actually been on the rise since october 2017... scary, to see how infectious code is...
https://grafana.wikimedia.org/dashboard/db/mw-js-deprecate?refresh=1m&orgId=1&from=now-2y&to=now

In T35837#4516593, @TheDJ wrote:

Interestingly enough, globals usage has actually been on the rise since october 2017... scary, to see how infectious code is...
https://grafana.wikimedia.org/dashboard/db/mw-js-deprecate?refresh=1m&orgId=1&from=now-2y&to=now

That's what prompted me to push group0 over the ledge.

In T72470#5325506, @Krinkle wrote:

Proposing to resume this project after the 1.35 cycle starts, in October 2019. With the step of turning off for all WMF wikis happening somewhere between January and May 2020, and in MW core for third-parties after that, to be part of the 1.35.0 release in June 2020.

In T35837#5325507, @Krinkle wrote:

In T72470#5325506, @Krinkle wrote:

Proposing to resume this project after the 1.35 cycle starts, in October 2019. With the step of turning off for all WMF wikis happening somewhere between January and May 2020, and in MW core for third-parties after that, to be part of the 1.35.0 release in June 2020.

This didn't actually happen, so do we still want to disable it by default for 1.35? Or postpone?

I actually cleaned up fawiki and wikidatawiki a couple of weeks ago and was planning to push this there but somehow it fell into the cracks. Will get it deployed in these two wikis ASAP.

In T35837#6306727, @Legoktm wrote:

In T35837#5325507, @Krinkle wrote:

In T72470#5325506, @Krinkle wrote:

Proposing to resume this project after the 1.35 cycle starts, in October 2019. With the step of turning off for all WMF wikis happening somewhere between January and May 2020, and in MW core for third-parties after that, to be part of the 1.35.0 release in June 2020.

This didn't actually happen, so do we still want to disable it by default for 1.35? Or postpone?

Yeah, no need to rush for the stable release. Third parties can switch it off already if they want to. The general bulk of the WMF wikis have not transitioned yet so it's hard to know whether the bulk of gadgets in use elsewhere will have been ported or not by now.

In T35837#6306743, @Ladsgroup wrote:

I actually cleaned up fawiki and wikidatawiki a couple of weeks ago and was planning to push this there but somehow it fell into the cracks. Will get it deployed in these two wikis ASAP.

oh I already disabled it in these two wikis.

Moving to MW-1.37-release as RC.0 ships in a week or two's time.

In T35837#6985815, @Jdforrester-WMF wrote:

Moving to MW-1.37-release as RC.0 ships in a week or two's time.

What is the blocker for setting this to false in 1.36? It's already disabled in most WMF wikis and nothing exploded.

Okay this is interesting, it's already disabled by default. I think this is done. Right?

It's disabled by default in 1.35. In WMF wikis it's disabled everywhere except five or six wikis which I'm disabling two per week.

Ha. I even did it myself. :-)