Allow for gadgets to be turned on by default
Closed, ResolvedPublic


A very nice feature for the gadgets would be to be able to have some gadgets turned on by default (for all users), and then users can turn them off if they want to.

It _could_ be done by including the code in (e.g.) Common.css and then make the gadget turn that code off, but that would be a bit messy and non-intuitive. So I think being able to turn some gadgets on by default would be a better solution.

Version: unspecified
Severity: enhancement
See Also:

bzimport set Reference to bz13742.
jhsoby created this task.Via LegacyApr 14 2008, 8:19 PM
MaxSem added a comment.Via ConduitJul 4 2008, 9:33 PM

My patch from bug 12211 implements this.

vvv added a comment.Via ConduitJul 7 2008, 5:20 PM

Fixed in r37263.

MaxSem added a comment.Via ConduitJul 7 2008, 7:06 PM

Reverted by Brion in r32278.

MaxSem added a comment.Via ConduitJul 7 2008, 7:13 PM

argh, 37278

siebrand added a comment.Via ConduitOct 31 2008, 1:22 PM

Reassigned to vasilvv

Verdy_p added a comment.Via ConduitNov 14 2009, 4:13 PM

Adding a gadget and activating it by default is a known source of problems. Somtimes it even breaks the clear intent of users, notably when the functionality breaks or invades their privacy.

For example, some gadgets have been activated in discussion pages that automated sending emails to users to inform them that a page "of interest" had been changed. This option was activated by default, and many users have complained that they now received tons of emails, just because in the past they had worked on many pages, even though they had set all their other preferences to NOT send them any email, but instead made their user page on all wikis to inform other users that they could be contacted in the Talk page of their "home" wiki. This activation caused MediaWiki sites to be reported as really SPAMMING (which it really was: the effect of enabling this option by default was completely equivalent to forcing users to subscribe to a new mailing list without their consent, assuming that they could "opt out" something that is not as easy as you think because the preferences panel is sometimes not usable when it is displayed by default in a language or script that they can't easily decipher and where even the language default is not so easy to locate and change).

Remember this: activating by default a new function that changes the behavior of the site MUST NOT be activated by default, unless there's a clear decision that the new behavior is MANDATORY FOR ALL (in which case there's not even the need for this option), or if the fact of not activating it for all will cause problems for working and supporting users that have not activated it.

Please let users decide by themselves which option they want, but in all cases, do not change the behavior for all users that already have an account where the option was not set.

kaldari added a comment.Via ConduitJan 11 2011, 10:58 PM

There is preliminary consensus to turn on the RefTools gadget by default on
Before I take this proposal to a wider audience, I wanted to decide how it would be implemented technically. If this bug is unlikely to be resolved soon, I may pursue the Common.js route instead. Thoughts?

He7d3r added a comment.Via ConduitJan 11 2011, 11:17 PM

(In reply to comment #7)

There is preliminary consensus to turn on the RefTools gadget by default on
Before I take this proposal to a wider audience, I wanted to decide how it
would be implemented technically. If this bug is unlikely to be resolved soon,
I may pursue the Common.js route instead. Thoughts?

You may want to look in the workaround used for Edittools on Wikimedia Commons. See "setup: function ()" of [[commons:MediaWiki:Edittools.js]] and [[commons:MediaWiki:Gadget-OldEdittools.js]].

MaxSem added a comment.Via ConduitFeb 16 2011, 6:11 PM
  • Bug 27460 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Via ConduitApr 4 2011, 12:51 PM

(In reply to bug 27771 comment #9)

(In reply to bug 27771 comment #8)

> Load by default: pending (bug 13742)

I can do it in 15 minutes, however I need wider discussion.

I'm not sure how the previous implementation was done, but I think such an option should use something like wgDefaultUserOptions (in other words: It would be on by default, and loaded for all anonymous users), but registered users can still go to Special:Preferences and untick the checkbox.

Verdy_p added a comment.Via ConduitApr 4 2011, 3:45 PM

@Krinkle: the idea is to have only SPECIFIC gadgets to be turned on by default after they come to a RELEASE status (and not an experimental status), as if it was a new gadget. All gadgets should go though the experimental status before being released, and in that state they MUST be off by default. This means that the decision to make a gadget ON by default will chnage the user settings that have been activated/deactivated explicitly by some experimenters. As a consequence, there cannnot be a global setting enabling/disabling all gadgets at once for their default setting, given that each gadget (experimental or not) stores its own ON/OFF preference. Making one gadget ON by default can only result of a prior discussion reaching to a concensus (it can be motivated also by the fac that disabling it provides worse results on the site content administration, or too many common errors by users ; enabling it by default should have the effect of simpliying the work from most users).
If you enable a gadget by default, it must also be well maintained across MediaWiki versions: this involves additional work for MediaWiki developers, or at least from administrators of wikis of the WMF before deploying a new version there.
If the change is motivated by a policy, why a gadget ? the only good reason for not implementing it by default is that the gadget may be specific to some wiki sites, and not workable for others, and the policy results from a local concensus and does not necessarily match the policy use elsewhere. It can help recucing the dependencies between MediaWiki developers and site owners thart have installed and are maintaining their own local wiki.

MaxSem added a comment.Via ConduitApr 4 2011, 3:55 PM

My vision of this bug:


  • Less chaotic than Common.js dynamically loading stuff.
  • Faster loading, provided that gadget's JS is ResourceLoader-compatible.
  • Unlike global scripts, gadgets can be disabled by users who don't like them.


  • Butthurt "omg they enabled that preference for me and haven't even asked ME!!1oneone"
  • This system is seemingly easy which may provoke clueless admins to wreck havoc.
kaldari added a comment.Via ConduitApr 4 2011, 6:01 PM

There are two use cases for this bug:

  1. Gadgets that are especially useful to newbies, but not as useful to established users. For example a license-picking wizard on Commons (doesn't exist yet). In this case, by the time a user learns about the Gadget and how to turn it on, they are probably too advanced to need it anymore.
  1. Gadgets that are so useful to a project that the community wants them to be used universally (or nearly so). For example, RefToolbar on (which was moved from a Gadget to Common.js).

My idea of how this would work is that:

  • Gadget definitions (at MediaWiki:Gadgets-definition) would accept a 3rd parameter for 'default state' which could be set to true or false (empty = false)
  • default gadgets would load for all anonymous users
  • all new registered users would have them turned on in their prefs by default
  • if an established user clicks "Restore all default settings" they would get the gadget turned on
  • if the gadget is brand new (and doesn't yet have a saved ON/OFF state) it would default to ON for everyone
  • the only way to mass-switch existing users' prefs would be to delete the existing gadget and relaunch it under a new name with the 'default' param set to true from the start (per the mechanism above)

This would make it impossible for admins to accidentally mass-switch everyone's gadget prefs and cause massive wikidrama, since there would have to be a conscious effort to re-launch the gadget for use case #2. It would also allow us to fulfill use case #1 without pissing off existing users by bombarding them with newbie gadgets that they have to turn off.

kaldari added a comment.Via ConduitApr 4 2011, 6:05 PM

I think my outline above would eliminate both of Max's cons while still keeping all the pros. Do others agree that this would be a good implementation path?

kaldari added a comment.Via ConduitApr 5 2011, 9:32 PM

The WMF Community department wants to start developing some "newbie gadgets" to address the newbie experience problem mentioned in the March 2011 update ( Since this is a blocker, bumping priority to High.

MaxSem added a comment.Via ConduitApr 6 2011, 5:53 PM

The Dark Side I sense in this, but let's try...

MaxSem added a comment.Via ConduitApr 12 2011, 6:12 PM

Done in r85902. Would be great if someone re-checked this, I'm a bit dizzy from all those checkboxes.

Add Comment