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

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 WebMon, May 25, 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 WebTue, May 26, 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 WebTue, May 26, 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.

Add Comment