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
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
This hook enables extensions such as CentralAuth to preserve and
use query parameters needed for an authentication flow. Since there
is a provider that handles logins in a different wiki (central login
wiki), and movement to a different URL, this hook preserves query
parameters that can be used between these requests.
Bug: T363483
Bug: T362713
Change-Id: I86e629b07e6e4a0f1d1a4c78a6c77d41b4d68e18
This is the Language Converter from Meitei Script to Bengali Script in mniwiki.
I don't know the language. I got help from a native speaker User:Haoreima.
The original prototype was in a Python Library written by myself.
It only converts the words that have Meitei characters (U+ABC0..U+ABFF).
The original prototype is already being used in mniwiki via Gadget and a Bot.
Bug: T357853
Change-Id: I810f18050f29efa38b2a646d96644e298af47c50
This splits RouteFileModule into two classes, ExtraRoutesModule and
SpecBasedModule.
ExtraRoutesModule has no module prefix and supports
only "flat" route definition files and additional routes from
extension.json.
SpecBasedModule represents a single module defined in a definition
file similar to an OpenAPI spec. The idea is that a full OpenAPI spec
can be generated by filling in any missing information based on
information provided by the Handler implementation. In particular, the
definition of parameters and request body schemas will be generated.
A JSON schema for the new file format is added under docs/rest/.
Support for the intermediate format introduced in Iebcde4645d4 is
removed. It was not included in a release and was not being used outside
core tests.
Bug: T366837
Change-Id: I4ce306b0997f80b78a3d901e38bbfa8445bed604
Special:RestSandbox presents a Swagger-UI interface for exploring REST APIs. The available APIs can be configured using RestSandboxSpecs.
For now, the default is to support no APIs, so the feature is disabled in production. In the future, it would make sense to expose the wiki's own REST API per default. The corresponding entry in $wgRestSandboxSpecs in LocalSettings.php would look like this:
'mw' => [
'url' => $wgScriptPath . '/rest.php/',
'name' => 'MediaWiki REST API',
]
Note that the spec URL may still change.
To also explore the endpoints exposed through RESTbase, we might add:
'wmf-restbase' => [
'url' => $wgServer . '/api/rest_v1/',
'name' => 'Wikimedia RESTbase API',
]
Similarly, we could expose a spec for endpoints on api.wikimedia.org, which could then be explored using the new special page.
NOTE: This adds a dependency on the swagger-ui npm library. See T325558 for the security review.
Bug: T362006
Change-Id: I1dd5ed82680a28f9c15136b446a2de0398525061
This is to make it clearer that they're related to converting serialized
content back into JSON, rather than stating that things are not
representable in JSON.
Change-Id: Ic440ac2d05b5ac238a1c0e4821d3f2d858bc3d76
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
Refactoring:
* Break out the database access part of UserOptionsManager to a separate
class hierarchy implementing interface UserOptionsStore. It's
basically a key/key/string-value store, very simple. The complex
parts of user options storage remain in UserOptionsManager.
* Bundle the UserOptionsManager caches into a per-user cache object. I
was adding a couple more and it was getting tedious.
Start integrating GlobalPreferences with UserOptionsManager:
* Have an array of stores. There's always a local store, and extensions
can add stores via an attribute.
* Add $global parameter to UserOptionsManager::setOption(), allowing
this method to update or override global options.
* Rename loadOptionsFromDb to loadOptionsFromStore.
* Move the local override feature from GlobalPreferences to core.
Bug: T323076
Change-Id: Ib3623b723557c819bc0ffdf21a4ffcb070eb298b
Experimental library that can display the login form in a small
browser popup window, a new browser tab or window, or an iframe in
a modal message dialog. We're still testing which of these methods
work from the technical side, and which are understandable for users.
Some methods or the whole library may be removed in the future.
Usage:
const authPopup = require( 'mediawiki.authenticationPopup' );
authPopup.startPopupWindow()
// or: authPopup.startNewTabOrWindow()
// or: authPopup.startIframe()
.then( function ( userinfo ) {
if ( userinfo ) {
// Logged in
} else {
// Cancelled by the user
}
}, function ( error ) {
// Unexpected error stopped the login process
} );
Or in future JS:
const userinfo = await authPopup.startPopupWindow(); // etc.
if ( userinfo ) {
// Logged in
} else {
// Cancelled by the user
}
In all three methods, the popup opens the login form with
&display=popup and with &returnto pointing to an unlisted special
page that communicates with the module on the parent page.
Once the library is stable, the AuthPopup component may be separated
from MediaWiki and released as its own package, to be used by tools
to open MediaWiki OAuth workflows in a similar way.
Bug: T364939
Change-Id: I08d9c799b8f79ebab2bcf4fcf330ee8eb995582e
Similar to LBForOwner, moving several internal methods there to fully
hide it from outside of rdbms.
Bug: T363839
Change-Id: I7a46d0e77d8865c6ed81ed351cb7fee0f9eda9cb
Setting this URL parameter will replace the default skin with a
"micro-skin" that omits most of the usual interface elements,
making the page suitable to be displayed in a small popup window.
Its design (such as it is) is mostly based on Vector 2022.
In the future, we might allow normal skins to serve this mode too,
if they advise that they support it by setting a skin option.
For now that is out of scope.
The login/signup process is otherwise completely normal. To make use
of it, launch the login page in a popup, and set &returnto=... to
redirect back to your own success page, which should communicate the
successful login to your app and then close itself.
The display=popup / display=page vocabulary is borrowed from the
OpenID Connect spec.
Bug: T362706
Change-Id: Ic7cbbe98344b25d2e965750e0c4429ce157163ed
This adds MediaWiki\Watchlist namespace to the classes of watchlist
directory and adds deprecation notice since 1.43 to the just created
unnamespaced aliases of the classes.
Bug: T353458
Change-Id: I4234f8fe62bb3bde6f5271c7ba31a2420b0f4b90
This adds MediaWiki\Content namespace to FallbackContent
and FallbackContentHandler and declares the unnamespaced version
as deprecated since version 1.43.
Bug: T353458
Change-Id: I3ee80aea379788b71539cc1c7a4ec216b753e042
This patch introduces a namespace declaration for the
MediaWiki\Content to JsonContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ia4ba6d3eddcb7b3f3d9f41a5ff80f724dbd01b22
This patch introduces a namespace, MediaWiki\RevisionList, and adds it
to the related classes and establishes class aliases marked as
deprecated since version 1.43.
Bug: T353458
Change-Id: I1614a00dd8973c5300d95317a725cbe46e14d1af
