This was removed in I44ee0014ac50c9c5dc66543dcd045dd5a81ce37c.
This basically partly reapplies I844db115f2563cb9ee1629c30d5f49d1ce58f5bd.
Bug: T289730
Change-Id: I14435b9f84b9a24445befbb8dc7fefce44bba078
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
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
Remove using of User::isIP since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T275602
Change-Id: Ia625be523706d1e24649f7aa15679491f9598b7f
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
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
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
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
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
