session.use_trans_sid is a PHP antifeature that tells PHP to add
session IDs to all local URLs by modifying the HTML it's told to
output. We have set it to false just in case, but now that's
triggering deprecation warnings.
Bug: T380755
Change-Id: Iace0dcdb23eedb432cc1c032bbb3ce31d34071be
(cherry picked from commit 3b948a3da4be2a20573db01d611d601f2f90f2e5)
This has been failing integration tests since 20250101 because all 2024
become 2025.
Bug: T382848
Change-Id: I5aa71bb7644cfb42140d8eaba9f408e762b2937c
(cherry picked from commit ba68c4494298bcaba7c8d1e1acaecff002cb3aac)
json_decode now emits a deprecation warning when called with null.
Before it would just return null anyway in these cases so I just
introduced a way around that avoids calling the mehod in the frist
place.
Bug: T382590
Change-Id: I47b7aca331a405bb3d2865cc280ef3ced537f84b
(cherry picked from commit b2fad75337256aaabd6e892bdd4bea8f86b47d5c)
Why:
- The test ClockTest::testShouldReturnCurrentTime is flaky.
- Ie48d9400cf3bb99467a16b9ea0cce6172e2e2568 recently augmented
the ConvertibleTimestamp library to allow faking hrtime(), which will
be a better solution for this class and test than the current
assertion.
What:
- Skip the test until core is updated to the latest version of
ConvertibleTimestamp.
Bug: T379562
Change-Id: Iae502ed0344f45f89da575f1c5d1e0fb9c1e4dfa
(cherry picked from commit a930114b4240ec311a56eef7f814f378cc3d5f88)
There's no point in retrying a job when you get "Revision x is not current".
It just causes log spam. Makes people think there's a problem when there isn't as it
logs in the error channel.
Bug: T379656
Change-Id: Iaa5bd006bf3f26277e81ad5bea1387ef4b925f68
Why:
* Special:PasswordReset allows users to send an email containing
a temporary password to the email address attached to an account.
* Temporary accounts do not have passwords and cannot have an email
address set (as they cannot access Special:Preferences).
* Therefore, Special:PasswordReset does not provide holders of
temporary accounts a way to get access back into the temporary
account if they loose access.
* However, the form currently accepts temporary account usernames
and we should update the functionality to reject such usernames.
What:
* Update SpecialPasswordReset to reject temporary account usernames.
* Expand tests for SpecialPasswordReset to check this fix has worked.
Bug: T380085
Change-Id: I004453d4d16cd2a0448ac3922e4d13c24a158c8d
(cherry picked from commit e27be818690820c0df227cb06206da499eb94d38)
When parsing wikitext like `{{func:a|b|c}}`, jqueryMsg accepted
multiple expressions in the parameters following '|' (which are
handled by templateParam()), but not in the first parameter
following ':' (which is handled by templateWithOutReplacement()).
So, `{{#FORMAL:Informal hello|{{GENDER:|Formal}} hello}}` worked,
but `{{#FORMAL:{{GENDER:|Informal}} hello|Formal hello}}` didn't.
Now they both work.
Bug: T379418
Change-Id: Ia4d57fd953dbd34e45789208ec8e765cce6ddf15
(cherry picked from commit 8b173830762738206919bd7b1a9ce3bba72dab5d)
MWCryptHKDF was added ten years ago (in af66c04d39), and as far as
I can tell, it was never used anywhere. It seems unlikely that CryptHKDF
will be used in the future, at least in its current form, for several
reasons:
* PHP 7.1.2+ has hash_hkdf(), so HKDF() would not be needed.
* At the time MWCryptHKDF was created, access to a CSPRNG was dependent
on server configuration: operating system, enabled PHP extensions,
open_basedir, etc. The "clock drift" RNG used as a last resort was not
considered to be secure or fast enough for generating large amounts of
output.[1] random_bytes(), added in PHP 7, changed the situation.
* Depleting the input pool of Linux's RNG is no longer a concern; there
is no more blocking output pool for /dev/random.[2][3] In 2022, this
change and others, including some that improved performance,[4] were
backported to stable kernels as old as 4.9.[5]
* $wgAuthenticationTokenVersion obviated the primary use case of
quickly resetting the user_token field for all users, assuming all
the existing tokens are unique.
* CryptHKDF seems to perform much slower than random_bytes(), at least
on Linux, making it pointless to use given that the other reasons for
its existence no longer apply.
[1]: https://bots.wmflabs.org/logs/%23mediawiki-core/20161004.txt
[2]: https://lwn.net/Articles/808575/
[3]: https://lore.kernel.org/all/cover.1577088521.git.luto@kernel.org/
[4]: https://www.zx2c4.com/projects/linux-rng-5.17-5.18/
[5]: https://lore.kernel.org/all/Yo3pmh9hiUFtQz77@zx2c4.com/T/
Change-Id: I29136fad826341d21728671aa30285d5551f1162
* Add FileBackend::addShellboxInputFile(), allowing Shellbox to read
directly from a FileBackend. Add generic, FS and Swift
implementations.
* Add FileRepo wrapper, which takes a FileRepo virtual URL.
* Add File::addToShellboxCommand(), which allows a File to be used as
input in a Shellbox command.
* Add configuration.
* Extend FileBackend::getFileHttpUrl(), adding method and ipRange
parameters. Unindent existing code.
I was going to add support for PUT requests, but I reverted it due to
the impossibility of supporting FileBackendMultiWrite. I left the method
parameter in getFileHttpUrl().
Bug: T292322
Change-Id: If9487a0c9586065bf044b69ac04cc7a06b6e8856
(cherry picked from commit 8cdde9dcb03e33332e49aed06aa71b60ae2c9b33)
This can cause PHP to try to load the param value as a class, with
potentailly disastrous results (though it’s not quite clear if this can
actually cause attacker-supplied code execution or not).
Bug: T377912
Change-Id: I0239b3e65cf516c6fdf287882f05e47a01f963c1
(cherry picked from commit cdf11b23474024dfe39057993372f2126302e244)
Add support for the new {{#FORMAL:}} syntax in jqueryMsg.
Add formalityIndex to mw.language.data, and add parsing for
this syntax mediawiki.jqueryMsg.js.
Bug: T366602
Change-Id: Idc6ce0d590729830fd734cccae860f2430b8475c
(cherry picked from commit 05170a2ea8d10b5f177cba1797e00babea52e941)
This was seen in WMF production during a train deployment, where namespacing of classes,
which had been serialized (for example CacheTime), along with our PSR-4 definitions may result
in cases where PHP tries to load the same PHP file more than once. Combined with non obvious
error messages, require_once gives us better behaviour and error messages.
More explicitly:
In T378006, the autoloader is entered from class_exists(), and the class has a filename
resolvable with PSR-4 which is already loaded by a non-PSR-4 class name. Using require_once
would allow class_exists() to return false in that case.
In T372500, the autoloader is entered from unserialize(). It looks like require_once would
just give you a more informative error message.
Bug: T378006
Bug: T372500
Change-Id: I928f29198af9baf81a3cae604b3adf41595c2176
(cherry picked from commit 03dd4ae7ae0e2ce7e45f0bf2cb913642eef842a8)
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead.
Followup to e662614f, using PHPStan.
Bug: T376276
Change-Id: I60d639b042b537bf2f531cc132f1b75a66b85acb
(cherry picked from commit da0a395efa7847916371f9c0a6b271faa022ff59)
Why:
- When a revision is imported and the wiki is configured to show
category changes in RecentChanges, a CategoryMembershipChangeJob is enqueued
that in turn runs CategoryMembershipChange for each category change.
- The resulting RC entries use the timestamp of the imported revision,
rather than the current time.
- If the revision being imported is older than $wgRCMaxAge, this can
cause the RC entries to be immediately deleted with a 1/10 chance by a
probabilistically enqueued RecentChangesUpdateJob.
What:
- Use the current timestamp for RC entries derived from
CategoryMembershipChange instances created for imported revisions,
instead of using the revision's timestamp.
Bug: T377932
Change-Id: Id697087b29e76ac64885f8c7a0e670f201474449
(cherry picked from commit 83d6c6870c1dca7e063bb4ac82c8675b085cc0fb)
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Changes to the use statements and some additions
are done automatically via script
This also updates @covers tag for the namespaced classes
Change-Id: I859ba6d05018c99710b744e2becab432410d3bca
'allowusertalk' should be set in the block API call when the "Editing
their own talk page" is NOT checked.
Bug: T376924
Change-Id: I19bab1e4dd6172e3d43c4bbda50765a173f6bcf0
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
This deprecates a number of methods which returned arrays by reference and
exposed internal representation details of the ParserOutput. It also
regularizes the return values to return consistent LinkTarget values,
working around the wide variety of different internal storage formats
used for links.
In the future, once these methods which expose the internal representation
are removed, we can simplify our internal storage as well. But for the
moment we add the new getter without changing the internal representation.
Note that by returning TitleValue objects this new interface also provides
a means to fix the issue identified in T204792 where interwiki and namespace
prefixes were getting confused. A TitleValue properly distinguishes between
these -- although the callers will still have to be careful to use it as
a TitleValue and not attempt to reparse it.
These methods also correctly handle fragments, which are present for the
language link type but stripped for the other linkt types.
Bug: T204792
Change-Id: I48a2077b9645124f83082afd953d6bf7a861270b
Jest tests don't cover PHP bugs :-P
Before, passing in the URL param wpExpiry as '3 days' or 'infinity'
wouldn't parse. Now it does. Add tests for reinforcement. The assertions
against `$fields[ 'EditingRestriction' ]` aren't that important and have
been removed to make use of the data provider easier.
Bug: T368583
Follow-Up: Ibc648117e6d4981c84e9df9f933ba033d339e908
Change-Id: I8070c90a535cac8715dcdf588c62aab14861a2fc
As a first step in a plan to reduce redundancy in OutputPage, replace
the $mIndexPolicy property of OutputPage with the corresponding
getter/setter methods in a ParserOutput held for the purpose of
storing metadata.
Bug: T301020
Change-Id: I6073f4033be936b669532ecf8104a8e5ff498e24
Why:
* When performing schema changes on virtual database domains, the
updatelog table may not exist on the DB connection being used
to perform the updates
* This is because the updatelog table will only exist on the
database used for the local wiki, and not a central wiki.
* As such, skip reading and writing to updatelog if the table
does not exist on the current DB.
** This will cause some updates to be repeated, but there is no
place to store that the update has completed and using a
local wikis' updatelog table would not prevent the update
from being performed again if update.php is run for a different
wiki in the same cluster when the table is shared.
What:
* Update DatabaseUpdater::updateRowExists and ::insertUpdateRow to
skip interacting with the updatelog table if it does not exist
on the DB connection being used to perform schema updates.
* Add tests for the currently completed untested DatabaseUpdater
class to verify these changes.
Bug: T377450
Change-Id: I60bf6028f17b0768588a09363ec28281954eb960
These use the new CdxMultiselectLookup component.
Values for the two inputs can be pre-filled with the
'wpPageRestrictions' and 'wpNamespaceRestrictions' URL parameters.
Tests to be added in a future patch (along with other tests around
partial blocks).
Bug: T362718
Bug: T362912
Bug: T368583
Change-Id: I53739bcdd63870fbfb57bc96298fc8d467bdfc2b
Special:Block is supposed to show a 'Confirm block' checkbox under two
conditions: if the 'hide username' option is being used, or if the user
is blocking themselves.
This patch takes the SPA-like behaviour a step further and will disable
the submit button and show the confirmation checkbox if the user target
is changed to the current user, or if the 'Hide username' checkbox is
checked. The logic of hiding the confirm checkbox and re-enabling the
submit button should follow the same rules.
Add `withSubmission()` helper to SpecialBlock.test.js and add test cases
for the newly added code.
Bug: T376754
Change-Id: Ie990051ae62b11f3a27bbc4cfc5c714a0096e2f3
Add a 'block' Pinia store to house all block-related data use in the
SpecialBlock.vue application. Minimal refactoring is done to make use of
the store, rather than passing around props.
UserLookup is reworked to only update the store's targetUser property on
a 'change' event, since the Codex Lookup component wants a "selection"
while we want to allow arbitrary input. This means anything that listens
to changes to the targetUser isn't fired off too quickly (i.e. API
requests, or flashing error states).
Other changes:
* Remove 'disabled' attribute from ExpiryField as the disabled state is
applied automatically.
* Change SpecialBlock.test.js to test against a date that's not a mere
decade away.
Bug: T376741
Depends-On: Ia88d987bf7e5afa1a17d63b4ebc96448ccec2f6c
Change-Id: Id6cff21eeeeb86876e59f70994ad10658ab6d9be
