This breaks later tests, e.g.:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/450433https://gerrit.wikimedia.org/r/c/mediawiki/core/+/465423
The only reason this didn't cause test failures until now is because the
namespace data was getting (incorrectly) cached in between tests. As
soon as we start resetting namespaces for each test, namespaces set by
the extension registry get wiped out by these tests.
Change-Id: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
So we don't need to hackily deal with ExtensionRegistry internals.
Depends-On: I9e62a02ed2044c847e9ab2dcdfab094001f88986
Change-Id: Id6ca6eb49db789dbb3f227533c4442506cc61bc4
As a direct effect
- sending emails and creating accounts now respects $wgAllowConfirmedEmail
- log messages get a bit less verbose for mail sending and creating
accounts (but should be clear from the context what action was
performed)
- less code duplication \o/
Indirectly, this should make solving the attached bug easy(tm), because it
just needs to add a hook to the canSkipCaptcha function.
Bug: T176589
Change-Id: Id27b0eadbab7300b9e6969d406fa6f00ef0888bf
Instead of misusing the config section of extension.json to declare
captcha triggers in the ConfirmEdits CaptchaTriggers config variable,
other extensions can now use the CaptchaTriggers attribute for the
exact same thing. E.g., to declare a new trigger, the following
addition to the own extension.json will register the trigger in
ConfirmEdit:
"CaptchaTriggers": {
"wikiforum": true
}
This also removes the CaptchaClass config from the main extension.json
config section, and automatically sets the SimpleCaptcha module in the
getInstance() method of ConfirmEditHooks, which is a pre-requirement for
the mediawiki/core change Ieeb26011e42c741041d2c3252238ca0823b99eb4.
Bug: T152929
Change-Id: I4c5eaf87657f5dc07787480a2f1a56a1db8c714f
