Last modified: 2014-09-05 22:44:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35837, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33837 - Set $wgLegacyJavaScriptGlobals = false by default
Set $wgLegacyJavaScriptGlobals = false by default
Status: NEW
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
All All
: Normal enhancement (vote)
: Future release
Assigned To: Nobody - You can work on this!
Depends on: 56550 65011
Blocks: code_quality 30358 50039 70470
  Show dependency treegraph
Reported: 2012-01-20 12:51 UTC by Helder
Modified: 2014-09-05 22:44 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Helder 2012-01-20 12:51:22 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).
Comment 1 Niklas Laxström 2012-01-20 18:30:39 UTC
According to my testing in it is now way too early to do this.
Comment 2 Krinkle 2012-01-20 21:08:36 UTC
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.
Comment 3 Lupo 2012-01-31 11:46:39 UTC
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?
Comment 4 Krinkle 2012-09-30 00:34:41 UTC
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.
Comment 5 Fomafix 2014-05-07 18:09:39 UTC
How many extensions still use the JavaScript globals?
Comment 6 Bartosz Dziewoński 2014-05-07 19:27:41 UTC
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. :)
Comment 7 MZMcBride 2014-05-14 01:59:29 UTC
(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.
Comment 8 PRO 2014-06-21 13:52:17 UTC
I don't understand why. Is
Comment 9 PRO 2014-06-22 10:32:55 UTC
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) ?
Comment 10 Krinkle 2014-07-03 19:39:07 UTC
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.
Comment 11 Derk-Jan Hartman 2014-07-03 20:14:34 UTC
Potentially, we could set this explicitly in Wikimedia config and then flip the DefaultSettings value.

If extensions are 'reasonably' clean that is.
Comment 13 Technical 13 2014-07-07 23:55:16 UTC
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.
Comment 14 Krinkle 2014-07-08 00:01:59 UTC
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' ) {
Comment 15 Krinkle 2014-07-08 00:06:32 UTC
@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.
Comment 16 Technical 13 2014-07-08 00:46:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.