Page MenuHomePhabricator

VisualEditor should retrieve content of all Page: pages wikitext editor field when switching from WikiEditor
Closed, ResolvedPublic8 Estimated Story Points


When switching from WikiEditor editor to VisualEditor only the content of wpTextbox1 is retrieved and not all the fields (wpHeaderTextbox, wpTextbox1, wpFooterTextbox and wpQuality)

ProofreadPage should be able to override ArticleTargetLoader.requestPageData in order to retrieve content from all fields

Event Timeline

Tpt created this task.Jun 25 2016, 4:39 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 25 2016, 4:39 PM

This problem is not confined to ProofreadPage, it happens on regular articles too.

Tpt moved this task from Backlog to Top priority on the ProofreadPage board.Jun 26 2016, 12:57 PM
Jdforrester-WMF triaged this task as Unbreak Now! priority.Jun 29 2016, 5:29 PM
Restricted Application added subscribers: Luke081515, TerraCodes, Urbanecm. · View Herald TranscriptJun 29 2016, 5:29 PM

Yes, but at this stage isn't even set up so we can't go and get a function in the appropriate target to ask it for wikitext to send.

This problem is not confined to ProofreadPage, it happens on regular articles too.

How does this cause issues in regular articles?

@Jdforrester-WMF Does someone in your team plans to work on it soon or is an external change proposal welcome? As the loading of the Wikitext edit form content is not part of the ArticleTarget interface yet, this change is probably going to be a bit tricky.

How does this cause issues in regular articles?

We build a fake read page, so stuff like the categories list is missing.

Jdforrester-WMF set the point value for this task to 8.Aug 1 2016, 4:57 PM

I've been thinking about this today, and recently moved from using .val() to .textSelection( 'getContents' ) in VE for another piece of editing software to help with switching in a similar case (WTE->VE) - T135747. Maybe what we could do is have a hidden input element that's just used by JS to store a jquery.textSelection-style function.
ProofreadPage could register a getWikitext handler (which would get stored in the input element's data, and would know how to build the full wikitext from wpHeaderTextbox, wpFooterTextbox, and wpQuality as well as wpTextbox1), overriding the default of something like this.parent( 'form' ).find( '#wpTextbox1' ).textSelection( 'getContents' ). VE would call it when appropriate (replacing all our current textSelection calls), and magically get back the full wikitext to submit to RB.
@Esanders, @Krinkle: Any thoughts/objections?

Storing a function in data seems a bit strange, but I @Krinkle will have a better idea of how the get wikitext stuff should work.

Restricted Application added a subscriber: Jay8g. · View Herald TranscriptSep 9 2016, 6:05 PM
Esanders removed Esanders as the assignee of this task.Sep 9 2016, 6:05 PM
Esanders updated the task description. (Show Details)
Zppix removed a subscriber: Zppix.Oct 30 2016, 5:52 PM
Aklapper lowered the priority of this task from Unbreak Now! to High.Dec 5 2016, 10:15 AM

Lowering priority to actually reflect reality ("Unbreak Now!" priority for nearly half a year and no assignee set by the VisualEditor team).

Elitre added a subscriber: Elitre.Jan 2 2017, 11:48 AM

Change 331642 had a related patch set uploaded (by Esanders):
Rebuild full wikitext when switching from WTE to VE

Change 331642 merged by jenkins-bot:
Rebuild full wikitext when switching from WTE to VE

Tpt closed this task as Resolved.Mar 27 2017, 4:05 PM
Tpt claimed this task.

Resolved by Ed's change( thank you!).

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptMar 27 2017, 4:05 PM