Page MenuHomePhabricator

[FEATURE REQUEST] Endpoint that renders user edit previews in the same format as mobile-html
Open, LowPublic

Description

Background information

Apps currently use the mediawiki api with action=parse and mobileformat=true to transform user-generated wikitext into a previewable page. Ideally, there'd be an endpoint that returns the user-generated wikitext as a page with formatting that matches the new article viewing endpoint, mobile-html.

Event Timeline

JoeWalsh created this task.Dec 3 2018, 3:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2018, 3:54 PM
bearND renamed this task from [FEATURE REQUEST] Endpoint that renders user edits in the same format as mobile-html to [FEATURE REQUEST] Endpoint that renders user edit previews in the same format as mobile-html.Dec 3 2018, 4:06 PM

I wonder if we should do something similar to https://en.wikipedia.org/api/rest_v1/#!/Transforms/post_transform_wikitext_to_html_title_revision and use the same as the backend service, just run the transformations on top of it.

@Joe Do you only need one single section in there + a preview of references defined in that section?
//cc @ssastry

@bearND after getting clarification of the product plans, it'd be ideal if we could either preview a single section or the entire article. Our main use case will be editing single sections, but there will also be the possibility of editing the entire article.

@bearND @JoeWalsh note that there is something to be aware of here with previewing a section. If a section references a named ref that is defined elsewhere in the article, when you submit that wikitext for preview, that named ref will be flagged as being undefined (same as the wikitext editor which says "Cite warning: <ref> tag with name SOME_NAME_HERE cannot be previewed because it is defined outside the current section or not defined in this article at all."). So, if you need behavior that is different than that, it gets complicated.

Also, it's gonna be interesting to implement this. MCS output is based on Parsoid HTML, and the HTML is not POSTed to MCS, it GETs it from storage. So in order to implement the transform endpoint, we will need MCS to support a completely different request flow. Not that it is impossible, it just might be a bit more work than expected.

bearND added a comment.Dec 3 2018, 9:39 PM

@Pchelolo Yeah, that's why I think this new endpoint would probably be similar to /transform/wikitext/to/html{/title}{/revision}.

@ssastry Isn't the above endpoint what VE uses? Or are they using /transform/section-changes/to/wikitext/{title}/{revision} instead?

@ssastry Isn't the above endpoint what VE uses?

VE doesn't need to use that -- it GETs the stored HTML.

But, afaik, the 2017 wikitext editor hits that endpoint.

@Pchelolo Yeah, that's why I think this new endpoint would probably be similar to /transform/wikitext/to/html{/title}{/revision}.

Externally - yes. but in order to process the POSTed content, we would need to first hit Parsoid to produce HTML (we have means of doing that) and then hit MCS to reparse the HTML into mobile oputput. Currently MCS is not capable of taking in HTML and we do now want to temporary store that. That's what I mean saying we would need some more work to be done on MCS side.

@Pcheclolo I was thinking the new PCS endpoint would call the corresponding Parsoid endpoint (internally).

@bearND Currently MCS (PCS) only talks to MW and RB. Adding Parsoid into the mix would not be my preferred way to go. Adding an endpoint to MCS (PCS) where we can POST the HTML and get all the transformations done would feel more natural. We eventually can even change everything in MCS(PCS) to do POST based API - it will be more efficient then what we're doing now. One less round trip, one less load up of HTML from storage => less latency.

@JoeWalsh Please tell when you need this to be done so that we could plan accordingly.

@ssastry that behavior is fine for references defined elsewhere in the article

@Pchelolo no urgent deadline on our end. This is a nice-to-have for consistency, we can continue to use MW in the meantime

bearND triaged this task as Low priority.EditedJan 11 2019, 10:46 PM

Setting priority to low since the backend work for this seems quite complicated and the workaround of using MW API seems sufficient currently.

Adding Parsoid into the mix would not be my preferred way to go.

Yeah, sorry meant to say talk to Parsoid via RESTBase. I did not men to imply proposing MCS to talk directly to the Parsoid servers.