Page MenuHomePhabricator

Set $wgLegacyJavaScriptGlobals = false by default
Open, LowPublic


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

I'm opening this bug (similar to T35836) mostly for tracking the progress on this regard.

For the overall schedule, see T72470: Remove legacy javascript globals.

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:07 AM
bzimport set Reference to bz33837.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Jan 20 2012, 12:51 PM

According to my testing in 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.

Lupo added a comment.Jan 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?

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

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

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

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

 // ...


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.

Krinkle claimed this task.Nov 24 2014, 10:27 PM
Krinkle updated the task description. (Show Details)
Krinkle removed a project: Future-Release.
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).

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.

Ricordisamoa added a subscriber: Ricordisamoa.
Technical13 added a comment.EditedJan 17 2015, 12:19 AM

@Krinkle @Jdforrester-WMF @matmarex Does the foundation support me cleaning these old uses up? Please see and comment as you see fit. Thank you.

Krinkle removed Krinkle as the assignee of this task.Jul 8 2015, 7:13 AM
Krinkle lowered the priority of this task from Medium to Low.
Restricted Application added subscribers: Luke081515, Aklapper. · View Herald TranscriptJan 29 2016, 7:37 PM

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.

Tgr updated the task description. (Show Details)Feb 5 2017, 9:44 AM
Tgr moved this task from Technical Debt to Frontend on the Developer-Wishlist (2017) board.
Krinkle updated the task description. (Show Details)Mar 7 2018, 8:42 PM

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

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

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?

TheDJ added a comment.Aug 20 2018, 9:12 PM

Interestingly enough, globals usage has actually been on the rise since october 2017... scary, to see how infectious code is...

Interestingly enough, globals usage has actually been on the rise since october 2017... scary, to see how infectious code is...

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

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.