Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ic4d4dd61de5ab896fb6173eb579c81f164a1e4a3
This patch introduces a namespace declaration for the
MediaWiki\Json to FormatJson and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5e1311e4eb7a878a7db319b725ae262f40671c32
This patch introduces a new namespace declaration,
MediaWiki\Xml and adds Xml and XmlSelect to it
and establishes class aliases marked as deprecated
since version 1.43.
Bug: T353458
Change-Id: I45cccd540b6e15f267d3ab588a064fbeb719d921
which takes two timestamps in order to calculate a more accurate text representation of the duration between the timestamps
Bug: T219397
Co-authored-by: addshore <addshorewiki@gmail.com>
Co-authored-by: Silvan <silvan.heintze@wikimedia.de>
Change-Id: I290f8da815f9571dae75fddde2da2010cc9a7fec
I think there is further room for improvement
here, such as a method that takes 2 points in time
and gives you a more precise summarization of the duration
in terms of actual dates.
(And we will do this in a followup)
To avoid changing behaviour where this method is called
the default interval of `month` is not specified, so
existing calls return as they did before.
For callers that want `month` granularity, they can
specify month.
Bug: T219397
Change-Id: I5a07e14629fd9f67b1f17df3db75b68f98295dfb
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I24ca752d5dac7c948fdbcabf721f6f0aef8a466f
MediaWiki only supports 14 character timestamps, and most date input
fields accordingly limit the accepted input range to fit within that
constraint, so the largest acceptable date is 9999-12-31 23:59:59.
However, if an user's own timezone preference is set to a timezone with
a higher offset than the server timezone, such dates may overflow into
the year 10000 and cause an error ("The timestamp XYZ should have 14
characters"). This very commonly happens when an admin decides to block
an user until 9999-12-31 instead of using the infinite expiry for some
reason, effectively breaking the block log for every user with a
timezone offset higher than the server offset.
Making MediaWiki support dates beyond the year 10000 would be a larger
undertaking, so for now, limit the impact of this problem by ensuring
that userAdjust() does not generate a local date that sprintfDate()
would not be able to handle.
Bug: T32148
Bug: T277809
Change-Id: I17ceee6c80dcc1559c6d66f1956ba1f0a4b519a3
Update cases where one of the IConnectionProvider methods is called
immediately.
This doesn't really change anything, but I hope it helps promote
getConnectionProvider() as the common way to do this.
Follow-up to 8604c384f6.
Change-Id: Id0e7d02bab0c570343c2b1f03c70b44ee39db112
Follows-up I8518e0488 (9c02258a04).
Instead of documenting how to compute the number to manually verify
it, use the expression directly. This should make it significantly
easier to understand, verify, and modify.
Noteworthy:
* Language.php, I kept 31_556_952 as-is because the
calculation would otherwise involve a float. It also has the benefit
of allowing the long durations to build upon that as a given number.
* SqlBlobStore.php, remove this irrelevant default value as it is
unreachable. The only call to new SqlBlobStore is BlobStoreFactory,
which always calls setCacheExpiry. For back-compat and to keep
tests as-is, move to re-used constant between class and config.
Change-Id: I86b034883bd7efdf93b8365b43178af826f1c703
This makes the code easier to read to avoid jumps and improves
encapsulation by not allowing the rest of the class having access to the
logic. Of course, if needed then some code can be refactored out again
but for now let's not do YAGNI.
Change-Id: Ic37524e386fc04fd67e33768417ff8425f85b0ca
Special pages belong to the interaction layer, lower level code should
not access them. That is especially true for something used everywhere
in the code base, like Language.
Change-Id: I46a2a7d60ff73dac3ce72e657c6232b6168a98e8
For readability. Allowed since PHP 7.4.
I searched for integer literals of 6 or more digits, and also changed
some nearby smaller numbers for consistency.
Bug: T353205
Change-Id: I8518e04889ba8fd52e0f9476a74f8e3e1454b678
In php8.2 the use of multiple signs makes further signs ignored
strtotime( "+-120 minutes" ) is processed as strtotime( "+120 minutes" )
Remove the + from the call as positive numbers are added also without +
Bug: T351848
Change-Id: I469c0e1b60eb17f051fc6a826265a3fd978f8de8
This implements the additional Bcp47Code interface method required by
wikimedia/bcp-47-code 2.0.0.
Bug: T331887
Change-Id: If3abc8a55eda8879ca904b25e9e3e5d40c1b0bab
It's not (only) an array of strings (aliases). It also contains the
case-sensitive flag as an integer (no, not as a bool).
Change-Id: Iba3cc6fd14360c0d972beb809940139c5b9e63bb
empty() only makes sense when the expression it checks is possibly
undefined, otherwise it's equivalent to a truthiness check with the
additional downside of suppressing errors when it's not wanted.
Replace it with simple truthiness checks, using strict comparison when
that seems to help with polymorphic variables.
These were caught by a bespoke phan plugin.
Change-Id: I52999e5286a0d9ad70b0da40b41b9f998ecb990e
The parameter $noSeparators is hard deprecated since 1c9bbfc14e
included in MediaWiki 1.36.
Also remove comment to commafy removed in 7f4e9bfa39.
Change-Id: Ice69e3593eddbe771a626533f5db1a75ae5c366f
LogFormatter is another place that uses the global state a lot, with
Title, Linker, etc. Some of its dependencies were accessing the
database, but most LogFormatter methods are not in the database group.
This patch tries to work around the DB dependencies by providing
(complex) mocks that do not access the DB. There's a lot of mocking
involved, but that's just because of the current state of LogFormatter,
and hopefully it'll get better some day.
Rights- and ProtectLogFormatter also need a mock DB connection because
they use the database to format expiry.
Bug: T155147
Change-Id: I4fa9ee4fb246e08cb2b4577454029b5af3276b79
All Messages*.php variables are supposed to be documented in
MessagesEn.php.
I don't see the point in having Language::minimumGroupingDigits() return
null, and then expecting every caller to cast null to zero.
The default for English is properly 1, not 0, since 3-digit numbers do
not need grouping. We don't write 999 as ",999". Setting it to 1
instead of null should improve the performance of the JS commafyNumber()
by avoiding the unnecessary loop body. Change the QUnit test data to
confirm that this works.
In the PHP implementation, adjust the comparison to avoid the
preg_match() when minimumGroupingDigits is 1.
Change-Id: I6679d69e7094502303389039550e17a47189e2dc
The `mb_str_split` function is better than `str_split` since we
don't need to hard-code the length of multi-bytes char.
The `strtr` function only travels the string one time, which is
very suitable for replacing a mapping of chars.
Change-Id: I25186250624f7c1403567957faf7d5ab414e1884
The $list parameter to the various *list() methods is not escaped by
these methods, so any taintedness in the argument is preserved by the
method and kept in the return value. taint-check has troubles figuring
this out on its own due to T274780, so annotate the parameters.
Note: once this is merged, taint-check could start failing on some
repos. Any errors would have a decent chance of being true positives.
Bug: T253879
Change-Id: I6cf56aca9760370cbeae19879e6b170b1cbd273f
