1. into class Parser
2. into class LinkHoderArray
3. into class DefaultPreferencesFactory
Add more tests for DefaultPreferencesFactory:
1. testVariantsSupport verifies that converter with variants is used correctly.
2. Test testUserGroupMemberships verifies that membership is used correctly
Bug: T243320, T243321, T243317
Change-Id: I1e5c37e18332d0d32391c74c06e3d84862e48df8
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
Classes that use ServiceOptions need to declare a list of keys that they
use, typically in self::$constructorOptions. If keys are missing from
that list that are supposed to be present, an exception will be thrown
when someone tries to access them. If keys are present on the list that
are never used, no error is flagged. This means if a dependency on a
given configuration option is removed and nobody updates the list, the
service will keep thinking it depends on that option when it doesn't.
This is messy at best, like an unused variable.
A new and easy-to-use TestAllServiceOptionsUsed trait fixes that
problem. It will log all the ServiceOptions accesses while the test
class runs and raise an error if there are any keys that were never
accessed.
In retrospect, it was probably not worth the time to write this, but
it's a sunk cost now.
Change-Id: Idcaf9a0e2f687069869e6f8057908ffee7dd5f11
We don't want to depend on the entire site configuration when we only
need a few specific settings.
This change additionally means that these services no longer see a live
version of the settings, but rather a copy. This means in tests you
really do have to call overrideMwServices() if you want services to pick
up your config changes.
ResourceLoader and SearchEngineConfig will need more work to port,
because they expose their member Config in a getter, and the getter is
actually used.
Parser and NamespaceInfo are also relatively complicated, so I split
them into separate patches.
Tested with 100% code coverage. \o/
Depends-On: If6534b18f6657ec1aba7327463f2661037f995b3
Change-Id: I1a3f358e8659b49de4502dc8216ecb6f35f4e02a
Due to a delay in the rollout of this feature, this part of the code has
to be temporarily removed again to prevent an unused setting from
popping up in the user settings.
Bug: T218556
Change-Id: I0f4e822fc25fddc2bc3c0b55b0792799a1e4c4ba
This should not be visible on production until the feature of rollback confirmation prompt has been deployed.
Bug: T199537
Change-Id: I8a49143f662b8412f74c06627c2285ab3c3b8cff
The GetPreferences hook lets extensions register additional user
preferences. They show up on the form and that breaks the hardcoded
assertion that exactly 5 preferences are available.
Disable the hook in case the test is run with extensions loaded in (ex:
BetaFeatures).
Change-Id: I78b11e989110407cd721e8a3fbbe81d28ca4be5b
I wasn't sure how to convert the rest of the occurrences in core (there
are a significant number).
Bug: T200881
Change-Id: I114bba946cd3ea8a293121e275588c3c4d174f94
This normalizes handling of transformations on the boundaries between
preferences and generic form controls and removes the special case
where email-blacklist is passed around as an array internally, leaking
into the API.
As a result of this normalization, meta=userinfo no longer returns an
array of users, using the internal representation like action=options.
Bug: T198935
Change-Id: Iff63da0d215585cfcf083e7f7ec8ed45d5b77301
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
This deprecates the Preferences class and replaces it with
a PreferencesFactory service. Basically, all code from Preferences
is moved into DefaultPreferencesFactory. All Prefereces methods
are now either shims calling DefaultPreferencesFactory or just
throw exceptions.
Bug: T178449
Change-Id: Id0b2db0c2de0890f6e1609a9a0dca207c4600f99
