Extension talk:ConfirmEdit

From MediaWiki.org
Jump to: navigation, search
Start a new discussion


Thread titleRepliesLast modified
MediaWiki 1.25.1219:28, 31 May 2015
reCaptcha 2.0312:54, 27 May 2015
Solution for typical problems with reCaptcha and MediaWiki 1.25112:50, 27 May 2015
Usernames still store even after a failed Captcha106:43, 5 May 2015
Create account is no longer working on my wiki219:38, 1 March 2015
Captcha for BlogPage Extension004:50, 28 February 2015
QuestyCaptcha with multiple answers?817:06, 21 February 2015
[Proposal] Creating questions for spambots but not for humans220:22, 20 February 2015
No CAPTCHA reCAPTCHA715:41, 18 February 2015
[Proposal] Use the same question on repeated requests115:24, 28 January 2015
Risk with $wgEnableWriteAPI?117:41, 26 January 2015
Reverts on ConfirmEdit's QuestyCaptcha519:51, 20 November 2014
Allowing autoconfirmed to skip captcha not working220:02, 12 November 2014
The current version of this extension is not compatible with 1.20701:22, 6 November 2014
Are you human?113:20, 29 October 2014
New users and URLs.... 105:20, 22 October 2014
Make Captcha more visible to users221:46, 16 October 2014
What is Special:Version106:28, 13 October 2014
Documenting Asirra119:37, 6 October 2014
Asirra configuration parameters020:42, 31 July 2014
First page
First page
Previous page
Previous page
Last page
Last page

MediaWiki 1.25.1

I am getting the folowing error, what should I have to do?

Fatal error: Uncaught exception 'Exception' with message '.../w/extensions/ConfirmEdit/extension.json does not exist!
Jaider msg23:17, 30 May 2015

Fixed in documentation, ConfirmEdit itself doesn't have extension registration yet, so please use the "old" installation routine:

require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";

Sorry for the confusion!

Florianschmidtwelzow (talk)13:56, 31 May 2015

Thanks for answering, but now I am getting the following error message

Invalid or virtual namespace -1 given.

when editing with SemanticForms (without ConfirmEdit, SemanticForms works just fine)

Jaider msg19:28, 31 May 2015

reCaptcha 2.0

Is there any plans to support reCaptcha v2 ?

Vedmaka13:32, 30 April 2015

My impression is that this extension is only maintained in a way that it works for WMF purposes. The extensions page as well as gerrit "are full of unmerged patches, patch suggestions and so on". I guess the answer is no until someone takes over maintaining this extension.

[[kgh]] (talk)19:03, 4 May 2015

Well, people can help review: there is a patch by Florian, if everyone tested it and confirmed it works then folks like Emufarmers and others with +2 powers would presumably be more comfortable with merging.

Nemo09:37, 11 May 2015

+1 Nemo! The changes are open for all interested people for testing and giving feedback. That would help us a lot. There is a bug tracking the work on getting the new captcha into ConfirmEdit since a long time: phabricator:T84918 and there are two patches in ConfirmEdit (both linked in the task), so feel free to take one, test it and report back what happened :)

Florianschmidtwelzow (talk)12:54, 27 May 2015

Solution for typical problems with reCaptcha and MediaWiki 1.25

If you're updating, start with deleting whole extensions/ConfirmEdit dir and copy it from mediawiki 1.25 archive. Replacing files won't do any good.

    • Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class 'ConfirmEditHooks' not found in /var/www/te_pl_wiki/includes/registration/ExtensionRegistry.php on line 169
    • Solution: include ConfirmEdit.php in your LocalConfig before loading a ReCaptcha.
    • Example:
require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
require_once "$IP/extensions/ConfirmEdit/ReCaptcha.php";
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = 'your-public-key';
$wgReCaptchaPrivateKey = 'your-private-key';
    • Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, function 'efReCaptcha' not found or invalid function name in /var/www/bw_fr_wiki/includes/Setup.php on line 678
    • Solution: edit extensions/ConfirmEdit/ReCaptcha/extension.json and remove "efReCaptcha" from "ExtensioFunctions"
    • Example:
"ExtensionFunctions": [
    • Error: PHP Warning: require_once(ReCaptcha/recaptchalib.php): failed to open stream: No such file or directory in /var/www/br_pl_wiki/extensions/ConfirmEdit/includes/ConfirmEditHooks.php on line 147
    • Solution: edit extensions/ConfirmEdit/includes/ConfirmEditHooks.php and edit function onReCaptchaSetup(), so it can find the file.
    • Example:
       public static function onReCaptchaSetup() {
               //error_log("cwd: ".getcwd()); // to debug currect dir location in log
               require_once( "extensions/ConfirmEdit/ReCaptcha/recaptchalib.php" );
       }, 27 May 2015

> Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class 'ConfirmEditHooks' not found in /var/www/te_pl_wiki/includes/registration/ExtensionRegistry.php on line 169

You shouldn't use "only" ReCaptcha, it's a bad practice including the framework in a module, that's why it's not working with ExtensionRegistration. A much smaller solution, btw, would be to use: wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptcha' ) );

> Error: PHP Warning: call_user_func() expects parameter 1 to be a valid callback, function 'efReCaptcha' not found or invalid function name in /var/www/bw_fr_wiki/includes/Setup.php on line 678

Tracked in: phabricator:T100504

> Error: PHP Warning: require_once(ReCaptcha/recaptchalib.php): failed to open stream: No such file or directory in /var/www/br_pl_wiki/extensions/ConfirmEdit/includes/ConfirmEditHooks.php on line 147

Tracked in: phabricator:T100505

Florianschmidtwelzow (talk)12:49, 27 May 2015

Usernames still store even after a failed Captcha

I've noticed that even when bots fail the Captcha it still stores the attempted username in my database. Does anyone know a way to change this so that the names only store if they pass the Captcha?

Your observation is incorrect. If you fail the registration captcha, the account doesn't get created. Bots however keep trying until they pass the captcha: since most captchas are broken (including ReCAPTCHA) eventually they succeed.

Nemo06:43, 5 May 2015

Create account is no longer working on my wiki

Initially, ConfirmEdit worked great, however recently I have had several people who were unable to create new accounts. I tried it myself on multiple computers with multiple different browsers & I am unable to create a new account.

  • My wiki Create account page is located here Vendopedia.com
  • Once you enter a username & password & select the Create your account button the intended page never loads

Any help resolving this would be greatly appreciated

Mojorhino (talk)21:27, 28 February 2015

I figured it out

  • After looking up what Asirra was I was able to get it working again by commenting out the following
##require_once "$IP/extensions/ConfirmEdit/Asirra.php"; 
from my LocalSettings.php file

After saving the settings everything is working once again

Mojorhino (talk)06:06, 1 March 2015

Indeed, that's because Asirra was discontinued by Microsoft.

Nemo19:38, 1 March 2015

Captcha for BlogPage Extension

Can you work with Captcha in Extension Blog Page? I would like to use Captcha in the comments of WikiBlog and still do not know how I can do this.

Can someone help me? Thank you in advance!

Alex Liebrecht (talk)04:50, 28 February 2015

QuestyCaptcha with multiple answers?

Is it possible for a single question in QuestyCaptcha to have more than one acceptable answer? For example, is it possible to have a question such as "Fill in the blank: Blue is a ____" and allow the user to get through with both "color" and 'colour"?

Schiffy (talk)15:41, 10 October 2014

Yes, just put the correct answers into an array:

/* ConfirmEdit */
require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php'; 
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
        "A question?" => "An answer!",
        "Fill in the blank: Blue is a ..." => array(
                'colour', 'color'
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array(
        'question' => $key, 'answer' => $value

I will add this to the docu. Cheers

[[kgh]] (talk)15:58, 10 October 2014

Sorry to bother, but this doesn't seem to work as intended. I tried to add an external link to my main page, and the questions with one answer could be passed successfully, but the questions using array() are not letting me through. On a side note, my custom made "Webmaster" group should extend sysop, but I still had to give it skipcaptcha manually.

Schiffy (talk)18:26, 13 October 2014

Yeah, this was quite irritating. After changing to "A question?" => 'An answer!', both worked nicely. However not if you use ". Obviously the answers have to be "quoted" identically. Sorry for this.

[[kgh]] (talk)18:54, 13 October 2014

Well right now I'm using only ' (not ") for all the questions and all the array() bound answers), including in the foreach loop at the end ($wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );), and it seems to still not be working.

Schiffy (talk)19:15, 13 October 2014

Cannot tell why it is not working for you now, but perhaps there is somebody else who sees the problem and may help. After I changed this one line in my example above everything works out fine for me.

[[kgh]] (talk)19:18, 13 October 2014

[Proposal] Creating questions for spambots but not for humans

A lot of spamming accounts were creating in my wiki although I had recaptcha in ConfirmEdit extension. I did some investigation why it happened. Here is what I found:

  1. Actually SimpleAntiSpam feature works very efficiently (it is core mediawiki feature now). It stops a lot of spambots. It makes me to add it with some improvements to ConfirmEdit/QuestyCaptcha to make it to work also during account creation.
  2. No one spambot that I see had javascript support. Although some of them can break recaptcha.

My idea is to get rid of human captchas and to create invisible “captchas” for spambots instead. It works similar to QuestyCaptcha but instead of questions for humans some html/javascript code is injected. It does some work for detecting spambot and the result is sent back for verification instead of QuestyCaptcha answer. As an example for html/javascript code I made a random math function generator. Javascript is needed on spambot side to get the correct result for this function. Html/javascript code can be improved in future for detecting more complex spambots with javascript support. I pasted my ConfirmEdit/QuestyCaptcha patch here http://pastebin.com/4gVXR3GA It allows to have blank $wgCaptchaQuestions and to define optional $wgHTMLCaptchaQuestion function for more complex spambots. The main advantage is that you can stop spambots without defining any $wgCaptchaQuestions. Let me know if a spambot on your wiki can beat my simple javascript check.

Meshr (talk)19:52, 13 February 2015

Such tricks work at small scale, not big scale. You can submit your patch against Extension:SimpleAntiSpam.

As for the questions, that's what the new ReCaptcha does. There is a patch in ConfirmEdit.

Nemo23:33, 14 February 2015

My patch is against ConfirmEdit and QuestyCaptcha Extensions. It enables additional functionality in these Extensions that allows to write your own “new ReCaptcha” code. It stopped spam completely for me without any captchas/questions which I had before. The question is whether ConfirmEdit and QuestyCaptcha authors agree with these modifications.

Meshr (talk)20:22, 20 February 2015


Will Google's new No CAPTCHA reCAPTCHA API be supported?, 5 December 2014

Probably yes, when someone writes a patch. :)

Nemo19:43, 5 December 2014

I've just written one. Gotta just send it in now.

MisterLambda (talk)23:38, 15 December 2014

Great, since this seems to be a nice CAPTCHA solution.

[[kgh]] (talk)20:46, 16 December 2014

Wait for this patch to be applied. If you must have it, apply it now, though it's in review for a reason.

MisterLambda (talk)11:35, 17 December 2014

Cool, I just pinged someone who has a good insight into who may possibly deal with your commit, i.e. to work with you on improving it if there is the need to or to merge it for you into the repo. Excited to try it ... :)

[[kgh]] (talk)17:17, 18 December 2014

[Proposal] Use the same question on repeated requests

I am using ConfirmEdit with QuestyCaptcha to prevent spam account creation. However it was quite painful to watch a new user trying to register to my site, because he had to re-fill the form several times (password did not match, username already exists, forgot to re-type password) and each time he had to think about the answer of a different question.

To improve usability, I would suggest:

a) saving the selected question in the users' session and providing a link to "show a different question", b) or showing a different question only if it has been answered incorrectly. c) Yet a different approach would be to save the information "this is a human" into the session so that he only ever has to solve 1 captcha, even if the form reloads because of a different error.

For backwards compability, such behavior should be enabled via a config variable.

What do you think? I am willing to write a patch but am currently not sure which is the best approach.

Benjaminpick (talk)14:52, 27 January 2015

The approach followed in latest releases is to avoid reloading the form and the captcha at all if possible. Invalid username is now warned in-place, without submitting the form; something similar can be done for password mismatch; and there was agreement on wikitech-l that the password could be "remembered" upon form reload if the registration fails for other reasons.

Nemo15:24, 28 January 2015

Risk with $wgEnableWriteAPI?

What if the user has $wgEnableWriteAPI = true? Will spam account creation be possible?

See also Thread:Project:Support_desk/API:_Disable_selected_dangerous_write_actions

Subfader (talk)15:43, 25 January 2015

ConfirmEdit and other CAPTCHA implementations work with the API so if you depend on it for spam protection, it should continue to be protected.

You may also consider disabling account creation by

$wgAPIModules['createaccount'] = 'ApiDisabled';
MarkAHershberger(talk)17:41, 26 January 2015

Reverts on ConfirmEdit's QuestyCaptcha


I noticed you reverted my edits to the ConfirmEdit Extension and, of course, I don't like it so I'm here to propose other changes.

The first edit removed a Previous Edit I made and added: DO NOT use an exact copy of the dynamic questions from the link -- they've been cracked by spammers. However other dynamic questions in the style of the questions presented are highly effective.(Blue used to high light removed section). Since the new posted questions have not been cracked by spammers it's no longer a true statement. How 'bout we change it to:Do Not use an exact copy of the dynamic questions from the link; it makes it easier for spammers to crack if everyone has the same questions. However other dynamic questions in the style of the questions presented are highly effective. Or something along those lines?

Your other revert was on this add:

QuestyCaptcha as an Alternative to the ConfirmAccount Extension[edit | edit source]

As an alternative to ConfirmAccount you can use the QuestyCaptcha, in following manner:

DO NOT disclose the answer in the question and ask a question that only you have the answer to. Redirect users to a page to that contains an email form to ask to join your wiki. This would require a contact page be somewhere inside your wiki. You can add an email page with this extension:ContactPage, via the Widgets Extension using the Widget:Google Form, or in several other ways.

Example Questy Confirm Account Alternative:

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
'You can only join this wiki by entering the secret code below.To receive the secret code you must register via email on this page:<a href="ContactPage">Contact Page</a> ' => 'YourSecretonlytoldbyemail',
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );

Or alternatively if this is a small wiki community, and you do not wish "outside" users, you could only tell the secret answer to your selective community.

Small Community Example:

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";
$wgCaptchaClass = 'QuestyCaptcha';
$arr = array (
'This is a Members Only wiki. If you are a Member please enter the secret code below' => 'YourSecretcode',
foreach ( $arr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );

Now I can understand that maybe that section should not be included in the page about setting up Captcha, but I still think it makes a more effective way of access control then Extension:ConfirmAccount. And since ConfirmEdit is part of the core the ways I listed above are easier for most then ConfirmAccount. What about adding it as a subpage to the extension with one line addition on the front page of the extension?

Something like this:

(sentence above ending).... highly effective.

(Add) Questy Captcha can also be used as an Alternative to the Confirm Account Extension. See: [[Subpage Name]]

Anyways just my thoughts. All the best to you.

Christharp (talk)07:22, 17 November 2014

Hello, I moved your question here so that others can give their opinion too. From your reply it seems you didn't read my edit summary: «Doesn't matter that they've been changed, they mustn't be copied anyway. QuestyCaptcha is part of ConfirmEdit, not an alternative to it. And we don't recommend usage of ConfirmEdit as a password restriction to editing.»

I still don't understand your usage of the word "alternative" and your usage of QuestyCaptcha for unguessable answers is not prevalent across MediaWikis.

Nemo07:28, 17 November 2014


I did read your edit summary. Points:

  1. my suggested first new edit acknowledged your statement about them not being changed, but also acknowledged the truth that they no longer have been cracked.
  2. the second edit about using Questy as an alternative to ConfirmAccount -- is it can be used instead of the ConfirmAccount extension. The ConfirmAccount is a totally different extension for preventing account creation at will, allowing only sysops the power to confirm an account and add a user. Since, however, that requires downlaoding a new extension, adding a new database, etc., if the same functions can be achieved by other means, especially by using an extension that's part of the core it just makes sense. Basically ConfirmEdit makes the ConfirmAccount extension obsolete.

Sorry for my lack of clarity. All the best to you. I'll check out the talk page.

Christharp (talk)14:37, 17 November 2014

Ok. But ConfirmEdit is an extension, although it's true that ConfirmAccount is not bundled. Installing ConfirmEdit and then using it just for password protection of account creation (you don't use the password captcha for anything else, right?) might be a bad idea for performance too, if its code is called on every edit.

More importantly, having to ask a password before registration is a bad user experience in general. At that point, why couldn't you create them an account directly when asked? Or use InviteSignup to offer them the possibility?

I do see a use for your idea; but I'd like to understand better why you consider it the best solution for your case. We need its rationale to be explained well in documentation, or we'll mislead users.

Nemo07:29, 18 November 2014


The assumption that I think the ConfirmAccount is making is that wiki is set up to only allow editing from users (that assumption could be false). That assumption is the assumption I was assuming when I wrote the section -- forgetting some wikis allow editing by anonymous people.

The code would not be called anymore then it's currently called. It would be invoked when someone went to the sign in page to join, which is the same as it is when you Use ConfirmEdit now.

Bad User experience? Anymore then a Captcha? All Captchas are a bad user experience, but without them we would be flooded with spam bots. Recently on a wiki I own the Questy questions were cracked and I was flooded with something on the order of 1000 spam accounts before I stopped it. That wiki, unfortunately, is always open to the public so the answer I gave here doesn't work.Password or Captcha before registration suck, but both answer real world problems.

The problem with InviteSignup is the assumption that the wiki admin will know everyone who wishes to join. A previously unknown person could not join the wiki.

The section I wrote was for a detailed purpose (if not expressed clearly): showing how with ConfirmEdit Questy one could do what the ConfirmAccount does. If one can use a Core extension to get rid of the need of another extension, in this case ConfirmAccount, let's make life easier by showing everyone how. Yes, it's not the purpose that ConfirmEdit was designed for, but that just shows the flexibility of the code. My method takes someone a few minutes to set up, if that, while the alternative is loading another extension, creating tables, etc., which is just a waste of time.

Once again I suggest a very detailed subpage on the method & it's purpose (replacing another extension).

All the best. Hopefully I'm providing some clarity that my earlier writing didn't.

Christharp (talk)08:15, 18 November 2014

I would support keeping the information. Here are my main points:

  1. A user of MediaWiki can do what they want or need, whether it's supported or not.
  2. MediaWiki can choose whether to support a method. (If it is sensible of course)
  3. It depends on a wiki's scope whether to add information, guidelines, etc. on such information.

On (1), a MediaWiki user could use it as described, to use QuestyCaptcha as an editting password. I can think of a use-case for this, such as when a wiki-admin decides it is too cumbersome to create accounts by-hand and can simply distribute the key to a group of people who is supposed to edit. Of course, as User:Christharp said, it can provide ease to the wiki-admin, as a they can do what they want, the task should be to make what is sensible, simple? It's a clever idea, one that a clever wiki-admin could figure out for themselves. Ideas such as these should be told to others who may need such a feature, but haven't thought of using it for the purpose of restricting access.

On (2), MediaWiki (and along with it, the Wikimedia Foundation) has their own incentives, and concepts such as free information, open access, the wiki way etc. However, a wiki may have many uses, perhaps it is a private wiki for company-information, or a "personal" wiki which does not concern the rest of the public and is limited to members of a group. It my opinion that some of these incentives should be encouraged but never mandatory for a MediaWiki user.

On (3), MediaWiki.org's sole task is to document the usage of MediaWiki and related software. As this is a clever use that uses the software, it depends on whether they support it (point (2)), or whether they should distribute this information.

Nahiyan8 (talk)19:51, 20 November 2014

Allowing autoconfirmed to skip captcha not working

Originally posted in Manual talk:$wgGroupPermissions

Having implemented the QuestyCaptcha part of this extension, I tried to edit my LocalSettings in such a way that autoconfirmed users can avoid the new CAPTCHA. The change I added is as follows:

$wgAutoConfirmAge = 86400;
$wgAutoConfirmCount = 10;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;

This should give a user autoconfirmed status after they've made ten edits and their account is 24 hours old. The third line, however, does not seem to take effect, as the skipcaptcha right is not showing up for autoconfirmed users in Special:ListGroupRights. When I misspelled the right's name, however, it showed up for the autoconfirmed group (albeit useless, since misspelled). Spelled correctly, it's missing from ListGroupRights.

Schiffy (talk)19:24, 11 November 2014

Are you adding these lines after the line where you include ConfirmEdit?

Nemo17:22, 12 November 2014

That would explain it. Thanks.

Schiffy (talk)20:02, 12 November 2014

The current version of this extension is not compatible with 1.20

That includes the version of the extension that is bundled with 1.20.

If you set $wgCaptchaClass = 'FancyCaptcha' in your LocalSettings.php you will get an HTTP 500 error if you attempt any operation involving a captcha such as creating a new account. If you look in FancyCapthca.class.php you will see it includes a call to getWikiId. The FSFileBackend class does not have that method in 1.20, although the trunk version does. The Apache error_log confirms that the failure is due to an attempt by FancyCaptcha.class.php to call FSFileBackend::getWikiId.

I am currently using the 1.19 version of this extension with 1.20 without any problems.

Prh47bridge (talk)12:44, 23 November 2012

I can't seem to find a working version. I have tried downloading the latest version and 1.19 in the ConfirmEdit page and it does not work with mediaiki 1.20. Any captcha option gives me a 500 error., 4 March 2013

FancyCaptcha does not work for me in MediaWiki 1.20.3. It says on text submit

 Internal error
 [41207728] 2013-03-16 07:01:45: Fatal exception of type MWException

Very sad... Can somebody fix it. I muss FancyCaptcha, and not a php developer :-(((

Nataraj (talk)06:59, 16 March 2013

Probably the same bug as bugzilla:46132, can you comment there please?

Nemo07:32, 16 March 2013

I do not know...

If you can tell me how to see MediaWiki or php Error log or something like this, I can tell you more about this error. For now only one thing I have is that message it browser. Since MediaWiki and other php scripts does not use common web server error log to report errors, I really do not know how to debug it...

Nataraj (talk)07:02, 17 March 2013

I found the source of the problem: the source was me.

For some unknown reason in previous installation I've configured FancyCaptcha right in the extensions/ConfirmEdit/FancyCaptcha.php file and while upgrading I've replaced all my custom configuration with a default one. So nothing worked.

So there is no bug in FancyCaptcha in my case (what about Prh47bridge's case I do not know), but there is a wish requests

1. to add some more diagnostics in cases when capcha files are missing or wrong

2. May be do some sanity check on initialization, i.e. check that capcha dis exists or something, so when you run media wiki on wrong configuration you will get warning even when you are not editing anything. May be add this check to upgrade script if it is possible...

Nataraj (talk)07:09, 19 March 2013

I'm getting the same issue:

  [74137648] 2014-11-06 01:04:27: Fatal exception of type MWException

When I set "$wgShowExceptionDetails = true;" in LocalSettings.php, it gets expanded to:

  [3fec957a] /index.php?title=Special:UserLogin&returnto=Main+Page&type=signup Exception from line 161 of   
  /example.com/htdocs/extensions/ConfirmEdit/FancyCaptcha.class.php: Ran out of captcha images

For previous people participating in this thread, a similar error turned out to be wrong location of the images. Here, it's not the case:

  $wgCaptchaDirectory = "/tmp/captcha";
  # ls /tmp/captcha/
  image_0c30eb32_909fdf4961658cbf.png  image_4b5777ea_02ea373d0eb70a08.png  image_7c662fed_bb479185e2e52234.png 

Any ideas what can be wrong? This is with MediaWiki 1.23.6., 6 November 2014

I'm using the question setting and it seems cause a 500 error on the account creation page.


Are you human?

This is not working on my MW 1.23.2 installation:

What can be the reason ?

hollosch (talk)17:50, 28 October 2014

This extension currently does not support this since this required change has not been merged yet. Probably you could do a manual patch to the code as see how it goes from there.

[[kgh]] (talk)13:20, 29 October 2014

New users and URLs....

The one thing that would distract spam is to prevent them from publishing their URLs. There are several ways to accomplish this, but for new users, there needs to be an extra hook for URLs. This hook shouldn't be a captcha but an approval process with other higher ranking members. It could be as simple as a moderated page or as complex as prompting ranking members to approve randomly using the message feature. If there was a MW option, I would even be okay with blocking URLs until new users are promoted or request the URL to be added to a whitelist, we just need MW to add the URL hook to the permissions.

Skunark (talk)03:19, 21 October 2014

Sounds like a feature request for Extension:FlaggedRevs.

Nemo05:20, 22 October 2014

Make Captcha more visible to users

When using QuestyCaptcha the form appears when the user has done changes and is on the same page (edit). The user is not aware that a captcha must be filled. Moving the Captcha to the bottom of the page or highlight it by css would change the problem., 8 April 2013

I agree, this is causing confusion for our users on the Create Account page, as well as the Edit page as described above., 16 October 2014

The issues is known but the solution is not trivial, because MediaWiki can't always know beforehand whether the edit will need a captcha (e.g. whether it will add an URL). In recent versions, Special:UserLogin shows the captcha from the start when required for registering.

Nemo21:46, 16 October 2014

What is Special:Version

I am trying to set this up and I have no idea what Special:version, 12 October 2014

A page on your wiki, like Special:Version here.

Nemo06:28, 13 October 2014

Documenting Asirra

Nemo bis believes that the extension should continue to document Asirra even though it closes down permanently as of today [1]. He thinks that this not functional module should be documented until it was removed from the code base. I do not think that this is a good idea. However, I just opened a bug for removing Asirra integration from the extension: [2].

[1] http://research.microsoft.com/en-us/um/redmond/projects/asirra/

[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=71712

[[kgh]] (talk)18:54, 6 October 2014

Thanks for filing.

Nemo19:37, 6 October 2014

Asirra configuration parameters

I have Asirra working correctly but I am attempting to use its $wgAsirraEnlargedPositionparameter to have the pop up images displayed to the right. Have tried in LocalSettings to no avail — I don't know PHP. What is the correct language here? Thanks., 31 July 2014
First page
First page
Previous page
Previous page
Last page
Last page