See blocking tasks.
Description
Description
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Open | None | T130639 All known clients of Parsoid HTML that require data-mw should fetch data-mw separately (if using RESTBase) or process the data-mw blob in Parsoid's pagebundle API response (if using Parsoid directly) | ||
| Open | None | T124837 Update Flow for Parsoid changes re data-mw | ||
| Declined | None | T125885 Switch Flow storage to store a page bundle blob instead of HTML | ||
| Open | None | T125889 Update code (extractors, converters) that uses data-mw to deal with separate components | ||
| Open | None | T125890 Figure out how to get page bundle from Flow VE | ||
| Invalid | None | T194980 Triage | ||
| · · · |
Event Timeline
Comment Actions
I was under the impression that Flow stored HTML, and needs to convert to wikitext for editing. Is that still the case?
The stashing functionality in RB is useful to preserve wikitext when temporarily switching to HTML editing. Does this apply here?
Comment Actions
I was under the impression that stashing was the exact feature lacking in RB for Flow to adopt it.
Comment Actions
Also, we have a switcher function (HTML <-> wikitext <-> HTML) (which we should make more performant). You can switch at any time (i.e. mid-edit, etc.)
The specific reason we stopped using RESTBase's VirtualRestService is problems with data-parsoid being removed. See rEFLWe359e9c166df: Temporarily disable RESTbase support to avoid data-parsoid issues. The linked tasks from that are T115236: Flow posts being serialized from HTML -> WT without providing Parsoid data-parsoid attributes?, T112350: [Regression] In betalabs "Due to a technical error, this post could not be retrieved." for entries with triple curly brackets, T113044: Converting {{{foo}}} from wikitext to html to wikitext returns a 500 error.
Comment Actions
Okay, so it sounds like the issue is really getting data-parsoid and data-mw from the wt2html end point, and storing it along the HTML in Flow storage.
Comment Actions
I see two main options:
1) Provide pagebundle end points for wt2html and html2wt.
These are JSON blobs containing data-parsoid, html & later data-mw, and could be stored in Flow storage.
Difficulty on the RESTBase side: easy.
Difficulty on the Flow side: easy-moderate; does not solve change propagation.
2) Move Flow storage to RESTBase, as discussed in T94574.
While the storage itself is fairly straightforward, we would not be able to use much of the Parsoid logic due to its assumption that content is available on-wiki. The change propagation issues mentioned on the task are a separate issue altogether.
Difficulty on RESTBase side: Moderate-complex, especially change propagation.
Difficulty on Flow side: moderate?
Comment Actions
After meeting, we decided to still talk to Parsoid: https://etherpad.wikimedia.org/p/Flow-Restbase-2016-02-04
Comment Actions
No, this will need to be done when (not if) data-mw split happens, unless we explicitly resolve we will maintain a separate flag / endpoint for Flow to preserve the old format.
Comment Actions
Not yet .. we've delayed doing this till it gets close to when we absolutely have to do this. We'll provide sufficient advance notice before we actually do this.