This converts user options management to a separate
service for use in DI context.
User options are accessed quite early on in installation
process and full-on options management depends on the
database. Prior we have protected from accessing the DB
by setting a hacky $wgUser with 0 id, and relying on the
implementation that it doesn't go into the database to
get the default user options. Now we can't really do that
since DBLoadBalancer is required to instantiate the options
manager. Instead, we redefine the options manager with
a DefaultOptionsManager, that only provides access to
default options and doesn't require DB access.
UserOptionsManager uses PreferencesFactory, however
injecting it will produce a cyclic dependency. The problem
is that we separate options to different kinds, which are
inferred from the PreferencesFactory declaration for those
options (e.g. if it's a radio button in the UI declaration,
the option is of multiselect kind). This is plain wrong,
the dependency should be wise versa. This will be addressed
separately, since it's requires larger refactoring. For now
the PreferencesFactory is obtained on demand. This will be
addressed in a followup.
Bug: T248527
Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
Only support passing RevisionRecord or int, remove use of
Revision::newFromId
Bug: T249021
Bug: T249561
Change-Id: Id4a8f64f239d0664865056887fe0a11c7e468d5f
Disabling tidy has been deprecated since 1.33. This cleans up the code
paths which still used untidy output.
Bug: T198214
Change-Id: I821ef3b8f59b272d983583d407b2f0794fe1e791
Added timestamp props to ApiComparePages.php with value setting only
occuring when getTimestamp() does not return null. Added Appropriate
tests to ApiComparePagesTest.php
Bug: T247686
Change-Id: I15523d11741786f3c5d572a6cff79aef787af78f
This commit also changes ApiWatch to make use of the new parameter type.
Other APIs will be updated to use it in a separate patch (T248196).
In doing this, we are for the first using logic within a TypeDef outside
the API. This seems acceptable given TypeDefs chiefly appear to serve as
a validation method, with otherwise no particular logic tied to the
concept of APIs.
wfIsInfinity() now uses ExpiryDef::INFINITY_VALS
Bug: T248508
Change-Id: If8f0df059eafb73ec9f39cc076b3a9ce2412d60a
This has long been somewhat confusing, and it's more likely a client
will wind up looping due to a cookie handling bug than that the session
loss is a transient failure on the server side.
Bug: T249526
Change-Id: I3430eb4cb1b6d85d6869c3d78709236f04da10a3
With this commit, the action=watch API accepts an 'expiry' parameter,
analagous to the expiry accepted by action=userrights, action=block,
etc.
Bug: T245078
Change-Id: If37a772253082529cb290027da87098c1e6bf98c
Also fix PHPUnit 9 warning in PNGMetadataExtractorTest about $delta.
This should fix all of the integration test warning spam.
Bug: T244095
Change-Id: I0e2a76d5df2685ae5ad1498864e0b5f9db60c0cc
The old way of providing a callable to SkinFactory::register is
still supported. Those callables expected the skin name as their
first argument. Coincidentally, so does the constructor of Skin.
Some skins might not define any constructor parameters at all,
which is acceptable to PHP, as it will just discard the argument.
The registration using $wgValidSkinNames has not been changed,
and skins that want to define services to be injected will still
need to manually register their skin to the skin factory.
CodeSearch did not indicate any extensions or skins manually
constructing a SkinFactory in tests, but for posterity, the old
way of creating a SkinFactory for testing can be replaced with
new SkinFactory( new ObjectFactory(
$this->createMock( ContainerInterface::class )
) );
Note that the constructor for SkinFactory for internal use only,
in accordance with the Stable interface policy.
You should use MediaWikiServices::getInstance()->getSkinFactory
instead.
Bug: T244466
Change-Id: I8ba9d869bddd9b6124e47697b789d752c0620b02
These are not configuration but business logic, similar to the
canonical names that are in NamespaceInfo.php, these must always
exist and cannot be altered or unset.
They were previously unconditionally assigned during all requests
in Setup.php and passed down as "site configuration".
Changes:
* Move them to MessagesEn.php where they can be cached and
processed the same way as other core-provided aliases.
Document and confirm with tests that this is a mergeable
attribute that follows the language chain.
* Remove the duplicated code in a few places that was reading
this variable + Language::getNamespaceAliases(), to instead
just call the latter and move the logic there, centralised,
and tested.
In doing so I noticed that these were applied in an
inconsistent order. Sometimes the config won, sometimes not.
There's no obvious right or wrong way here, but I've chosen
to standardise on the way that Language::getNamespaceIds() did
it, which is that config wins. This because that method seems
to be most widely used of the three (it decides how URLs and
titles are parsed), and thus the one I least want to change
the behaviour of.
* Document that $wgNamespaceAliases may only be used to
define (extra) aliases, it is and never was a way to access
the complete list of aliases.
Bug: T189966
Change-Id: Ibb14181aba8c1b509264ed40523e9ab4000fd71a
This adds a baserevid parameter for detecting edit conflicts, as an
alternative to the less precise basetimestamp parameter. This is
introduced for parity with and use by the new REST api.
Bug: T230843
Bug: T34037
Change-Id: Id7565018f66860b5c2ba688777508db1b88700ae
* Avoid partial assertions using array subsets.
Instead, explicitly ignore the keys we want to ignore,
and then assert the array in full.
This way, newly added properties are explicitly detected
by the test, and it also automatically means that no bad
properties can be added. For example, properties like 'new',
'minor' and 'bot' express their meaning by sheer existence
and must never be tolerated to exist.
This was motivated by the many assertArraySubset() deprecation
warnings that were making the CI build output very noisy,
and thus it was difficult to quickly find real problems.
- For testNamespaceParam() I added rcprop=title, as it was
only asserting those keys. The alternative was to repeat
all the assertions for the overall output, which other tests
already did.
* Avoid using User::getName() or Title::getPrefixedText()
in the asserted expected value. Be explicit. This also
makes the test run considerably faster.
* Use 'tablesUsed' the way we normally do in MediaWiki unit
tests, by declaring the class member. (We never use
TestCase constructors.)
* Remove use of harcoded DB truncation for 'recentchanges'.
MediaWikiIntegrationTestCase does this already, which is what
`@group Database` and `tablesUsed` are for.
* Remove use of mutable TestUser, the user is never mutated.
This allows the internal registry to re-use the same instance.
* Remove use of assertArrayHasKey() where it only checked
something the test would immediately assert on the next line.
We already have PHPUnit configured in general to assert and
fail directly upon any undefined key access.
* Use sample names like Foo, Bar and Quux which are easier
to remember and distinguish than overly long and similar
titles with some word or number added at the end of them.
Change-Id: I8133e1199e3b1d053be7053795172891ad2bf48b
This should be the exact same. Its more a style change than anything.
So why do it then?
* I believe this is much less confusing than code mentioning a weird
"standard class". Barely anybody knows what this is, and what the
difference between "object" and "stdClass" is.
* The code is shorter.
* It's even faster. In my micro benchmark it's twice as fast.
Change-Id: I7ee0e8ae6d9264a89b6cd1dd861f0466ae620ccc
In VisualEditor, when the user is saving their edit, we want to ensure
that they understand how their edit will be attributed. Therefore, if
the user gets logged out or logs in in another tab, we want to display
a message about it before saving.
We've been detecting this situation by manually managing tokens and
handling the 'badtoken' error, but our code would be much simpler and
it would be possible to share it with other extensions if we could
instead rely on automatic retrying in mw.Api#postWithToken and use
'assertuser' and 'assert' parameters. 'assert=anon' is the only
feature we're missing.
Bug: T245327
Change-Id: I485f99e1f5f493262b0c9af22370da01adf1e09c
Accidentally broken by I991809acf.
Also added a test that should hopefully prevent this from accidentally
being broken again.
Bug: T245149
Change-Id: Ia7985397db50efe8af81f643f2a0a89d0ece179e
ApiStructureTest has a lot of logic for validating Action API settings
arrays during CI. Some of that logic should be part of ParamValidator
instead.
Bug: T242887
Change-Id: I3c3d23e38456de19179ae3e5855397316b6e4c40
Depends-On: I04de72d731b94468d8a12b35df67f359382b3742
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
This log message was added at the request of Wikimedia's Security team
in 2016, but as far as I can tell was never enabled on Wikimedia sites.
Rather than adding more logic to avoid logspam when browsers include an
Origin header for same-orign requests, let's just get rid of it
entirely.
Bug: T243908
Change-Id: I799b17a5f4891f9e739d6b62551a5736b8a6664e
This patch tries to make assertions in tests more readable by using more
self-documenting assertions as provided by modern PHPUnit versions. Among
a few others, these two main changes are done:
* I found a lot of assertions with the expected value being the *second*
parameter. I did not changed all of them. Only some that can be replaced
with assertNull() and such.
* I try to replace all `assertTrue( is_…() )` with dedicated assertions.
Change-Id: I1fc72188fbd0edacf13886e7f9a9eacbd85f13c2
Remove the deprecated Preprocessor_DOM class, which was hard-deprecated
in 1.34. This begins to simplify parser configuration and reduce redundant
code paths, but I've left two things for cleanup in a future patch:
1. The `preprocessorClass` configuration option to the parser, exposed
in `$wgParserConf`, ServiceWiring, ParserFactory, etc. There is no reason
for this to be exposed as configurable, but I've left this clean up to a
future patch.
2. The `$wgMaxGeneratedPPNodeCount` configuration, exposed also in
ParserOptions. Only Preprocessor_DOM calculated this count, and since
we are only using Preprocessor_Hash now, this configuration has no effect.
But since this value was exposed in ParserOptions and elsewhere, I've
deprecated where needed but left this clean up to a future patch.
Bug: T204945
Change-Id: I727f003f9a42d0c92bcbcce8a8289d5af6cd1298
