@Jdforrester-WMF had this mock around T116417

the switch basically acts as VE being primary mode. so Visual editing ON or visual editing OFF, instead of VE <> WT

I'm wondering for the timeline of the rollout for this project. Is this 2 to 3 years away from going live, or are we likely to see changes to the wikitext editor within the next 6-12 months on production sites?

@Pine Our quarterly goal is to make it available as Beta Feature.

@Esanders OK. How many months until it goes to production? I realize that an exact number is impossible to know, but an estimate would be helpful.

By the way, I was wondering what the plan is for implementing yet a third editing interface without inducing more visual clutter. I very much like the https://nirzar.github.io/prototypes/ve/switch/wikitext/wikitext.html demo concept of using the [[ ]] icon to stay within the VisualEditor window while having the option to switch to wikitext. However, I wonder if that choice of visual representation will create confusion with the link icon in the editor. I don't know what to propose as an alternative, but I do think that it could be confusing.

Also, do you have a name for this third form of editing? I am thinking of something like "Visual source editor".

I now get error 504 on https://visualeditor-test.wmflabs.org/w/index.php?title=Main_Page&action=edit

In T104479#2602874, @Paladox wrote:

I now get error 504 on https://visualeditor-test.wmflabs.org/w/index.php?title=Main_Page&action=edit

Parsoid seems to be down, and failing to start:

vagrant@mediawiki-vagrant:/vagrant/srv/parsoid$ node src/bin/server.js --num-workers 2 --config /vagrant/srv/parsoid/src/localsettings.js
Error while reading config file: YAMLException: end of the stream or a document separator is expected at line 7, column 15:
            prefix: 'localhost',
                  ^

Fixed.

In T104479#2603489, @Esanders wrote:

Fixed.

How? I did a pull on the vagrant repository, which fixed the parsoid config, but RB began returning HTTP 500 instead.

I updated the parsoid config yaml to the new format, then vagrant git-updated everything

In T104479#2603646, @Esanders wrote:

I updated the parsoid config yaml to the new format, then vagrant git-updated everything

Not sure what you needed to change. VE/RB/Parsoid in Vagrant work for me out of the box after:

$ git pull
$ vagrant git-update --force

@Esanders Hi, when going to https://visualeditor-test.wmflabs.org/w/index.php?title=Main_Page&action=edit it dosent show the new wikitext editor, it only shows visualeditor, also when I try to switch back to wikieditor it says this

SCRIPT5007: Unable to get property 'blur' of undefined or null reference

MUST-FIX: Don't use Parasoid. It results in assorted preview errors. I briefly tested the New Editor, and tossed together this screenshot with a random assortment of problems. The left side is the New Editor preview, the right side is the current wikitext editor preview, and both are previewing the same wikitext. Hint: The right side render is correct.

@Alsee are you using Mathoid? The error is likely related to the fact that you use Parsoid (and RESTBase too?) but not Mathoid.

In T104479#2694841, @mobrovac wrote:

@Alsee are you using Mathoid? The error is likely related to the fact that you use Parsoid (and RESTBase too?) but not Mathoid.

The image displays NINE problems. Not just the math error. I logged into a fresh account WMF's test server to test New Editor, so I'm not using anything other than the WMF's setup.

Flow (on mediawiki.org and on EnWiki, and any other wiki) has the same problems, but far worse because Flow's wikitext is completely fictional. Flow doesn't even save in wikitext. Saving in Flow can mangle or destroy the original wikitext. Merely previewing can mangle or destroy wikitext. Repeated previews can progressively mangle wikitext to an unlimited extent. Merely reverting an edit can damage the original content.

The current discussion on EikiWiki is whether the WMF will amicably uninstall the Flow extension, or whether we're going to run an RFC on removal of the extension. Of all the problems with Flow, this fake-wikitext system is the most absurd and irritating. I find it incomprehensible that the WMF tried to build a new wiki-discussion-system that doesn't actually support wikitext. Talk pages are not chatboards. They are wiki-workplaces.

The community is not going to accept a new wikitext editor with broken wikitext support. Simply replace the Parasoid-preview with the same render used by the current wikitext editor, the same render that is used on article pages. That inherently gives a perfect preview of what you'll get when you save the page. Not only is it important for experienced editors, it's even more important for new editors learning how to edit. Having inexplicably inaccurate previews will be frustrating, and will sabotage their on-ramp process.

@Alsee: Can you provide the Wikitext that you were previewing?

In T104479#2720652, @kaldari wrote:

@Alsee: Can you provide the Wikitext that you were previewing?

I did try to provide the wikitext previously. However the WMF has converted the relevant talk pages to Flow, and Flow is so completely broken that it doesn't merely misrender it, Flow literally can't save the wikitext. I spent a stupid amount of time trying to do so. Flow destroys the wikitext when you try to preview it or save it. It was very frustrating.

<gallery>File:Example.jpg|Caption<ref>Ref 1</ref></gallery>

* [[Link 1]]
* [[World|Link 2]]
* [<!--comment-->[Copy source|Link 3]]
* [http://example.com Link 4]

{{#if:redflag|<span style="color:red;|<span style="}} font-weight: bold">Red.</span><ref>Ref 2</ref>

<div><table><td><li>went up the hill<div>
to fetch a pail of water
</div>Jack and Jill</table></div>

<hiero>A1-B2-D4-E5</hiero><hiero>F6 p*p*p:t*t*t</hiero>

<math>\begin{align}
 f&=\frac{a-b}{a}.
\end{align}</math>

== References ==
<references />

Note Link 1 was a generic redlink, the page name was "World" making Link 2 a generic blacklink, Link 3 pointed to any generic bluelinked page, and Link 4 was a generic external link.

My primary point is that there's a large and unknown number of cases where Parasoid gets the preview wrong. Using two different engines for rendering article pages and previews is a fundamentally broken design. The specific examples illustrated are incidental to the fundamental problem. Playing whack-a-mole on a few random bugs will not fix the fundamental problem. Preview should work just like it does in the current wikitext editor, preview should use the article rendering engine. That inherently ensures accurate rendering for all cases. Accurate previews is expected by experienced editors, accurate previews is particularly critical for new editors.

Using two different engines for rendering article pages and previews is a fundamentally broken design.

Ironically, I think that's one of the main impetuses for the new Wikitext editor—to allow MediaWiki to eventually standardize on a single rendering engine, that being the Parsoid engine used by VisualEditor. I'm not actually involved in this project though, so don't quote me on that.

@kaldari, sounds like MediaWiki is going to be fully rewritten on javascript

In T104479#2733380, @kaldari wrote:

I'm not actually involved in this project though, so don't quote me on that.

Even with this sentence kept in mind, let me allow my comment to:

standardize on a single rendering engine, that being the Parsoid engine used by VisualEditor.

I hope not, that would be a de facto killer for third parties, who can't host their own parsoid service :)

However, this isn't the focus of this task :P

third parties, who can't host their own parsoid service

Why can't they? Some people are already doing so on private wikis.

In T104479#2734658, @Whatamidoing-WMF wrote:

third parties, who can't host their own parsoid service

Why can't they? Some people are already doing so on private wikis.

Because some third parties (at least these one, I know) use a "normal" webspace or other hosting services, where they just can upload files. Installing and managing services on the other hand isn't something they want (or can do).

I'm sure if MW switches to requiring NodeJS there will be an appropriate forum for people to raise their concerns, however this ticket is neither the place nor the time :)

@Alsee Are these known Parsoid issues? If not could you file them as such. Thanks.

When previewing an edited page redlinks are not red and weblinks do not come with the external link icon.

@Gradzeichen please see T153535