I've verified that no other extension uses this code apart from VE
and locally tested that with this patch, VE still works and nothing
explodes.
There parent patch takes care of making sure the mode is no longer
injected and we now have just etags with no hacked in modes because
we now use direct mode always.
Bug: T341612
Change-Id: Ib1756bf60104467a3a34be9bbb06d8f63537e550
This follows the event of VE no longer using RESTBase anything. All
actions related to stashing and Parsoid and now handled in MW core.
Bug: T339227
Change-Id: I50b20ed5abb721a6ac8987cac37a6f395a4816dc
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
Helper classes have been moved to a dedicated namespace
of their own, this patch references the new namespace.
Depends-On: Ieeb7a0a706a4cb38778f312bfbfe781a1f366d14
Change-Id: I5a2792a3536f6d953905561410f0e4966254ccbe
This isolates this extension from knowledge about the constructor
signature of the helper classes. Constructore signatures are not stable
interfaces.
Needed-By: Ie430acd0753880d88370bb9f22bb40a0f9ded917
Depends-On: I10af85b2da96568cfffd03867d1cb299645fb371
Change-Id: If1914dbfbefc3501b4d4cef4beb1fae307c36455
* Rename imported classes in VE that will be renamed in core
* Re-enable tests that would fail when the core patch is merged
Depends-On: I506f3303ae8f9e4db17299211366bef1558f142c
Change-Id: I59ebeb24fa0de5f10d1501cc0830c7e4805e1003
When receiving HTML from a VE session, process it with the same kind of
ParsoidClient that was originally used to generate the HTML. If we were
to use a different implementation, the ETag wouldn't match, so we would
fail to find the stashed data-parsoid map, and the edit would fail.
Bug: T320704
Change-Id: I3b73431fccacecb4ad88b82f8f5675b1042e03ce
AutoConfig was used to set VE to call internal REST API endpoints exposed by the parsoid extension.
With DirectParsoidClient available, this is no longer needed.
NOTE: this causes all wikis that do not have a RESTbase backend
configured to start using DirectParsoidClient. This is true in
particular for officewiki and labswiki.
Bug: T320704
Change-Id: Ia4c6184dd75a653c3202ea160b6605335f36f6eb
If VE is configured to call parsoid directly in PHP, the client
should not try to fetch HTML from restbase. Doing so will
lead to inconsistencies, and may cause edits to fail.
Bug: T320704
Bug: T320703
Change-Id: I98bfdd305dcd188d91db6a8fe5885156cdeca7db
* DirectParsoidClient makes use of parsoid directly for performing
transformations on both wikitext and/or HTML contents.
* Also, it's used to fetch HTML from parsoid's parser cache. Before,
this operation was done via RESTBase but now it's being fetched in
core's parsoid parser cache.
* This patch also enables VE clients to transform HTML to
Wikitext when switching from HTML to source mode on. It
makes use of the HtmlInputTransformHelper to perform this
transformation.
* Now, VE client can make use of core code for switching
between HTML to source mode and back without RESTBase.
Change-Id: I5c7cfcc4086d8da7905897194d8601aa07418b59
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
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
