WinCache is an APCu equivalent for use with Microsoft IIS, but in recent
years has been unmaintained and lacks support for PHP 8 and newer.[1]
So, remove support for it as MediaWiki will be raising the minimum
supported PHP version to 8.1.
[1] https://www.php.net/manual/en/install.windows.recommended.php
Bug: T365691
Change-Id: I4d2dc01a9119bb1f858132f0146b894750c1e86d
This allows to change the category link rendering by extension
CategoryTree without missing update of mCategoryData and mCategories
which leads to wgCategories = [] (T372155).
The new hook will be used in extension CategoryTree by
Ic86f210474cbc0e2dcebf664cf2309a4a4408f60.
Bug: T372155
Change-Id: Id82a77a57d1f12233d974ea4c1b093f50c5ab74f
Add a new hook that can be used to prevent authentication just
before AuthManager takes the main action (writing the session
for login, creating the local user account for account creation).
The driving use case is a wiki which supports both a local and
a central (wiki-farm-level) login or signup flow - various
security options (such as 2FA) are needed during local login
but unnecessary during central login (which will have those
security features centrally), so we need to skip much of the
security when the user is taking the central route, and a bug
in how that's done could result in circumvention of security
features during local login. The hook makes it easy to inspect
and potentially interrupt login near the end, when we know for
sure what route it took. (Specifically, we know which primary
provider was used. The hook doesn't expose other details,
such as the list of preauth or secondary provders that were
invoked, because they were not needed for the immediate use
case, but they are easy to add in the future.)
The hook is called after the secondary providers for login
and before them for account creation, since secondaries can
interrupt login but cannot interrupt account creation.
A shortcoming is that since the hook is called after a primary
provider succeeded, it cannot prevent the primary provider from
doing work, ie. it cannot prevent creation of the remote account
during account creation (although it will prevent the creation
of the local account). This is not great but acceptable, since
creating a new account isn't very security-sensitive.
This also means the hook would not be useful during account
linking, as AuthManager does not do anything there, all the work
happens in the primary provider. This is even less great but
few authentication extensions implement account linking.
The hook is not called for authentication happening via
CreatedAccountAuthenticationRequest, which is a weird internal
hack hook handlers should not have to know about.
Also rename a confusingly named variable.
Change-Id: I835b2fe2f43e6e81f23348165cbb9c93832e6583
Allow disabling authentication providers. This allows for
extensions to replace core providers with their own.
This is using the $wgAuthManagerAutoConfig keys instead of
AuthenticationProvider::getUniqueId() as the keys to filter.
This makes it more useful for site administrators, and also
it's probably the better known of the two identifiers so
more intuitive.
No effort is made to prevent the hook from filtering
differently in different steps of the same authentication
process.
Bug: T369180
Change-Id: If5435b54a4fc08f685c04fc10eb44c6d72cd78fa
Why:
* The fixDefaultJsonContentPages.php maintenance script was added
in 2986d47c90 which was MW 1.27
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove fixDefaultJsonContentPages.php
Bug: T373335
Change-Id: Ie20f55c6a8723573aa7e9acd67766af9dfb67269
Why:
* The populatePPSortKey.php maintenance script was added in
993ce4d411 which was in at
least MW 1.34.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populatePPSortKey.php
Bug: T373334
Change-Id: Iaa86bb193bf8feae9f5e2fe33255182e864d2e4f
Why:
* The populateBacklinkNamespace.php maintenance script was
added to update.php in MW 1.24 in
b8c038f678
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateBacklinkNamespace.php
Bug: T373333
Change-Id: Ia70fdd5c5ae087d7f5bdf4499185701bbb106c1f
Why:
* The addRFCandPMIDInterwiki.php maintenance script last had
it's update key modified in MW 1.23 in commit
bd38435848.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove addRFCandPMIDInterwiki.php
Bug: T373331
Change-Id: Ie6791c0cc2cfab5e09aa0b1c7ddcea1099cd1f79
Why:
* The populateRevisionLength.php maintenance script last had it's
update key modified in 0f79beec8b
which was MW 1.22.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateRevisionLength.php
Bug: T373313
Change-Id: Ic621e14a6ea7f455a396aac61b9919ed8436d71a
Why:
* The populateFilearchiveSha1.php maintenance script has been in
core since fb2c1c645b which was
MW 1.19
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateFilearchiveSha1.php
Bug: T373312
Change-Id: Ia68d11ccc5c9f470783acfe7139e48f76a1576c9
Why:
* The populateImageSha1.php maintenance script has been in core
since at least MW 1.19, being definitely added to update.php
in 1.19 through 7cb4d69d9d.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateImageSha1.php
Bug: T373310
Change-Id: Ibc6a31b1eafb7c5727d68bfb2526ffd7532408a6
Why:
* The populateRecentChangesSource.php maintenance script was
added in 6bbd4bca6c which was in
MW 1.22. It was added to the version-specific updater
list, which means it is no longer run in 1.43 and therefore
is also never called.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateRecentChangesSource.php
Bug: T373308
Change-Id: Iabe8f0b28966c9d57a19d6965cc2de7ce489e8ed
Why:
* The populateIpChanges.php maintenance script was added in MW 1.30
in commit d09554b6ef.
* Per the version policy, wikis wishing to upgrade to MW 1.43
should upgrade via 1.35 or 1.39 before moving to 1.43.
* As such, this script will have been already run for any wiki
upgrading to 1.43 and therefore this script is unused.
* Removing the script is useful to reduce the amount of untested
code in the maintenance directory and reducing unnecessary
maintenance on now unused code.
What:
* Remove populateIpChanges.php
Bug: T373306
Change-Id: Ie6b5405ceac4aa5465325dc5b5d3b82e3235390f
Why:
* The populateRevisionSha1.php maintenance script last had it's
update log key changed in MW 1.19 in c326cab5, and it has been
added to update.php since that version.
* This means that, since the script has been run via update.php
since before MW 1.35, it should be possible to remove the
script as all wikis will have run this script and therefore
it will be skipped for all wikis (as it's in the update log).
* Removing now unused maintenance scripts is important to reduce
the amount of untested code in the maintenance directory and
also prevents the need to update the code for migrations
(e.g. using the query builders).
What:
* Remove the populateRevisionSha1.php maintenance script.
Bug: T373238
Change-Id: Id3d46d6e0d4b8bd4aaf6d3ed01d7b759813c981a
Why:
* In the CheckUser extension, a maintenance script named
'purgeOldData.php' purges data from the recentchanges table.
* This script is run on WMF production daily to ensure private
data is purged.
* This should instead be in core, so that the functionality can
be used when CheckUser is not installed and also not duplicate
existing code used for the job that purges the table.
What:
* Create purgeRecentChanges.php which purges expired rows in the
recentchanges table by running the code in the
RecentChangesUpdateJob directly (without using the job queue,
as there is no need to do that because we are in a maintenance
script context).
* Add a test for this maintenance script
* Test the purging features of the existing job to ensure that
this code is reliable.
Bug: T373032
Change-Id: Id32780c00b053d7fec94a00812f8d40a6bf2e40c
Why:
* The Maintenance::fatalError method calls the exit method, which
when called causes the PHPUnit test suites to exit early.
* This means that code that calls ::fatalError cannot be tested
unless the method is mocked for each test.
* To avoid this problem the ::fatalError method should not call
exit() when running PHPUnit tests, as described in T272241.
Instead, it should throw an exception which can be caught when
the call is expected.
What:
* Create MaintenanceFatalError which extends Exception, which is
thrown by Maintenance::fatalError instead of calling exit() if
the 'MW_PHPUNIT_TEST' constant is defined.
** This new exception takes the error code passed to the
::fatalError method and uses it as the exception error code.
* Create MaintenanceBaseTestCase::expectCallToFatalError which
makes it easier for tests to assert that a call to
Maintenance::fatalError occurs. This can optionally assert
that the $code passed is as expected.
** Code which wishes to assert against the provided $msg can use
::expectOutputString or ::expectOutputRegex.
Bug: T272241
Change-Id: I554a963c63eb4f22ebb3273053a7b83a33dcb4d1
Add a hook to StartUpModule that can modify the source URLs
that get embedded into the startup module JS in the form of
mw.loader.addSource() parameters.
The intended use case is preserving relevant URL information,
especially in the case of the 'local' source which is a
relative URL, when the URL pattern of the load.php URL
that generates the startup module code is different from the
URL pattern of the page that loads that load.php URL.
(E.g. $wgLoadScript is set to a different domain than the
current page, to canonicalize load.php URLs for a site
that's reachable via multiple domains, but then by default
the local source is a relative URL which would be
interpreted relative to the URL of the page that executes
the startup module code, so it would result in calls to
non-canonical load.php URLs).
Bug: T365162
Bug: T371530
Change-Id: I199ab779abd0596b836ae43dcc5f2f2a489c9274
This code was partially copied into MassMessage and will hopefully
enable more places that accept arbitrary wikitext to check lint errors.
It also hides the internal details of checking with the Linter
extension's configuration in one place until it can be refactored into
something more acceptable (T360809).
Bug: T368690
Change-Id: Iaeb3ccbd61a2a8cb0d8b3dc8b06a3a10bc8fa653
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
In T361190 and Quibble 1.9.0, we introduced parallel execution of
PHPUnit tests to speed up the CI jobs. The existing implementation
is purely Python/Quibble, and cannot directly be used by developers
locally. With this patch, we re-implement the parallel test
execution already implemented in CI as a composer task so that the
parallel tests can be run locally.
The `phpunit:parallel:extensions` command expects to be run after
`phpunit:prepare-parallel:extensions`, and expects to find 8 test
suites with the names `split_group_X` (for X in 0 through 7) in the
PHPUnit configuration file. 8 here is currently a hard-coded number
that corresponds to the number of parallel test executions we need
to saturate the CPU of a 4-core developer machine, and experimentally
leads to a good speed-up versus the serial execution.
When this command runs, it forks to launch 8 parallel processes,
each running one of the `split_group_X` suites. The parent process
waits for the children to complete, buffers the output, collects the
exit statuses, then dumps the buffered output and exits with a
non-zero status if any of the child processes failed (i.e. if there
were test failures).
We introduce `phpunit:prepare-parallel:default` as a complement to
`phpunit:prepare-parallel:extensions`, and the two commands
`phpunit:parallel:database` and `phpunit:parallel:databaseless`.
This creates four possible combinations - two different test suites,
and two different test groups. This is a similar setup to that which
we have in CI - the Database and non-Database tests are run in
separate groups, and some jobs use the `extensions` suite while
others just use the default suite.
The `phpunit:parallel:...` commands will fail with a helpful message
if no `split_group_`s are found in the active PHPUnit configuration.
To help test whether the split test runs are really running all the
tests in the suite, we generate and store the PHPUnit results cache
file. Comparing the results cache files from linear versus parallel
runs should tell us if all the tests have been executed.
Bug: T365976
Change-Id: If106802f08edd5d4c841bb7970c69b88ab3bb39b
In preparation for also handling the AS_REVISION_WAS_DELETED failure in the
constraint, rename it in a separate commit so that git can more easily track
the change.
Bug: T157658
Change-Id: Id55b40d8e327429fbaf45a96c0b00caaa9110da1
In T361190 and Quibble 1.9.0, we introduced parallel execution of
PHPUnit tests to speed up the CI jobs. The existing implementation
is purely Python/Quibble, and cannot directly be used by developers
locally. With this patch, we re-implement the test splitting logic
already implemented in CI as a composer task so that the parallel
tests can be run locally.
There are a couple of different approaches to running PHPUnit tests
in parallel. The different approaches have been discussed at length
in T50217. Ideally, we would just install the `paratest` extension
and use that to parallelise the execution. Unfortunately we have
complex test suites (specifically Parser tests and the Scribunto
test suite) that dynamically create tests as they run, which makes
it hard for `paratest` to work out which tests will run.
To overcome this limitation, we use the `phpunit --list-tests`
function to create a list of test classes that would be included in
the execution of the test suite, then scan the filesystem for
classes named in the `tests-list.xml` output. The classes we find
are then collected into smaller groups (`split_group_X`) which we
can run in parallel in separate processes.
We split into 7-8 groups here, as that experimentally leads to an
even spread of the tests and consumes 100% of all cores on a 4-core
processor.
Because `ParserIntegrationTest.php` is a single test class that
generates thousands of integration tests, we put that in its own
bucket rather than allocating it round-robin to one of the split
buckets. This again helps to keep the buckets roughly the same size.
The current implementation only supports splitting the `extensions`
test suite. We need to do some more development and testing to
support splitting other suites.
The new composer command `phpunit:prepare-parallel:extensions` will
generate a `phpunit.xml` file with the same contents as
`phpunit.xml.dist`, but with the split-group suites added. The
result of running all of the split groups should be the same as the
result of running the whole test suite.
Bug: T365976
Change-Id: I2d841ab236c5367961603bb526319053551bec2e
