Provide a modern wikitext editor
Open, NormalPublic40 Story Points

Tokens
"Love" token, awarded by Liuxinyu970226."Like" token, awarded by Pine."Like" token, awarded by Harej."Barnstar" token, awarded by Florian."Love" token, awarded by eranroz."Barnstar" token, awarded by TheDJ."Like" token, awarded by Shizhao.
Assigned To
Authored By
Jdforrester-WMF, Jul 1 2015

Description

This will be a new editor, not a modification to the existing wikitext editor, because we want to avoid suddenly disrupting editors and breaking all existing gadgets.

MVP (for initial release as a Beta Feature) is described in more detail at T141149: Provide a Beta Feature of a modern wikitext editor integrated into the visual editor.

High importance:

  • Section editing
  • Desktop, tablet and mobile-suitable (dynamic/responsive)

Nice-to-haves:

  • Syntax highlighting
  • Code folding

A rough mockup is here. To see the wikitext editor, click the brackets icon in the top-right corner.

A rough demo video as of mid-May 2016 is https://www.youtube.com/watch?v=jgd2ZHOZGBE.

You can see it in action at https://visualeditor-test.wmflabs.org/wiki/Wiki_markup?veaction=editsource

See also: mediawiki.org page

Related Objects

StatusAssignedTask
OpenEsanders
OpenNone
OpenNone
OpenNone
OpenNone
OpenEsanders
OpenNone
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
DuplicateNone
OpenNone
ResolvedJdforrester-WMF
ResolvedEsanders
Resolved AlexMonk-WMF
ResolvedEsanders
OpenNone
There are a very large number of changes, so older changes are hidden. Show Older Changes
Esanders updated the task description. (Show Details)Jul 22 2016, 8:40 PM
Jay8g added a subscriber: Jay8g.Jul 23 2016, 3:32 AM

Change 229567 merged by jenkins-bot:
Wikitext surface alpha feature

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

At least by the time of the real production release, and ideally beforehand, I'd like us to get T116417: Come up with a better re-usable UI concept for a button to switch editor-mode; the current one is confusing, and hard to discover done as well.

@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


Ltrlg added a subscriber: Ltrlg.Aug 23 2016, 6:10 AM
Pine added a subscriber: Pine.Aug 24 2016, 4:42 AM
Pine added a comment.Aug 24 2016, 4:45 AM

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 awarded a token.Aug 24 2016, 4:46 AM
Elitre updated the task description. (Show Details)Aug 24 2016, 10:14 AM

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

Pine added a comment.EditedAug 27 2016, 4:59 AM

@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".

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.

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

Esanders added a comment.EditedSep 1 2016, 11:01 PM

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

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

Trizek-WMF updated the task description. (Show Details)Sep 20 2016, 8:30 AM
Izno added a subscriber: Izno.Sep 27 2016, 7:59 PM
Alsee added a subscriber: Alsee.Oct 5 2016, 8:06 PM

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.

Alsee added a comment.EditedOct 6 2016, 7:02 AM

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

Nnvu added a subscriber: Nnvu.Oct 12 2016, 1:19 PM

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

@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

Florian added a comment.EditedOct 21 2016, 7:31 AM

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.

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.

Cirdan added a subscriber: Cirdan.Dec 13 2016, 8:20 PM
Restricted Application added a subscriber: Luke081515. · View Herald TranscriptDec 20 2016, 10:31 PM

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

Nnvu removed a subscriber: Nnvu.Jan 1 2017, 11:24 PM
Nnvu added a subscriber: Nnvu.