Don't use RawMessage, the API error formatter doesn't know what to do
with it. Instead call dieWithException(). These exceptions probably
shouldn't bubble up here, but we can worry about that later.
Bug: T344173
Change-Id: I3d1645a3580feeed6fe1431a7bfcdc584f681061
After catching the REST exception, just throw an API exception.
Remove the step inbetween where we built a response array.
Bonus:
* Remove tests that only tested this array building.
* Remove the unused 'code' from successful responses, and update
documentation of return value shapes.
* Remove impossible check for `$ex instanceof LocalizedException`.
After moving the code into one place, it's obvious that it can't
happen, since LocalizedException doesn't inherit from HttpException.
Bug: T341613
Change-Id: I31370efeed9d5283b53eafca102b2f1efc811d27
After we removed other clients, the $response array can only be
generated by DirectParsoidClient::fakeRESTbaseHTMLResponse(),
which never includes a fake 'x-cache' header in the response.
Bug: T341613
Change-Id: I90bcb1e26e4164f8f4a34da3abcb01ac0769e21a
Having per-wiki statistics is neat but expensive. Now that VE has been
switched to not use RESTbase on all wikis, Go back to collecting
all stats under a single key. The relevant dashboards have already been
adjusted accordingly.
Change-Id: I9666bfa3fed547f3f619a9e0c9c24b9240edc359
More could be done, but these are the ones that annoy me the most,
and I'm not willing to do more changes right now.
Change-Id: Ia02af09d631fea191e57da75420f0d2d1ed46c19
We want to be able to measure how backend performance changes
when we switch from RESTbase to calling Parsoid directly.
We expect to see a performance boost, in particular for
html/to/wikitext, since we avoid the network overhead.
Since we will make the switch by wiki, we need to be able to compare
the metric before vs. after for a single wiki. So, this adds the
wiki ID as a prefix to all existing metrics. Once fully rolled out,
we should get rid of the wiki prefix.
We will need to update the dashboard found at this url:
https://grafana.wikimedia.org/d/000000249/edit-stash?orgId=1
Change-Id: Iac9070b27f4b0d25b0e31c9fad38abc08c433a28
Part of my secret plan to delete ApiParsoidTrait.
* Inject RevisionLookup into ApiVisualEditor
* Use RevisionLookup::getRevisionById instead of ApiParsoidTrait::getValidRevision
* Use RevisionLookup::getRevisionByTitle instead of ApiParsoidTrait::getLatestRevision
* Use standard MediaWiki error messages
* Delete unused ApiParsoidTrait::getValidRevision
* Delete unused ApiParsoidTrait::getLatestRevision
Depends-On: I7244ee4916fb011fad5faa1d9f837e83f6ac2dc1
Change-Id: I8089c0c516d9dba52e931a0a80740c0361216dbd
All code that used to live in ParsoidHelper has been moved to
VisualEditorParsoidClientFactory and VRSParsoidClient.
ParsoidHelper is no longer needed.
Change-Id: I21c4a8cd86f8d085e75a601ed6d2509dedd75d42
Getting the correct client is now done via the VisualEditorParsoidClientFactory
so this is no longer needed. Follow-up of: I787c0afb227308aab56770d.
Depends-On: I4b9e7362a1bf1b4f224c8c652d40851a18c19824
Change-Id: I175aef2326a0d784fb8211542a3fe90cbf6c6d08
This patch introduces a factory service for creating VE Parsoid
clients.
NOTE: This patch also injects a GlobalIdGenerator to the client
and avoids usage of deprecated UIDGenerator class.
Change-Id: I787c0afb227308aab56770d14d62e08eb0084a6c
ApiParsoidTrait depends on some ApiBase methods, which is inconvenient
when one wishes to access Parsoid HTML outside of the action API. Move
the bulk of the code into a new class ParsoidHelper, which doesn't.
Replace the uses of methods:
* dieWithError: throw a different kind of exception where it makes
sense, or change the method to return a StatusValue instead of
throwing where it doesn't
* getPageLanguage: use Title::getPageLanguage() or pass as parameter
* getConfig: pass to constructor
* getLogger: pass to constructor
* getRequest: pass the only required part to constructor,
leave some other API-specific code using it in ApiParsoidTrait
Bug: T314565
Change-Id: I90656cc74bb1cb1f2f3c82ad51cfb164cb8a4a4b
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
This ensures proper redacting, and consistent discovery and formatting
for Logstash queries.
Bug: T233342
Change-Id: I9a2a96793a5b7669648d222a0d472c15c09b84d3
* Mismatching capitalization.
* Unused pieces of code.
* Properties that can be constants.
* Use $this->getConfig() in special pages.
Change-Id: Ia7e2c438c5ddd3c770070701e4cbdfc79fccf009
This name is consistent with T91820.
Bug: T91820
Bug: T259685
Depends-On: I0c4ec63bb26641b237c92dbd3bc5367811ca0675
Followup-to: 3561167493
Change-Id: I4c4c5f83ad56a198d08095d629a6ba86ce9dc1a4
Set the 'forwardCookies' flag if the wiki is private (not everyone is
allowed 'read' access).
Bug: T260201
Change-Id: I0b958e8b75c04e4a27f50f91276be221a5b1404d
* Remove postHTML/postData separation, not very useful.
* Pass $oldid instead of full params object.
* Return full repsonse like other methods, instead of just body.
Change-Id: I0fe301475adeb0fd5952809c3f74f0cb19f89cfe
This copies the Parsoid extension code into includes/VEParsoid
to allow a "one extension, zero-configuration" install of
VisualEditor for MW's LTS release. The Parsoid code has been
re-namespaced (`VEParsoid` instead of `MWParsoid`) to avoid
autoloader conflicts if you actually install Parsoid as an
extension (as we do in Wikimedia production). Similarly, we
arrange that the ServiceWiring and RestRoutes configurations
are skipped unless running in zeroconf mode, to avoid
conflicts with the Parsoid extension.
This import matches Parsoid commit b30f223.
Bug: T248343
Change-Id: Ic63ce40f59c4be8f4fdc5f9ac17798353fc86866
This allows it to respect the proposed limit on HTTP request timeout.
Bug: T245170
Depends-On: I8252f6c854b98059f4916d5460ea71cf4b580149
Change-Id: I1c3d96720709253ad15bb8528cdd132571de2e4e
Goals:
* Allow other extensions to reuse these methods (maybe upstream them
to MediaWiki core later)
* Allow ApiVisualEditorEdit to extend ApiEditPage. We'll be able to
reuse its definitions for API parameters instead of duplicating
them, and we won't have to pass around unrecognized parameters.
Bug: T252573
Change-Id: If5c8d95560cbb078ae4980f4a912cbaeafe53d3e
