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
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
