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
The captchas in production are registered conditional, in tests the
class needs to be added to the autoloader.
Moved this register up to setUp to detect the existing @covers correctly
by the new testValidCovers from
I1d564bcae2bfbedb004c440b90db6341148ed4ba
Change-Id: I79f225126d7bbbfd436ab165bb98a0ed9517b8bc
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
