This was removed in I44ee0014ac50c9c5dc66543dcd045dd5a81ce37c.
This basically partly reapplies I844db115f2563cb9ee1629c30d5f49d1ce58f5bd.
Bug: T289730
Change-Id: I14435b9f84b9a24445befbb8dc7fefce44bba078
Specifying it as such creates a 0 based index for what is a single value
property. This wasn't noticed before because I6b81ea318f52e accessed the
request object directly instead of using $params. See also
I3baa1ebb66559 for how this bug manifested in GrowthExperiments.
Bug: T289652
Change-Id: Ife8350d1cea79fc1dd6f3cb040a7801b9fe6db91
What:
Add a hook that runs before 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.
Why:
VE plugins may send additional data when saving an edit, and extensions
might want to prevent the save from taking place based on that
additional data.
See for example the AddLink plugin in Ic8225933c9, where the save is
blocked if link suggestions don't exist in the database at save time.
Bug: T283109
Change-Id: I6b81ea318f52ec47661086d85b5cc242a3fcd0e4
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
* Mismatching capitalization.
* Unused pieces of code.
* Properties that can be constants.
* Use $this->getConfig() in special pages.
Change-Id: Ia7e2c438c5ddd3c770070701e4cbdfc79fccf009
This allows using the config variable independendly from the cirrus search extension.
This way it can be used for all subtickets of T271802.
Bug: T277028
Change-Id: I1b3bdda5fa6fbfe5c531c3b51c2c8e2a28ed1faf
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
