Page MenuHomePhabricator

User preference to disable VisualEditor
Closed, ResolvedPublic

Description

It's strange that I can't find a bug for this. Lots of user on en.wiki complained loudly about this [1], but nobody succeded to write a bug report for it? Well, here it is:

Please provide an option in user preferences to turn VE off. Some users just don't like it and don't want to have an extra tab which they don't use anyway. The gadget isn't perfect, as the tab might appear for short time before it is removed again, and has to updated when VE integration changes. The only reason I found for why there is no such option is this:

"It was planned, but the code turned out to be seriously buggy at the last minute. Getting it really, truly off (rather than just covered up) is more complicated than expected." Whatamidoing (WMF) (talk) 06:32, 2 July 2013 (UTC)

Now with the minimized amount of code that is loaded at startup, it is acceptable to load the code, but just not to execute it. Adding

if ( !mw.user.options.get( 'visualeditor-enable' ) ) {
return;
}

near to the end of modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js should be all that's really needed.

[1] https://en.wikipedia.org/wiki/Wikipedia:Vpt#.22Opt_out.22_of_VE_needed_under_preferences


Version: wmf-deployment
Severity: enhancement
URL: https://en.wikipedia.org/wiki/Wikipedia:Vpt#.22Opt_out.22_of_VE_needed_under_preferences
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52086

Details

Reference
bz50929

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:56 AM
bzimport set Reference to bz50929.

To disable: Preferences > Gadgets > Editing (section) > checkmark for "Remove VisualEditor from the user interface" > Save

This is probably mentioned on http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback

(Quote from comment #0)

The gadget isn't perfect, as the tab might appear for short time before it is
removed again, and has to updated when VE integration changes.

This should be in the obvious place, in the editing tab of user preferences, not a gadget.

Created attachment 12827
en.wp temporary workaround

Since I doubt this will get fixed any time soon, I have implemented a change to a label, to redirect users with words from on preferences tab to another.

Attached:

Screen_Shot_2013-07-11_at_11.25.01.png (237×495 px, 19 KB)

  • Bug 51179 has been marked as a duplicate of this bug. ***

This is actually a site request for the English Wikipedia right now, as this preference is enabled everywhere else right now. Changing Product/Component accordingly.

This will not be a request only for English Wikipedia any longer, as soon as the VE is activated by default on Wikipedias in other languages. Keep that in mind!

(In reply to comment #3)

This should be in the obvious place, in the editing tab of user preferences,
not a gadget.

Yep.

(In reply to comment #6)

This is actually a site request for the English Wikipedia right now, as this
preference is enabled everywhere else right now. Changing Product/Component
accordingly.

Can you explain what the code in this area looks like? There _was_ a user preference previously, it's just gone missing. Is this simply a matter of setting a configuration variable?

(In reply to comment #9)

Can you explain what the code in this area looks like? There _was_ a user
preference previously, it's just gone missing. Is this simply a matter of
setting a configuration variable?

Yes, it's just a matter of removing "$wgHiddenPrefs[] = 'visualeditor-enable';" in CommonSettings.php.

Great, thank you.

I'm marking this bug with the "easy" keyword accordingly.

(In reply to comment #7)

This will not be a request only for English Wikipedia any longer, as soon as
the VE is activated by default on Wikipedias in other languages. Keep that in
mind!

just in case what Bartos wrote is not 100% clear:

The extension already implement a user-selectable enable/disable switch - nothing should be done there.
LocalSettings.php for enwiki specifically removes the choice, by setting the line

"$wgHiddenPrefs[] = 'visualeditor-enable';"

this bug is basically a request to delete this line from enwiki's LocalSettings.php, and thus allowing users to opt-out of VE.

a derivative request would be such: once VE is enabled by default on other wikis, please do not to add such a line to their LocalSettings.php.
the second part is a "forward looking" request, i.e. it's a request not to do something in the future, without actually knowing if there's any intention to do it...

(as a side, it seems that the decision to remove user's switch was not a good one: the main result of this decision was that on enwiki, someone had to write a special gadget for disabling VE, instead of just using the built-in switch...)

peace.

Change 73565 had a related patch set uploaded by Odder:
(bug 50929) Remove 'visualeditor-enable' from $wgHiddenPrefs

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

  • Bug 51389 has been marked as a duplicate of this bug. ***

That would reopen bug 48666 Make VisualEditor a hidden preference.

Per https://en.wikipedia.org/w/index.php?title=User_talk:Eloquence&diff=564621335&oldid=564492863 and other lengthy discussion, this is and remains a WONTFIX.

VisualEditor is switched on or off at the wiki-level, not on the per-user level. The fact that there is a temporary artefact of the alpha roll-out still around in the code that allows us to expose this option to users for the next few weeks (until it too goes away once the alpha roll-out is no longer needed) does not mean we should dishonestly mis-lead users into thinking that we are supporting this as a preference, which is what implementing this request would do.

(In reply to comment #16)

Per
https://en.wikipedia.org/w/index.php?title=User_talk:
Eloquence&diff=564621335&oldid=564492863
and other lengthy discussion, this is and remains a WONTFIX.

This is one user's talk page. What discussion are you referring to? Is the link at the top of the page no longer the consensus? Also I'd like to know exactly what reasoning there is for having this preference hidden.

Tyler, please follow the entire link in comment 16.

This discussion is occuring on wikitech-l as well: http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070560.html

It's probably better to continue the discussion on the mailing list, rather than to abuse bugzilla.

(Just trying to synchronize the conversation.)

(In reply to comment #18)

Tyler, please follow the entire link in comment 16.

I did. It's only 3-4 people talking on a talk page. Kind of pales in comparison to the numerous people who supported this in the original link.

This discussion is occuring on wikitech-l as well:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070560.html

It's probably better to continue the discussion on the mailing list, rather
than to abuse bugzilla.

(Just trying to synchronize the conversation.)

Agreed. I've continued the discussion there.

Have you guys not read http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/RFC there is a clear consensus, 57 vrs 6, for "VisualEditor should have a way to be turned off fully, easily, and without continuing to leech resources". Many people don't want it the feedback page is constantly getting "how do I switch this off?" threads. Failure to implement this feature is causing more work for those on the wiki and a politically very bad decision.

@Richard Morris: Please, bugzilla is a tool for developers, not a discussion forum. Please discuss this on the wikitech-l mailing list (url above, or subscribe at https://lists.wikimedia.org/mailman/listinfo/wikitech-l) or at the RFC you linked to, or on a Talk page. Anywhere, really, except for bugzilla.

Others: please do not respond here to Richard Morris or others. Refrain from the temptation, whether you agree with him or not. Make your point on one of the discussion sites (again: mailing list, talk page, RFC, IRC) not in bugzilla.

Thanks.

Please do not discuss on this bug. The topic is on wikitech-l which has much more audience and is way easier to handle such long discussions :-]

Thread starts at:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070560.html

C. Scott Ananian: you're out of line.

Bugzilla is regularly used for discussion (among devs and non-devs alike) and calling it abuse (comment 18) to use Bugzilla's comments field for discussion isn't appropriate at all.

Richard Morris' comment (comment 20) correctly points to on-wiki discussion that's directly relevant to this bug. It's long-standing practice to cross-reference on-wiki consensus-gathering discussion with Bugzilla bugs.

https://gerrit.wikimedia.org/r/#/c/75542/ was merged today, but it is only a dirty workaround that doesn't fix the actual problem.

What happens when VisualEditor goes out of beta? Will editors that have turned it off be required to switch to it? What if they'd prefer to keep using source editing?

Noting that the main issues causing people to disable VE are

  1. bloat (this may be more perceived than real; the VE init.js isnt very large, and the scaffolding is used for other features besides VE) and
  2. the UI for edit section links (which is bug 50688 and bug 50540).

I am optimistic that both will be resolved before VisualEditor goes out of beta.

Change 73565 abandoned by Hashar:
(bug 50929) Remove 'visualeditor-enable' from $wgHiddenPrefs

Reason:
A preference to temporarily disable VisualEditor has been introduced in the VisualEditor extension itself : https://gerrit.wikimedia.org/r/#/c/75541/

This change is thus no more needed.

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

Sorry, but this is clearly *not* fixed!

  • The eye-wash preference in VE is nonsense and will be gone quickly when VE comes out of beta.
  • The core of the problem - disabling VE when one surely will never use it - will not be solved by this hack.
  • The failure by WMF (deploying a buggy beta software to everybody by default) is poorly concealed by this change but not solved either.

In fact you're even working against your own goals with this change: In the beta phase where feedback by editors is needed most you're now offering a preference to disable VE. When VE becomes stable and feedback is not that necessary anymore the preference will be gone, and the same discussion you're trying to mute with this change will start again.

Please reopen this bug, accept https://gerrit.wikimedia.org/r/73565, so we have a real fix in place!

This bug is about having a user preference to disable VisualEditor which is exactly what has been implemented by https://gerrit.wikimedia.org/r/#/c/75541/ . It is the proper way to handle this, not $wgHiddenPrefs :-D

The fact that the preference might be gone after VE is out of beta is a different problem. For now the request has been fulfilled as far as I understand it. Just check the "Temporarily disable VisualEditor while it is in beta" in the user preference and VE is gone.

Sorry, your perception of this bug is pretty messed up.

Thhis bug is about "disabling VE", *not* about "disabling VE during beta period".

The patch clearly doesn't solve this problem.

For what it's worth, I agree with hashar. The bug as filed is resolved: there's now a user preference in the appropriate tab ("Editing") that fully disables VisualEditor.

I think we should deal with the future in the future. :-)

So you will reopen this bug as soon as VE gets stable? Promised?

I agree with hashar as well. And who knows, maybe hopefully by the time VE is out of beta this preference will not be really necessary (per comment 25). I'm pretty sure we're got at least a few months before we'll have to worry about that.

[This comment is about the generalisation in the VE extension of the deployed patch, I open the bug 52086 for this specific generalisation inside the VE product.]

I can see the logic behind the introduction of the new preference (use a negative preference instead of a positive to use it on wikis where the VE is the default editor), but for the sake of generality of the VE extension it would be better to name it as "visualeditor-preference-disable: Disable VisualEditor" (see bug 52086).

And the temporary messages related to the deployment-test in the Wikimedia environment could be overriden in the WikimediaMessages extension. E.g.

"visualeditor-preference-enable: Enable VisualEditor (experimental, [[{{int:visualeditor-feedback-link}}|please help in reporting bugs]])"
"visualeditor-preference-disable: Disable VisualEditor [during the beta phase] (but [[{{int:visualeditor-feedback-link}}|please help in reporting bugs]])"

(I guess in this case the WikimediaMessages section in InitialiseSettings.php should be move below the VisualEditor section)