Page MenuHomePhabricator

New Wikitext Editor: Previews should use the article-view rendering engine
Closed, ResolvedPublic8 Estimated Story Points

Description

There are a large number of errors where the New Wikitext Editor preview does not match the genuine article view after save. Discussions on projects pages indicate that some of those rendering errors are explicitly CANTFIX/WONTFIX, that the WMF plans is to play whack-a-mole on endless individual rendering errors, and that the WMF is explicitly aiming for less than 100% accuracy due to CANTFIX/WONTFIX issues. These issues appear to be due to using the VE engine (Parsiod etc.) to generate previews, rather than using the genuine article view engine (PHP parser etc.).

The task is for previews to use the genuine article view engine (using PHP Parser etc.), like the current wikitext editor, fixing all of these errors at once.

Strong community consensus that this issue is serious enough to be a deployment blocker: EnWiki Village Pump RFC is here. The key text was:
Actionable Blocker: Article previews. Previews are a critical part of the learning process for new editors, as well as a critical tool for experienced editors. Inaccurate previews will confuse, disrupt, and frustrate. Possible resolutions:

  • We could happily retain our current wikitext editor; or
  • previews must use the article-view rendering engine (this is called the PHP parser), as well as any other relevant parts of the article-view software stack. This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software.

Related Objects

Event Timeline

To avoid a split discussion, see my Technical Collaboration Guideline comment at T154843#2926550.

Based on discussions on project pages this task appears to be a WONTFIX

Could you provide links for context?

The issue was first raised by me 14 weeks ago half way down this thread on Talk:Wikimedia_Product. That was before any project page or documentation even existed yet. "Whatamidoing, can you please please please go to the head of the New Wikitext Editor project and tell them that a new "Wikitext editor" that doesn't have genuine wikitext support is a deal breaker? It has the same Parasoid-based fake wikitext that Flow has. I suspect there would be a consensus against even having it in Beta-features until that "bug" is fixed. I've already saved a screenshot showing the New Editor botching the preview in nine different ways at once, and it's not hard to show lots more. A new wikitext editor that can't give accurate previews is a non-starter."

Four weeks later, after a project page was created, Rogol Domedonfors opened this thread on Talk:2017_wikitext_editor.

When the page 2017_wikitext_editor/Feedback was created over three weeks ago, I opened this thread. In that post I explicitly stated that the issue should be categorized as an actionable blocker. I should have explicitly referenced the Technical Collaboration Guideline.

To be clear, I only posted a small fraction of the rendering issues that I happen to know of. The list of rendering issues that I've found are certainly a negligible fraction of the rendering issues that exist. Some are common issues, some are weird corner cases, but the proposal here is to sync previews with genuine article views to fixing everything at once. It also ensures that previews stay synchronized when any patch alters any aspect of page renders. Running previews through an entirely different rendering engine was a baffling design choice.

Legoktm renamed this task from New Wikitext Editor: Provide genuine article previews to New Wikitext Editor: previews should match article view (use PHP parser).Jan 8 2017, 8:32 PM
Jdforrester-WMF renamed this task from New Wikitext Editor: previews should match article view (use PHP parser) to New Wikitext Editor: Ensure that previews match article view as much as practical.Mar 14 2017, 7:04 PM
Jdforrester-WMF lowered the priority of this task from Medium to Low.
Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.
Jdforrester-WMF removed the point value for this task.
Alsee renamed this task from New Wikitext Editor: Ensure that previews match article view as much as practical to New Wikitext Editor: Previews use the article-view rendering engine. (Consensus this is a blocker issue).Mar 21 2017, 5:46 PM
Alsee raised the priority of this task from Low to High.
Alsee updated the task description. (Show Details)

I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.

Alsee, unless you are personally planning to do a task yourself (e.g., submit code, create design, write documentation, etc.), then you should not be setting its priority field. See https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities

Jdforrester-WMF lowered the priority of this task from High to Low.Mar 21 2017, 6:07 PM

I've corrected the task to inherit from the one it talks about, and re-set the priority. I'm minded to revert the changes made from an accepted task that we would do (make the differences negligible) to one that's invalid (switch over to the legacy system that's being replaced), but I might have missed some nuance. @Alsee, can you clarify?

can you clarify?

The RFC question, closing result, and every response, are available here. If the RFC itself, and the RFC text copied into the task here, aren't sufficiently clear, then I'll need a more specific question of what you want clarified. Over 90% of editors supported one or both issues as deployment-blockers, and almost as many people supported each issue individually. Almost everyone considers the New Editor to be an unacceptable downgrade unless (at least) these issues are sufficiently addressed. I hope you consider that to be a striking and seriously concerning result.

We have all known for years that the number one factor for projects running into problems is lack of early community input. A project to replace our editor absolutely should have had significant community consultation during concept and design phase, so we could all collaborate on what we want and need in a New Editor.

I will try to list every possible path I can imagine ahead. I welcome you to cite any alternative I overlook, and hopefully indicate which one(s) you have in mind.

  1. Engage the community in discussion, trying to generate WMF-community consensus on a mutually acceptable plan.
  2. Deploy only to wikis that want it.
  3. Implement the same kind of previews as the current editor has, per RFC and task description.
  4. Keep the current wikitext editor as default, per RFC and task description.
  5. Push project out as default, against overwhelming community objection that it's a downgrade.
  6. Avoid the issue until deployment is scheduled, and deal with 1,2,3,4 or 5 in panic mode.

I've corrected the task to inherit from the one it talks about, and re-set the priority. I'm minded to revert the changes made from an accepted task that we would do (make the differences negligible) to one that's invalid (switch over to the legacy system that's being replaced), but I might have missed some nuance. @Alsee, can you clarify?

It doesn't explicitly say use the legacy PHP parser, it just says to use whatever is generating the actual views readers see. At least for NWE, I'm not sure what the technical blockers are to using the API's action=parse with some kind of editstash stuff. If/when the default parser changes, that API module will get updated for it anyways.

Whatamidoing-WMF renamed this task from New Wikitext Editor: Previews use the article-view rendering engine. (Consensus this is a blocker issue) to New Wikitext Editor: Previews use the article-view rendering engine.Mar 30 2017, 6:23 PM

I'm copying related concerns submitted at 2017 wikitext editor/Feedback:

  • Accidental misspelling of a category's name is not seen in the preview.
  • List of used templates won't get updated.
  • The effect of {{lowercase title}} or other title-changing code cannot be previewed.
  • Category changes resulting from addition of new templates do not appear in the preview. For example, try inserting a {{Use British English}} template in English Wikipedia.
Pppery renamed this task from New Wikitext Editor: Previews use the article-view rendering engine to New Wikitext Editor: Previews should use the article-view rendering engine.Oct 16 2018, 11:40 AM

To add a current example to the discussion:

The table header in https://de.wikipedia.org/wiki/Vorlage:Charteintrag/Beispiele looks *very* different in the 2017 wikitext preview compared to the actual article.

This is what the header looks like in the actual article:

header_in_article.PNG (174×647 px, 9 KB)

And this is what the preview is showing:
header_in_preview.PNG (384×810 px, 23 KB)

So it's not just some minor difference in the category or title display, but significant differences in the content as well.

Ah, thanks - I didn't know about that one. But wouldn't a change of the rendering engine also fix T212085?

In this case, it actually wouldn't… We have code that specifically removes style tags after rendering the preview (apparently because they used to crash Chrome: T52043). It would remove them all the same no matter where the preview comes from. I'll reply on the other task, I think we can easily fix this, it was just overlooked.

But wouldn't a change of the rendering engine also fix T212085?

It might well, but this task has been largely dormant for almost three years. I think that task will probably be resolved some other way.

Switching to the PHP parser might not make sense in this case given the development roadmaps of Parsoid and NWE, because it would be work that would have to be reversed when Parsoid becomes the default renderer, and NWE is still a beta feature. Unless somehow Parsoid gets abandoned altogether (which doesn't really seem likely at this point), I think this task will eventually end up being closed as invalid/wontfix.

@Tkarcher alas, no -- that's about how dependencies bundled with the preview markup are applied. Which parser is used makes no difference.

As an aside, not speaking as the person prioritizing work or anything, with the current Parsoid efforts (it's in PHP now!) and progress towards a single parser, I suspect that this task is going to eventually be resolved by that switch-to-Parsoid happening and getting us "previews use the article-view rendering engine"... but not in the sense the task originally meant.

EDIT: I didn't reload the page before commenting, so the preceding two comments basically covered what I said here.

Change 808926 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/VisualEditor@master] Wikitext mode: Use action=parse for preview

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

Change 808926 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Wikitext mode: Use action=parse for preview

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

EAkinloose added a subscriber: EAkinloose.

I checked to see that contents and formatting work fine in preview and after publish following edits with the New Wikitext Editor. However, feel free to reopen this ticket if you still notice glitches with the New Wikitext Editor preview.

ppelberg claimed this task.