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

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

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.

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

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.

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.

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.

(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.

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

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?

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?

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.

In T54141#1312318, @ssastry wrote:

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?

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.

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.

@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 :)

In T54141#1568572, @Neil_P._Quinn_WMF wrote:

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?

The primary benefit I see is that I'd like to enable VE on pages where it will not be enabled globally.

In T54141#1568572, @Neil_P._Quinn_WMF wrote:

@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?

Has Paroid been round-trip tested against Wikisource pages in the main & Page: namespace?
I am guessing there will be a new batch of page corruptions on Wikisource when it is deployed for the Page: namespace, if there has not been specific testing for the Page: namespace. Wikisource has some very odd hacks. Many thanks if this testing has already been done and there are no serious problems when it is deployed.

An alternative would be for wikisource to add an editnotice, which is only shown for VE editors, for pages which have problems with VE. Then it can be more advisory:

"this page may have problems with VE; please check the diff after saving changes. Report bugs at <x> ; if there are no bugs, remove this editnotice by <do y>."