Parsoid always enables `<ref>` processing, but our Cite extension
implementation tries to fetch $wgCiteResponsiveReferences, which won't
be set if the Cite extension is not installed.
Change-Id: Idde8af07e5bf40983b2ec878ebf70aabb522a800
(cherry picked from commit 0ca4ae6908b626d34f8445d9048342378d0e3c23)
Currently we always register VE as a Beta Feature, and then
expect users to use $wgHiddenPrefs to hide it, hackily.
Also, set this new preference to false so that 3rd party
wikis don't show the BF by default.
Bug: T254349
Change-Id: I92fe3d44bb4d762ca7b1bc693b7d2e74367c84ec
getDefaultMessageText() returns false when the message doesn't exist.
It was incorrectly treated as a string by this code.
Follow-up to 3ec5e04a37.
Change-Id: Ib94a30697bd20133e46cbd31c14caf5f0c4169dd
Set the 'forwardCookies' flag if the wiki is private (not everyone is
allowed 'read' access).
Bug: T260201
Change-Id: I0b958e8b75c04e4a27f50f91276be221a5b1404d
The output is assumed to be the same as you would get if you
fetched the page again, so this output-modifying hook needs to run.
Bug: T258980
Change-Id: I015ac183a0c25dafb9b95c577edd4ef59c112d43
Previously, when the editsection link of the section edit links had
a class defined (either by the skin or through an extension), the
mw-editsection-visualeditor class would not be added, as the + operator
on arrays does not merge existing entries.
The side effect of the mw-editsection-visualeditor class missing is
that the initialization code in ve.init.mw.DesktopArticleTarget.init
would add an additional link to the section edit links, resulting in
three links shown when VisualEditorUseSingleEditTab is false.
Change-Id: I4b25c63884fa367fb0e44c61323a19a71fb6b9d8
* 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 Special:ApiSandbox to display multi-line text boxes for
them, which makes testing the API easier.
Change-Id: I10541a8e9033d81740033da80d842f58d1d3e0de
Calling the linter is very slow as the result is not
cached. Extensions needing this (DiscussionTools) should
just call the Linter extension API directly.
Bug: T253799
Change-Id: I994b52ca70c29a32900741a36087f10144396720
The current default for Message::__toString() is to parse, so this
keeps that behaviour unchanged.
Change-Id: I528a60c1d9c0f8c1596a15e06a764200a2b2565f
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
We go through all this trouble to pass the config to the API modules,
and then we don't use it at all (we removed the uses recently in
ce094c72d and d85d30f9b).
If we end up needing the config there again, we can just get it by using
MediaWikiServices::getInstance()->getConfigFactory()->makeConfig( 'visualeditor' )
anywhere we want, like we do all over the place in VisualEditorHooks.
Change-Id: I9d254a9946f0d24783baf68c409b10291a8fd1b3
