Extension talk:ConfirmEdit

Jump to navigation Jump to search

About this board


What do you have in your visual CAPTCHA warehouse?

2 (talkcontribs)

Because this is straight out weird. (talkcontribs)

The text reads "bakedbeams" before the Captcha expires the entry image.

Reply to "What do you have in your visual CAPTCHA warehouse?"
Costas Athan (talkcontribs)

Not a bug. I had enabled the CSP header (Manual:$wgCSPHeader/en) and I should add an exception for the hCaptcha scripts in order to load. I did it and now everything seems to work fine. At least the hCaptcha loads normally.

I am using MediaWiki 1.35.0.

I created an hCaptcha account and I enabled hCaptcha following these instructions: https://www.mediawiki.org/wiki/Extension:ConfirmEdit#hCaptcha (For added safety I basically load the keys from an external file, out of the webroot, as described here for MySQL passwords: https://www.mediawiki.org/wiki/Manual:Securing_database_passwords)

The problem is that the hCaptcha does not load. I get the text "To protect the wiki against automated account creation, we kindly ask you to solve the following hCaptcha:", but hCaptcha isn't available.

Am I missing something about its configuration?

HenriqueCrang (talkcontribs)

Does ConfirmEdit save a log of all the events when it shows a captcha? I'm interesting in looking for the user, the content and the captcha answer for each attempt. Is it possible?

Reply to "Log of CAPTCHA attempts"

ConfirmEdit or Google ReCaptcha v2 not working?

Chuck.Kahn (talkcontribs)

Recent flood of new spam users on my Wiki over the last 12 days.


How do I stop this flood? I've had ConfirmEdit installed with Google ReCaptcha v2 on this Wiki since 16/08/2018. Did Google ReCaptcha v2 change something? I have been using the same set of Google ReCaptcha keys on two different Wiki domains. Was that the problem? I just now created separate keys for each Wiki. The other Wiki's newuser list is here:


And here's my LocalSettings.php setting:

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ]);

$wgCaptchaClass = 'ReCaptchaNoCaptcha';

$wgReCaptchaSiteKey = 'your public/site key here';

$wgReCaptchaSecretKey = 'your private key here';

I opened a Chrome Guest window and was freely able to create a Test page on my Wikis without being logged in. Shouldn't ConfirmEdit be... confirming the creation of new pages in that situation?

Dinoguy1000 (talkcontribs)

I was going to say that ConfirmEdit + ReCaptcha v2 is incompatible with VisualEditor (per these edits), but it appears that your wikis don't use VisualEditor. I guess this module is simply broken somehow.

I can't offer a fix, but I will suggest that if you can, to switch to the QuestyCaptcha module; with unique question/answer pairs, it completely eliminates automated spam unless the spammer decides to specifically target your wikis (and even then, you can simply switch out the question/answer pairs).

Chuck.Kahn (talkcontribs)

So I #-d out the ReCaptcha lines and added these QuestyCaptcha lines and tried creating a Test7 page in a Guest Chrome window and again got no prompt. Same creating a Test8 page from another PC.

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);

$wgCaptchaQuestions = [

'What is the capital of France?' => 'Paris',

'What is the capital of Spain' => 'MADRID', // Answers are case insensitive

'What is the name of this wiki?' => $wgSitename, // You can use variables

'How many fingers does a hand have?' => [ 5, 'five' ], // A question may have many answers


Chuck.Kahn (talkcontribs)

Tried creating a new page today in a Guest Window and was prompted with the QuestCaptcha question 'What is the capital of Spain' -- so it works now. I didn't change anything from yesterday but today it works.

Chuck.Kahn (talkcontribs)

Got a ton of spam today so I changed the QuestyCaptcha questions. Anything else I should try?

Dinoguy1000 (talkcontribs)

The questions you set for QuestyCaptcha shouldn't be generic. Ideally they'll reflect the subject of your wiki, and shouldn't be super-obvious without at least a passing familiarity with the subject (though you should also be careful not to make them too obscure). The questions in the code you posted in response to my first comment are all bad ideas for actual questions to use, especially since they appear directly on the extension page here as examples of questions.

With proper question/answer pairs, QuestyCaptcha is going to be one of the most effective anti-spam measures you can install that still allow for normal editing with minimal hassle.

Chuck.Kahn (talkcontribs)

Saw the main page of my wiki was vandalized today. I opened a guest window in Chrome and was able to edit the main page -- no QuestyCaptcha prompt needed. Then I added these lines to LocalSettings.php:

$wgMainCacheType    = CACHE_ANYTHING;

$wgCaptchaTriggers['edit']          = true;

$wgCaptchaTriggers['create']        = true;

$wgCaptchaTriggers['createtalk']    = true;

$wgCaptchaTriggers['addurl']        = true;

$wgCaptchaTriggers['createaccount'] = true;

$wgCaptchaTriggers['badlogin']      = true;

And the QuestyCaptcha prompt appeared. Here I was adding harder and harder questions to QuestyCaptcha every time spam appeared and it turns out it wasn't the questions but these added option lines that are needed.

Dinoguy1000 (talkcontribs)

QuestyCaptcha isn't intended to stop vandalism, but to stop automated spam. Vandalism is almost always done by humans, so any questions that allow for normal editing are going to be trivially defeated by vandals. You should instead use other tools for antivandalism, such as protecting high-traffic pages that shouldn't be edited often (e.g. your main page, and any very widely used templates), and installing and configuring AbuseFilter. QuestyCaptcha itself should usually only be configured to trigger on account creations and bad logins, and on page creations and new external link insertions for anonymous or non-autoconfirmed editors.

Reply to "ConfirmEdit or Google ReCaptcha v2 not working?"

FYI: Known issue with Extension:MobileFrontEnd: Captcha on sign-up page is not working/shown/reply not saved

CayceP (talkcontribs)
Reply to "FYI: Known issue with Extension:MobileFrontEnd: Captcha on sign-up page is not working/shown/reply not saved"

FancyCaptcha "pool.py error" generating Captcha images

Dthrevan (talkcontribs)

Having issues generating captcha images, please help!

Current setup:

Python 2.7.18

Python Imaging Library 1.1.7 for Python 2.7 (Windows Only)

Error below:

C:\Python27>python.exe C:\Ex\captcha.py --font C:\Ex\FreeSans.ttf --wordlist C:\Ex\words.txt --key=Foo --blacklist C:\Ex\blacklist.txt --output C:\Ex\ --count=20

Generating 20 CAPTCHA images separated in 20 image(s) per chunk run by 1 threads...

Traceback (most recent call last):

  File "C:\Ex\captcha.py", line 298, in <module>

    p.map(run_in_thread, data)

  File "C:\Python27\lib\multiprocessing\pool.py", line 253, in map

    return self.map_async(func, iterable, chunksize).get()

  File "C:\Python27\lib\multiprocessing\pool.py", line 572, in get

    raise self._value

NameError: global name 'verbose' is not defined

Dthrevan (talkcontribs)


Ulrich C. Thiess (talkcontribs)

Same problem here. Need help. Thanks.

Reply to "FancyCaptcha "pool.py error" generating Captcha images"

Problem with Confirm edit for 1.34

2 (talkcontribs)


I am trying to use ConfirmEdit with Recaptacha but i get an error at the top of the page when i enable it, do anyone know why? i have the latest version of the extension and i am running Mediawiki 1.34. the error goes away when i dissable the extension.


Deprecated: Use of Using $ceAllowConfirmedEmail is deprecated, please migrate to $wgAllowConfirmedEmail as a replacement. is deprecated. [Called from require_once in /includes/Setup.php at line 906] in /includes/debug/MWDebug.php on line 333



wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ]);

$wgCaptchaClass = 'ReCaptchaNoCaptcha';

$wgReCaptchaSiteKey = '';

$wgReCaptchaSecretKey = '';

TiltedCerebellum (talkcontribs)

Does your site use visual editor with which ReCatcha is not compatible?

Reply to "Problem with Confirm edit for 1.34"

Captcha is not shown for login failures

2409:4043:194:CE4A:18E0:AF1B:B5C:9BAF (talkcontribs)

I have added this code to Localsettings.php:

2409:4043:194:CE4A:18E0:AF1B:B5C:9BAF (talkcontribs)

I have added this code to Localsettings.php:

$wgCaptchaTriggers['badlogin'] = true;

However it doesn't show captcha question when I try to login with bad username or password.

It shows well for creating new acccount, so setup looks good.

Please suggest what should be done to fix.



Reply to "Captcha is not shown for login failures"
Farvardyn (talkcontribs)

By default, in which cases QuestyCaptcha asks question while editing/adding an articles and when not asks? Does it depend on email confirmation?

Dinoguy1000 (talkcontribs)

Defaults for ConfirmEdit are listed on its page; QuestyCaptcha uses these defaults. In particular, captchas are by default shown to everyone except for bots and admins, any time a new URL is added to a page, an account is being created, or a login fails. See the section I linked for details on how to customize this setup for your wiki.

Reply to "QuestyCaptcha"

QuestyCaptcha not preventing account creation

SheldonBole (talkcontribs)

I have QuestyCaptcha setup on my wiki. When I go to Request account, I see the QuestyCaptcha question, but whether I enter a correct or incorrect value the account request is processed, i.e. I see the resulting "Your account request has been sent and is now pending review. A confirmation email has been sent to your email address." Additionally, when I look under Open account requests the account request does appear there.

The site is on:

MediaWiki R1.34

PHP V 7.3.17

ConfirmEdit section in LocalSettings.php looks as follows:

// QuestyCaptcha Settings

   wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);

   $wgCaptchaClass = 'QuestyCaptcha';

   # QuestyCaptcha questions:

       $wgCaptchaQuestions = [

           'How many fingers on one hand?' => [ 5, 'five' ],


       $wgMainCacheType = CACHE_ANYTHING;

       $wgCaptchaTriggers['createaccount'] = true;

Any guidance would be greatly appreciated!

Dinoguy1000 (talkcontribs)

It sounds like your wiki is configured to require all account registrations to be approved by an administrator/trusted user? ConfirmEdit/QuestyCaptcha may not have been tested in that type of environment, since no WMF wikis have such a setup.

SheldonBole (talkcontribs)

Hello Dinoguy1000, thanks for the suggestion. I am busy following up, as in I'm turning those settings off to see if I can get QuestyCaptcha to work, but have run into other, I hope unrelated, issues. So I'm sorting those issues before being able to test your suggestion. On Extension:ConfirmAccount it does specifically say:

"The ConfirmEdit extension can be used (in conjunction with the ConfirmAccount extension) in order to use captchas to stop flood requests."

However, I do understand from your suggestion you are specifically referring to QuestyCaptcha.

I have a few things I want to test... I'll be back.

SheldonBole (talkcontribs)

For anyone finding this thread, Extension:ConfirmEdit's QuestyCaptcha and Extension:ConfirmAccount don't play nicely!

When QuestyCaptcha's creataccount trigger is set to true, the question appears correctly on the account request form. However, incorrect answers to QuestyCaptcha have no effect and account requests are still submitted.

I have set $wgCaptchaTriggers['createaccount'] = false as the Captcha is not having any effect on account creations.

We decided to rather keep the account approval (through Extension:ConfirmAccount) and QuestyCaptcha functionality on the other Extension:ConfirmEdit's triggers. This has stopped fake accounts being created on our wiki at this stage.

For a brief period when I had:

$wgGroupPermissions['*']['createaccount'] = true; and

$wgCaptchaTriggers['createaccount'] = false;

We were inundated with fake account creations. Even though I had ConfirmAccount enabled. To solve this I set $wgGroupPermissions['*']['createaccount'] = false;. New users then need to "Request Account" through ConfirmAccount's functionality. This doesn't really affect user experience, but does stop bots creating fake accounts.

Reply to "QuestyCaptcha not preventing account creation"