VisualEditor: Provide a mechanism to disable VisualEditor on a given page (to be used if it corrupts said page)
Closed, DeclinedPublic

Description

There are many pages for which VisualEditor is broken. In some cases, the page syntax can be changed to avoid the problem. In other cases (such as nlwp's largethumb, dewp dab pages, enwp episode lists), the design affects many pages, and the only feasible solution is to fix the parser. While we wait for fixes, the VE should be disabled on those pages known to be affected.

The set of pages to be VE-disabled could be a category, if you trust the villagers..:-)
Or a title blacklist in MediaWiki: namespace so it is admin only
Or a regex blacklist in MediaWiki: namespace so it is easier to blacklist all pages which include a certain element.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53767

bzimport added a project: VisualEditor-MediaWiki.Via ConduitNov 22 2014, 1:54 AM
bzimport set Reference to bz52141.
jayvdb created this task.Via LegacyJul 27 2013, 1:30 PM
jayvdb added a comment.Via ConduitJul 28 2013, 6:08 AM

A temporary solution is being developed: {{Disable VE top}} and {{Disable VE bottom}}

https://en.wikipedia.org/wiki/Template:Disable_VE_top

jayvdb added a comment.Via ConduitJul 28 2013, 9:34 PM

If WMF has spare compute power, Parsoid could flag which pages it _may_ break, and tell the VE extension to not enable itself on those pages.

Eloquence added a comment.Via ConduitAug 3 2013, 12:02 AM
  • Bug 52489 has been marked as a duplicate of this bug. ***
Eloquence added a comment.Via ConduitAug 3 2013, 12:03 AM

It would indeed be helpful to be able to selectively disable VisualEditor (we should indicate to a user who'd otherwise see VisualEditor that it is disabled, to reduce confusion).

A hidden blacklist category could be included in a page or template to achieve
the desired effect, and could be used by developers to prioritize roundtripping
issues.

MZMcBride added a comment.Via ConduitAug 3 2013, 12:04 AM

I don't like the idea presented in bug 52489 (a blacklist category). VisualEditor simply shouldn't break pages ever. Users shouldn't be required to shield articles from it; that's a bit insane.

Eloquence added a comment.Via ConduitAug 3 2013, 12:08 AM

Obviously VE/Parsoid shouldn't cause breakage - the goal would be to keep membership of that category close to zero at any given time. But if and when things do break, it'd be good to have an official mechanism to deal with it, rather than just template hacks.

MZMcBride added a comment.Via ConduitAug 3 2013, 12:14 AM

(In reply to comment #6)

Obviously VE/Parsoid shouldn't cause breakage - the goal would be to keep
membership of that category close to zero at any given time. But if and when
things do break, it'd be good to have an official mechanism to deal with it,
rather than just template hacks.

Bugzilla is the official mechanism for dealing with breakages.

While it's easy to say that the goal would be to keep the category membership near zero, it sounds like (from reading comment 0) that this category would quickly include tens of thousands of pages.

jayvdb added a comment.EditedVia ConduitFeb 15 2014, 3:02 AM

An interesting solution is to add a wikitext magic word __NOVISUALEDITOR__ to disable it in contexts it might otherwise be enabled.

https://www.mediawiki.org/wiki/Thread:Extension_talk:VisualEditor/Behavior_switch_NOVISUALEDITOR

Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 4:16 PM
Rdicerb added a subscriber: Rdicerb.Via WebMay 25 2015, 2:23 PM

This is an old task, so it would be good to get some specificity around whether this is still an issue and under which circumstances. Can someone please re-validate this issue?

GWicke added a comment.Via WebMay 26 2015, 8:33 AM

I'm pretty certain that the largethumb template issue has been fixed, and based on the lack of activity and concrete reports of ongoing large-scale corruptions it seems possible that the work-around described in this task might no longer be needed. @ssastry and @Jdforrester-WMF: Could you chime in?

ssastry added a comment.Via WebMay 26 2015, 12:04 PM

Yes, the largethumb template issue has been fixed since early 2014.

The only large-scale corruptions that have been reported have been due to transient bugs on deploys (which tend to be fixed quickly or deploys reverted). There are some pages on which Parsoid could potentially cause corruptions, but those one-off bugs tend to get fixed promptly. There are no large sets of pages that I am aware of that aren't handled properly on the Parsoid end. So, as far as I know, from the Parsoid perspective, this workaround shouldn't be needed.

Trizek-WMF added a subscriber: Trizek-WMF.Via WebJun 22 2015, 3:05 PM

Yes, the largethumb template issue has been fixed since early 2014.

The only large-scale corruptions that have been reported have been due to transient bugs on deploys (which tend to be fixed quickly or deploys reverted). There are some pages on which Parsoid could potentially cause corruptions, but those one-off bugs tend to get fixed promptly. There are no large sets of pages that I am aware of that aren't handled properly on the Parsoid end. So, as far as I know, from the Parsoid perspective, this workaround shouldn't be needed.

@Jdforrester-WMF, what do you think about declining this bug?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldJul 24 2015, 12:30 AM
Jdforrester-WMF closed this task as "Declined".Via WebJul 24 2015, 12:31 AM
Jdforrester-WMF claimed this task.

Agreed.

IKhitron added a comment.Via WebWed, Aug 5, 10:19 AM

Hello, @Jdforrester-WMF. You merged T107426 here, but it is not the same problem. The main part over there was an ability to ENABLE the VisualEditor on a page in VE-disabled namespace. Thank you.

Kipod added a comment.EditedVia WebSun, Aug 23, 5:46 PM

i see this is "closed, declined".
since another ticket, opened by me, was "closed, duplicate" pointing here, i would like to request to reconsider.
implementing my request should be very easy, controllable, requres no changes outside VE, and very simple change inside VE, and, oh, by the way, will also close/solve this one. so i paraphrase my previous request here:

there are good reasons (i guess) not to enable VE on some namespaces, and specifically "project" namespace, but it would be desirable to be able to override it for specific pages.

i was thinking something like adding two new magic words:

__ENABLE_VISUAL_EDITOR__
__DISABLE_VISUAL_EDITOR__

this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE.

implementing these two switches is 100% risk-free (currently there are no pages that use these magic words), and should be easy enough to implement, such that the switch that decides wheter or not to enable VE will test for these magic words, and make the correct decisiosn.

so, implementing it would be risk-free, easy, and will soleve at least two legitimate requests that came from the community (with some 19 members subscribing to this ticket).

maybe you should consider reopening. unfortunately i can't offer a patch to prove my claim that it's "easy"...

peace.

Neil_P._Quinn_WMF added a comment.Via WebMon, Aug 24, 6:24 PM

@Kipod, whether it's easy or hard it not really the main issue. The main issue is whether the benefits outweigh the downsides—and unfortunately there are downsides. These magic words would increase complexity, sometimes stay on pages long after the need is gone, and risk confusing users when no visual editor tab appears on a page where they expect to see it.

Today, the visual editor corrupts pages far less often than it did when this bug was filed two years ago, which makes me think that the benefits of these magic words would be small. Are there other reasons for having them?

this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE.

That only works for people who turn off the visual editor completely. If you disable the visual editor on a given page, I can no longer choose to use it.

Peace to you as well :)

Add Comment