Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create FixUserRegistrationTest that fully tests the associated
maintenance script.
Bug: T371167
Change-Id: Ifb3594f7dc0055568431002a9180df7db4da9692
Why:
* Maintenance scripts in core have low test coverage, and
increasing the test coverage will help avoid regressions and
bugs.
What:
* Create RenameUserTest which tests the renameUser.php
maintenance script for when invalid arguments are provided.
Bug: T371167
Change-Id: I778f45e74708d1ad25b8bda918f5c3ca03e4668d
Why:
* Maintenance scripts in core have low test coverage, and testing
them is important to avoid regressions and bugs.
What:
* Create ResetAuthenticationThrottleTest which tests the script
for invalid or missing options, as well as resetting the
throttles for temporary account creation and name acquiration.
Bug: T371167
Change-Id: Ied9619f12f3f41040b1837e0923f8c7fb345175c
> Given all called same-class methods are de-facto and liberally claimed,
> and that we keep the coverage limited to the subject class, it maintains
> the spirit and intent by listing the class as a whole instead.
>
> PHPUnit offers a more precise tool when you need it (i.e. when testing
> legacy monster/god classes), but for well-written code, the
> class-wide tag is exactly what you want.
>
> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors, especially private functions (or worse,
> forget to update it).
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: If90fc5285a067ec8f706d87b2ba1ae85020e2ba0
To be merged after the following change has been deployed: https://gerrit.wikimedia.org/r/1060893
Bug: T366271
Change-Id: I1dd9a91bc37e32bde15f52271fbea2580943ab99
Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create JSParseHelperTest that fully tests the associated
maintenance script.
Bug: T371167
Change-Id: I6ae5d9722169518dd19fd5136b12b7ecd6a22798
Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create MoveBatchTest that fully tests the associated maintenance
script.
Bug: T371167
Change-Id: I2244f46e34e81c98a2647e00b229ca68bc3d3568
Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
* Doing this for frequently run scripts is important, as they
may fail in ways not caught by running them in CI.
What:
* Create CheckComposerLockUpToDateTest that fully tests the
associated maintenance script.
** Move test case composer JSON files used by the LockFileCheckerTest
class into the 'phpunit/data' folder instead of placing them
in the same directory to allow the new test class to use these
files too.
Bug: T371167
Change-Id: Id473ef440c6b7f8ecbb1c869f9cc0cf98705a0e9
Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
** For example, in testing the script a bug is found where the
Maintenance::purgeRedundantText method will throw an
unexpected exception if no valid rows exist in the
content_address table.
What:
* Create DeleteOldRevisionsTest that fully tests the associated
maintenance script.
* Update Maintenance::purgeRedundantText to not attempt to
use an empty list as the value provided to
IReadableDatabase::getExpr.
** Add a regression test for this.
Bug: T371167
Change-Id: Id0c3c5d6fe56bc9fe5d5347c82dab9ab61137f58
Some wikis treat the category list from ParserOutput as a /set/, others
as an /ordered list/. For those who don't care about the order of
categories, provide the option for wikis to sort the categories
in OutputPage.
This can also be activated with a query parameter, `&sortcat=1`, which
is useful to the Parsoid team when doing visual diff testing to avoid
false positives caused by differences in category ordering.
Bug: T373480
Change-Id: Idd14650a1898c6a49c88441ef024ce3012903bbe
Extensions can use the ArticleParserOptions hook to customize the
parser options used for article read views, and Visual Editor uses
ApiParse to regenerate the article read view HTML after edit. In
order for VE to remain consistent with the original parse options,
provide a `usearticle` option to the parse API to allow it to invoke
the ArticleParserOptions hook.
Bug: T373212
Change-Id: I906affc8d2335b7bb48dff3a4b061fcf86b71cee
Follows-up changes I57a8e7ea1b3, I1e76d2f5ae, I98ea4670e8, and
more in a search for "parse_url" in Codesearch (WMF Deployed).
Bug: T319340
Change-Id: I2b389612f4d591080f7e6235ddfc72f832b31143
Update a few tests that relied on the feature flag to ignore
the 'requireemail' preference on "User1" to instead use "User2",
who doesn't have the preference set.
Bug: T242406
Change-Id: I996d3996272d704a071d1d2094c3568247b80f98
This method has a weird behavior where it resets the category *link* list
while not resetting the category *list*. It turns out that no one actually
needs that weird behavior; in fact no one needs this method at all, since
the only external user is the Translate extension, which could use the
OutputPage::addCategoryLinks() method instead, which has existed since
2014 (Id25041a7891f588ffa787fdd2c092342eecd30c8).
Deprecate this method with warnings.
Bug: T373480
Depends-On: Id25041a7891f588ffa787fdd2c092342eecd30c8
Change-Id: I7b07d761eb8cd5ad1e6da2dd836e969a0d492c2b
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:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create PurgeOldTextTest that tests the maintenance script
by mocking the ::purgeRedundantText method.
** Mocking this method is done because it should be tested
directly instead of indirectly through this maintenance
script
** Using this method of mocking avoids the need for a database
test, which speeds up the execution of this test class.
Bug: T371167
Change-Id: I0a79fa79f151ff4102f746becaea2c800a7cd064
Y2K38 is 14 years from now. Past experience shows that some installs
survive well over 14 years.
Windows 32bit is 0.04% and those systems are very unlikely to ever run a
2025 version of MediaWiki.
Bug: T122660
Change-Id: I45274f639159de83413e05aa498539f7be5f0e05
Why:
* Maintenance scripts in core are mostly untested and testing them
will help to avoid regressions.
What:
* Create RemoveInvalidEmailsTest that fully tests the associated
maintenance script.
Bug: T371167
Change-Id: I0c269e6d581c6da63d67c869d29f6f7b59033fd4
We were only showing the development mode warning when Codex was used in
code splitting mode, but not when the full library was being loaded.
Bug: T314507
Change-Id: I22e9707b659b004ef1059f8b13feaf3f61b7ca28
This patch lays the groundwork for incremental/selective parsing in
Parsoid by ensuring that we can pass previous cached parses through
the parse pipeline to Parsoid. We do this by adding a new render
hint type, `previous-output`, and ensuring it is passed along.
Because revisions can contain a ParserOutput which is the combination
of separate ParserOutput objects for each of their slots, RenderedRevision
also contains a method to unsplit the combined ParserOutput to reconstruct
an original ParserOutput for use in incremental parsing. Currently this
is mostly a stub, but illustrates how slot combination and splitting can
work, assuming those transformations are reversible.
Extra calls to ParserCache::getDirty() are added to some code paths
in order to ensure that any previously-cached ParserOutput is available
for selective update. In order to mitigate any performance concerns,
these are only done for the Parsoid parser at the moment. Future
patches will add additional metrics to quantify the cost/benefit ratio
of the additional cache lookups on these paths.
Bug: T363421
Bug: T371713
Change-Id: I440884f1d7e09c1ff9806f848b7b53a636367690
