Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Add a "global" parameter to ApiOptions which allows it to update or
override global preferences.
Bug: T323076
Depends-On: I686c0091768ed330683fff89201fae4f93b8a1c4
Change-Id: Ieb2d0c0d0da5c51b2a47ed8a967a47b4e7ad4577
This gives us the flexibility to add features to core without
affecting GlobalPreferences.
Split getUserForUpdates() into asserting and non-asserting variants
since most things are using it without checking for a null return.
Bug: T323076
Change-Id: I53e5c409a650397fde03a8578b0182f0b97927a9
Fix the dependency loop between PreferencesFactory and
UserOptionsManager by moving the concept of "reset kinds" or "option
kinds" to PreferencesFactory.
Note that this is a half-baked feature from 2013 (I5f9ba5b0dfe7c2ea)
that is not really used for anything. Apparently only the "all" and
"unused" kinds are used.
The strong dependencies on PreferencesFactory internal details show that
this feature belongs in PreferencesFactory. But UserOptionsManager can
reset "all" preferences without help from PreferencesFactory, so add a
helper for that.
The rationale for putting it in UserOptionsManager was that eventually
all preference definition information should move to UserOptionsManager
(T250822). I don't agree with that. UserOptionsManager is the key/value
store which backs PreferencesFactory. I need to refactor it further for
T323076 and it will help to have these concepts be separate.
Hard-deprecate UserOptionsManager methods resetOptions, listOptionKinds
and getOptionKinds. Add convenience methods to replace calls to
resetOptions().
I couldn't understand the logic in resetOptions(). Why was it copying
old values instead of just omitting them? Why was it assigning null but
only for "all"? setOption() had a documented method for resetting an
option to the default, so I just used that.
Bug: T323076
Depends-On: I1ed0a1a9f6492fb50254104fa4bc9f2130218323
Change-Id: I900fd4a48c96d91491eae54824e7bf02a004843d
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
I was thinking add validations to HTMLApiField and other field types
if any, but then I found one field type that hard to implement proper
length validation, which is used for the `email-blacklist` preference.
The API will not save options that exceed the limit after this patch,
as if the validation is done by respective html fields.
Bug: T326696
Change-Id: Ib6b04db33bc6a806a49a16a1797c191faf5fb59d
The value can apparently be null. String functions don't accept null
any more in PHP 8.1.
Bug: T289926
Change-Id: I32d558b8c710c55d08cb3496d70a489004407be0
Previously attempted in 07b4daf85d,
reverted in 8763d8e911.
Message parsing used to be the biggest part of loads during
DefaultPreferencesFactory::loadPreferenceValues(), since it need to
load form fields to validate existing user preferences.
Message names in form descriptor can be unset as much as possible,
but special cases should be carefully handled.
The attempt of loading value for info fields is skipped to avoid
issues described in T302643.
Bug: T58633
Bug: T302643
Change-Id: I05dcfd60d4103b447dea71851b8e4db9a5d0e1e6
This reverts commit 07b4daf85d.
Due to the new method being used in both the API, and in the
loadPreferenceValues method (which is used by the main pref UI), this
change is not easy to reason about and is much wider in impact than
I had thought. More research and understanding is needed.
Bug: T302643
Change-Id: Ic420bc16ac5de8ce90343926e9c73815f3ff7479
Message parsing used to be the biggest part of loads during
DefaultPreferencesFactory::loadPreferenceValues(), since it need to
load form fields to validate existing user preferences.
Message names in form descriptor can be unset as much as possible,
but special cases should be carefully handled.
Bug: T58633
Change-Id: I1b5c2331e6d5a63f296b4147a91aecb39abf3530
There will be some checks for the existence of fields referred by cond-state, fields in the same descriptor should be loaded in one go.
Change-Id: Ie3c4c1b35fc33d738dea8ca168ab8f07063f7a59
This method was recently added and was to result in the deprecation
of a few places where User objects were being passed to the factory.
This has now been reconsidered and this patch reverts to the
previous behaviour. It is largely a revert of Ie1bed9e9537cabc836992ccfa7fb127885ea3e11
Bug: T238466
Depends-On: Idc9f33fd5ab55bde88cc306ca63adead286380a8
Change-Id: I3653559704ccfd9bca0946f5a865be93bdf5ceb6
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Add a new setUser() method to PreferencesFactory so that a User
object doesn't have to be passed around so much. This is how
GlobalPreferencesFactory has done it, and so after this change
that code can be removed from GlobalPreferences.
Bug: T238466
Change-Id: Ie1bed9e9537cabc836992ccfa7fb127885ea3e11
For preferences like 'skin' that have a limited number of values, null
is not a valid value, thus attempts to reset them fail with
"Validation error for \"skin\": This value is required."
Bug: T65080
Change-Id: I86554a6d30c8ab970740d8682fb2261476de0677
Because GlobalPreferences needs an API and that API needs to behave like
this one, it makes sense to make them share code. Move some functionality
into separate functions to make this possible.
Bug: T62856
Change-Id: Ic64934e7f7226a309d71c22626119ea233e2caeb
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
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
PHP 7.2 broke existing functionality in making count( null ) raise a
warning. So add tests for null all over the place, or change tests where
we know the value is null or an array (but not false, empty-string, or
0) to just cast to boolean.
Bug: T182004
Change-Id: Idfe23a07daa9f60eee72f2daf04304be87057a29
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
* This does the same thing ApiOptions does to avoid these errors.
A new getInstanceForUpdate() method is now in the User class to
simplify this pattern.
* Avoid overriding $user in ApiOptions for code readability.
* Fixed IDEA errors around Preferences::getFormObject() return type.
Bug: T95839
Change-Id: If2385b7486c043bd70d7031ff35e37dfb079a4d2
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
