Write a Parsoid backend for VirtualRestService, and replace VisualEditor's and Flow's hacks with that. Incorporate the cookie forwarding hacks from VE as well.
See https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service and https://github.com/wikimedia/mediawiki/tree/master/includes/libs/virtualrest
This would also be a good opportunity to clean up the way the Parsoid URL (and whether it's available) is configured in mediawiki-config
See also: T74988
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use ParsoidVirtualRESTService | mediawiki/extensions/VisualEditor | master | +36 -54 | |
| Make a VirtualRESTService class for Parsoid | mediawiki/core | master | +130 -1 |
It might be nice to model the internal interface somewhat similar to the way the RESTBase interface will look like:
The local bit here could be shorthand for the local domain / wiki. Page titles are percent-encoded, so slashes are no problem.
The cookie authentication business should be doable in the virtualrest backend handler for the parsoid end point, so that users don't need to deal with it. The backend is also the only place that needs to deal with actual host names etc from the config.
I ran into issues with the way I was trying to use VirtualRESTService. My onResponses function was not getting called. Aaron said "seems like there should be a $execReqsByService for the second loop to over so onReponse is called for non-replaced requests too" (referring to code in VirtualRESTServiceClient::runMulti)
Change 181011 had a related patch set uploaded (by Alex Monk):
Make a VirtualRESTService class for Parsoid, and use it
We fixed the issue I was running into in https://gerrit.wikimedia.org/r/181121, @aaron made https://gerrit.wikimedia.org/r/181119 to fix the issue we found last night.
Change 181706 had a related patch set uploaded (by Alex Monk):
Make a VirtualRESTService class for Parsoid