What:
Add hook that runs after a save attempt is made in ApiVisualEditorEdit.
The hook receives the same data available in ApiVisualEditorEdit, and
implementations of the hook can modify the API response.
Also introduce templated
parameters (https://www.mediawiki.org/wiki/API:Templated_parameters) in
the API parameters; this allows plugins to pass arbitrary data along
with their request using e.g. plugins=linkrecommendation&data-linkrecommendation=foo
Add ServiceWiring files, a PHP namespace, and a HookRunner class to
support the above changes.
Why:
VE plugins may wish to send additional data when saving an edit and take
action based on that data on the server-side. See for example the
AddLink plugin in I7a052f8e which sends annotation data, and then uses
the new hook to perform a database operation.
Change-Id: I392691475fbdcec766acbd832600e82efcb5bfe8
Otherwise, the global context is used (RequestContext::getMain()),
which is undesirable when you're building a rubegoldbergian
contraption and we're already inside an internal action API request
with a fake context.
Change-Id: I66e79e641eda185f7af2561d3655c92cba762135
Applying the changes from the MediaWiki core patch for T120883
(Ife272a0eb1f3322bc8eb30ca803bd21801acba3e) to our duplicated
code implementing the same functionality.
Bug: T270453
Change-Id: I1b2de322aa0c69eb6d3b3ffadaed3fbaa3a58bca
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: I7395a8620064dcbe019b92feba17d9c9996ffbb7
Remove using of User::isIP since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T275602
Change-Id: Ia625be523706d1e24649f7aa15679491f9598b7f
The failure was:
includes/VisualEditorDataModule.php:37 PhanTypeMismatchArgument Argument 2 ($pretty) is ResourceLoader::inDebugMode() of type int but \FormatJson::encode() takes bool|false|string defined at ../../includes/json/FormatJson.php:115
includes/VisualEditorDataModule.php:41 PhanTypeMismatchArgument Argument 2 ($pretty) is ResourceLoader::inDebugMode() of type int but \FormatJson::encode() takes bool|false|string defined at ../../includes/json/FormatJson.php:115
Probably triggered by changes to MediaWiki in commit
Ieaf04e0c289646dd5d5b027b4f1f8278167b2d57.
Change-Id: Iab139c4dd69c9a16c9f4f9e2fd47ec76a9003152
If someone has edited before the switch (2016-ish), never edited since
then, and try to edit again now, it's probably no longer helpful to
show them a popup dialog about a change that happened 5 years ago.
The immediate motivation for this, though, is T273189. We discovered a
bug with the preferences that, among other issues, caused this dialog
to not be shown in some cases where it should have been, and fixing
the bug now would cause it to be shown the on the next edit attempt.
If someone has edited before the switch (2016-ish), *and* edited since
then, and try to edit again now, it's definitely not helpful at all to
show them a popup dialog about a change that happened 5 years ago.
Bug: T273189
Change-Id: I4b5a3d8dbdf1c853eb39fcfc85a9fe87a4db0f21
We have two preferences used for enabling/disabling VE:
'visualeditor-enable' and 'visualeditor-betatempdisable'.
(And 'visualeditor-autodisable', which sometimes overrides
them both, but it's not relevant here.)
The user can only set 'visualeditor-enable' when VE is Beta Feature,
and they can only set 'visualeditor-betatempdisable' when it is not.
However, when deciding if VE should be loaded, we always checked both
of the preferences. This gives incorrect results when the preference
that is not supposed to be settable actually exists, due to being set
in GlobalPreferences on another wiki where it's settable.
A similar issue could occur if VE configuration is changed from Beta
Feature to a normal preference (or the other way around), and the
preference values for the previous configuration still persist.
Bug: T271434
Change-Id: I7399b3c516f762429050a662ac85d1d392392323
Depending on the config, we would sometimes define both the
'visualeditor-enable' and the 'visualeditor-betatempdisable'
preferences, even though they contradict each other.
Bug: T273188
Change-Id: I6ac7e4580bf232a5198ad8842f814bc381131e00
* VisualEditorNewAccountEnableProportion
* VisualEditorAutoAccountEnable
Seemingly never used on Wikimedia wikis, and untested since 2016.
Bug: T273177
Change-Id: Ic132ef2091399fd223626ae307830f278e72ec01
This name is consistent with T91820.
Bug: T91820
Bug: T259685
Depends-On: I0c4ec63bb26641b237c92dbd3bc5367811ca0675
Followup-to: 3561167493
Change-Id: I4c4c5f83ad56a198d08095d629a6ba86ce9dc1a4
A couple of things make this quite a simple change:
* Most messages are generated from a single message key
* $title->getEditNotices() already returns an array
keyed in the same way, we just currently flatten it.
* The VE client already flattens the array immediately
in ArticleTarget#parseMetadata, so no change required.
* PHP preserves the order in which keys are added, not
that notice order is particularly important.
This partially undoes c824dc383a,
which changed the format from a mixed array to an indexed array.
Bug: T272188
Change-Id: I646667fe2513e371e0c8270761553253d1abe2b6
isRegistered is part of the slick UserIdentity interface, i.e.
it's the more "canonical" form. This change makes it a bit
easier to move away from using the huge (4000+ LOC) User class
everywhere, in favor of the UserIdentity interface, where
possible.
This patch is meant as a small step towards this goal. I tried
to replace some usages of User type hints already, but prefer
to go in small, incremental steps.
Change-Id: I827b83a5304b1975437d5fd5083f2877dba6f6d8
Although wikitext is (expected to be) in Unicode Normalization Form C,
the output HTML may not be, due to the presence of explicit entities in
the wikitext representing non-NFC codepoints.
Bug: T266140
Depends-On: I2e78e660ba1867744e34eda7d00ea527ec016b71
Change-Id: I0d34c9a01f1132c2616ed3392ea40d8b73e15325
The hook should work now.
I tested it manually and preloading with extensions works fine.
Preloading the default text for system messages is fixed as well.
Bug: T266404
Change-Id: Icf40112bd5fabf24452f9b807b388399c7c920f0
This patch starts using watchlist related values from ApiEditPage
results instead of updating the "watch link" based on whether the
checkbox was selected or not at the time of saving the article.
This change does not depend on T261030 and can be merged without it
but T261030 needs to be fixed or temporarily watched items will not
display the right tooltip when hovering the "watch link" or star icon.
Bug: T260434
Change-Id: I2c844223620d7d28f36a0cd8ae3dee4b0c8ae5bf
We'll update this before 1.36 is released, unless we get Parsoid
integrated "properly" before then.
Change-Id: I92d8555b1f5dc121c5f596b5cb6d59414280388f
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
