Extension talk:ConfirmEdit/LQT Archive 1

Problem Installing PHP ERROR
When I try to install the extension it causes the entire wiki to fail and I get a blank screen MediaWiki: 1.6.10 PHP: 4.3.9 (apache2handler) MySQL: 4.1.20

the error message is

[client 79.181.107.14] PHP Warning: main: URL file-access is disabled in the server configuration in

LocalSettings.php on line 132 [client 79.181.107.14] PHP Warning: main

(/extensions/ConfirmEdit/ConfirmEdit.php): failed to open stream: no suitable

wrapper could be found in LocalSettings.php on line 132 [client 79.181.107.14] PHP Fatal error: main: Failed opening required

'/extensions/ConfirmEdit/ConfirmEdit.php'

in /home/sites/worker/worker_tests/wiki_dev/LocalSettings.php on line 132

Locale setup problem
How can I set english locale for ConfirmEdit?

When I setup ConfirmEdit r19995, then it works with messages like japanise.

Workaround
CofirmEdit seems to write messages in the language that is last defined in ConfirmEdit.i18n.php. Hence, I added the following line to the end of this file:

$wgConfirmEditMessages['last'] = $wgConfirmEditMessages['en'];

Now all messages are in English. I've tested this with MediaWiki 1.6.10.

However, this does not fix the original issue, that ConfirmEdit and MediaWiki use different locales. Any ideas?

13:58, 30 October 2007 (UTC)

It looks like yet another conflict between ConfigEdit version and MediaWiki version. Looking at http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_10/extensions/ConfirmEdit revision 27741, ConfigEdit.php, line 156-157, you can see that ConfigEdit tries to add all its i18n'ed messages to a cache. It tries to tell MediaWiki which messages are for which locale by using the second argument. But if you look at MediaWiki 1.6.10, includes/MessageCache.php, line 485, addMessages takes only 1 argument. I fixed this by having ConfirmEdit add only the current locale to the message cache:

function ceSetup { # Add messages global $wgMessageCache, $wgConfirmEditMessages, $wgLanguageCode; $wgMessageCache->addMessages( $wgConfirmEditMessages[$wgLanguageCode] );

Debian Etch problems
Debian Stable (AKA Etch) uses MediaWiki 1.7.1 and adding this extension returns Fatal error: Call to undefined function wfMemcKey in /var/lib/mediawiki1.7/extensions/ConfirmEdit/ConfirmEdit.php on line 358

I think the compatibility with versions is out of date on the install page??

I upgraded to mediawiki1.10  1.10.2-1 and things work now. Do not use the Debian auto upgrade at this date (10/13/07) - has issues. Instead create a new LocalSettings.php via http://www.myserver.org/mediawiki/config/index.php Then run meld and see the differences between your old and new LocalSettings.php

Installing?
How do i install the ConfirmEdit extention?

--84.179.34.46 23:29, 21 February 2006 (UTC)
 * The installation directions are there, copy the files and include the declaration. --Kenny5 02:10, 12 April 2007 (UTC)

I noticed that it was not matching any links, so I added this patch: http://paulproteus.acm.jhu.edu/tmp/omg

I believe it's due to changes in the underlying MediaWiki.


 * Yes, it was a regression bug and was fixed in the 18349 revision of ConfirmEdit.php. Vocaro 11:04, 15 December 2006 (UTC)

-- Asheesh Laroia, 2006-11-24.

I can't install ConfirmEdit
How I can install only ConfirmEdit? I don't see any links. Kirill
 * Hmm... Have you read the page? If you want to have it installed on a Wikimedia project, open a bug at http://bugzilla.wikimedia.org --.anaconda 16:42, 25 December 2006 (UTC)
 * Sorry. I don't understand, what this extansionn do. I think that moderator can approve change articles. But I see - this simple check of work people, not spam-bot. :(

I tried installing ConfirmEdit as per the instructions on a Wikimedia 1.9.3 installation. However I end up with a blank page with no errors. commenting out the 'require_once' line in the localsettings file brings the site back to life. Any idea how to allow the site to show script errors so I can see what's going wrong? April 2, 2007. Todd
 * Never mind - forgot to install the internationalization file.

Special Pages Information
It would be nice to have some mention of how to create the Special Pages files for this extension, and perhaps a sample file.

skipcaptcha by IP address range?
Anyone know of a quick way to modify this extension to allow IPs in a specific range to skip the captcha? &#x2014;Alxndr&#x00a0;(t) 00:16, 14 February 2007 (UTC)
 * There's an IP whitelist in ConfirmEdit.php. Just look at the comments before $wgCaptchaWhitelistIP.  Put this whitelist info into LocalSettings.php after the require_once(...) and you should be good to go. Michael Daly 18:48, 8 July 2007 (UTC)

ERROR
Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9

Warning: Cannot modify header information - headers already sent by (output started at /home/codev/public_html/en/w/extensions/ConfirmEdit/ConfirmEdit.i18n.php:516) in /home/codev/public_html/en/w/includes/WebResponse.php on line 9
 * It works for me in 1.9.3. Try disabling all other extensions and see what happens. --Kenny5 02:08, 12 April 2007 (UTC)

tested with wikimedia 1.9.3 and not displaying any captcha
thanks for checking... cedric walter from == http://wiki.waltercedric.com
 * It works for me, in 1.9.3. --Kenny5 02:12, 12 April 2007 (UTC)

I'm also not seeing any captcha in 1.9.3. I've tried accessing the .png files directly, and that works fine. Accessing them via the generated Special: URL doesn't, though. I get this error message instead:
 * The image “http://www.qualtrics.com/wiki/index.php?title=Special:Captcha/image&wpCaptchaId=405875869” cannot be displayed, because it contains errors.

ConfirmEdit is the only extension that's installed so far, and it's set up to use FancyCaptcha.
 * AHA! I think I've found the problem, at least for my site.  Apache is applying mod_deflate when I request the image via the Special:Captcha URL, probably because the actual request is for a PHP script and not directly for an image.  Now, I just need to find out how to turn off mod_deflate for image requests without turning it off for everything else...

Install question
I've been working on an upgrade from 1.4.7 to 1.6.10 (the best I can do without PHP5), and have run into a couple of things with this extension.

First, the captcha images I created don't render in the browser on signup. Here's example source:



I'm having the same problem with images not being rendered. It looks like the Captcha special page is not created at all, but I still can't figure out why not.

I know the extension is seeing the images because if I change the path it gives an error about not finding them.

Second, the default language is Slovak (which is the last one in the FancyCaptcha.i18n.php source). Is there a quick variable I can change to fix this?

To fix the language displayed, move the desired language to the end of the FancyCaptcha.il8n.php file so it is the last one added to the array. For some reason (as you've discovered) the last language is displayed, despite locale settings.

Thanks

Captcha trigger for uploads?
Is there or can a trigger be created for when someone attempts to upload a file? I've had a few vandals replace images on my wiki and ConfirmEdit has definitely slowed them down (thank you!), but the captcha doesn't come up when you upload or replace an image file.

Doesn't work
The development version as of today just gives me this:

Parse error: syntax error, unexpected T_BOOLEAN_AND, expecting '(' in /home/pclos/public_html/docs/extensions/captcha/ConfirmEdit.php on line 308

Sy Ali 02:05, 14 May 2007 (UTC)

Placing empty parenthesis: "" after each LoginForm::WRONGPASS seems to fix it:

< $retval = LoginForm::WRONG_PASS;

> $retval = LoginForm::WRONG_PASS;

Does Nothing
Installed the SVN version (as per the link given elsewhere here) for Wiki version 1.6.10, PHP4. The include line is in the LocalSettings file, I've installed ExtensionFunctions.php in the /extensions directory, the ConfirmEdit files are in a ConfirmEdit directory.

No errors displayed or logged, no captcha displayed, accepts edits for non-logged in users without complaint. It does absolutely nothing.


 * Got same problem

T_BOOLEAN_AND
This problem still exists as of July 1st 2007.


 * as of 12 June, I also get the error:
 * Parse error: syntax error, unexpected T_BOOLEAN_AND, expecting '(' in /home/wiki/public_html/w/extensions/ConfirmEdit/ConfirmEdit.php on line 320
 * Aussiepete 05:58, 12 June 2007 (UTC)

wfMemcKey
After downloading and installing latest version on MW 1.7.3, Special:Userlogin returns:

Fatal error: Call to undefined function wfMemcKey in /web/domain.org/extensions/ConfirmEdit/ConfirmEdit.php on line 348

--MatthewBurton 04:41, 4 June 2007 (UTC)


 * any solution for this?
 * Mdale 18:34, 11 June 2007 (UTC)


 * Installed an older version. It uses arithmetic problems instead of captchas, but it's blocked all spam so far. The language in the PHP files reflect captchas, not math, so be sure to change it so your users aren't confused. - MatthewBurton 04:34, 17 June 2007 (UTC)


 * This is probably due to the script trying to use $wgMemc for storing bad login info. Usually, $wgCaptchaStorageClass decides if cookies or $wgMemc is used for storage, but a bug in the script makes it attempt to use $wgMemc even when you've chosen cookies for storage. I solved this crudely by commenting out all things regarding bad login counting. - Ymgve

new $wgCaptchaClass
My wiki (1.6.6) crashes on this line : $wgCaptcha = new $wgCaptchaClass;

Any ideas? Am I missing additional files? If so, please state that one has to use this or that version SPECIFICALLY. I am at a loss here.

Mr.Mouse

same but different..... new $wgCaptchaClass
Mr. Mouse, I'm having the same trouble with My wiki (1.12.0) it is also not working at : $wgCaptcha = new $wgCaptchaClass; ...this is line 9 I'm just waiting for a spam attack! -Will --Willjermuk 15:05, 21 June 2008 (UTC)

Right is there another place can place this post to get some help or suggestions on this issue, haven't heard from anyone in a week. Thanks Will --Willjermuk 14:55, 28 June 2008 (UTC)

Another install question
The extension kills the site when I plug it into LocalSettings.php. I workaround that by replacing $IP with the real address, but the extension doesn't work. Site's called videoville.org, running on MediaWiki 1.6.10. Any help is totally rad. --24.208.181.227 21:15, 7 July 2007 (UTC)

I get the same result. MediaWiki 1.6.10, PHP 4.3.9, MSQL 4.1.20. It looks like one of the early install problems posts rectified it simply by making sure the internationalization file was present. Both files have always been present for me. I've tried numerous mods to the scripts with no luck. Bummer, looked like and awesome extension.--129.74.153.198 19:14, 23 August 2007 (UTC)


 * $IP should be your install path and not the IP address. By dumping an IP address in there you just causing the extension to fail to load.  J.smith 19:49, 13 December 2007 (UTC)

captcha image generation
Does anyone have any better captcha image generation script that works with FancyCaptcha or know how to modify the image generation on captcha.py? The images I generated are too unreadable to be useful. See http://www.zuul.org/~zuul/image_ff988f48_3e1f52eb9fe90987.png I'm using a simple sans serif truetype font with python-2.4.3p0 and PIL py-Imaging-1.1.5p0 on OpenBSD 4.0. Please respond to me at http://en.wikipedia.org/User:Sborsody. Thanks.


 * Well it looks like you should use a bold font when generating the images. I tried Arial Black and other bold like Tahoma Bold and it looks a lot better. --SBorsody


 * The best Captcha I've seen involves identifying pictures instead of letters/numbers. A fire truck, a football, a duck, etc.  Basic images that any human could recognize.  As far as I know, no bot has cracked it yet.  208.201.146.137 18:35, 27 September 2007 (UTC)

Suggestion: Make number of links configurable
Hi, would be a nice feature to be able to configure the number of links in an edit needed for the captcha to be thrown. So when I add only one link I don't get harassed by the captcha. ;-)

I might look into it myself when I have more time... --Matsch 19:25, 23 August 2007 (UTC)

Conflicting with SpamBlacklist Extension
Hi, it seems this extension is conflicting with the SpamBlacklist Extension (link). On creation of a new page (where a captcha is thrown) i get the following error:

Warning: Missing argument 4 for wfspamblacklistvalidate in /home/www/web125/html/rockinchina/wiki/extensions/SpamBlackList/SpamBlacklist.php on line 67


 * MediaWiki: 1.6.8, PHP: 4.4.6

Cross posting to: Extension_talk:SpamBlacklist -- Matsch 20:07, 23 August 2007 (UTC)

Another Captcha option?
My host says I have python available, but I can't dump files into the directory myself. They also said "the server supports the CAPTCHA php pear modules. You can use these modules to generate CAPTCHA." Is there a way to use what's already there with MediaWiki?--Azurite 05:06, 4 September 2007 (UTC)
 * If you can, use reCAPTCHA. It doesn't require any python libraries. --MZMcBride 00:47, 18 September 2007 (UTC)

Suggestion: Captcha for new IPs
This extension has been phenomenally successful in stopping spam on our site, but there's still one kind of bot that gets through. It doesn't add spam, all it does is insert nonsense words onto the beginnings of hundreds of pages, changing IPs regularly to avoid blocks. It's obviously a bot gone haywire, but I've come up with a possible solution to stop it. Have an option that requires Captchas for the first 5 edits from any new IPs. Include a note on the page saying "This will only be required for your first five edits", so as to avoid scaring away legit editors. This would stop about 99% of the junk edits on our site, and I know this bot affects lots of other wikis as well. I'm useless at PHP, so I wouldn't know where to begin with this, but I'm sure it can't be that complicated to set up for someone who knows what they're doing. A good idea? 70.119.42.36 17:14, 9 November 2007 (UTC)

undefined function wfLoadExtensionMessages
When attempting to install on a 1.10.1 wiki version, we're getting the following error:

PHP Fatal error: Call to undefined function wfLoadExtensionMessages in /opt/****/httpd/****.org/html/extensions/ConfirmEdit/ConfirmEdit_body.php on line 9

I haven't been able to find any references to this specific error and was wondering if anyone had any advice? Thanks in advance.
 * I have got the same problem trying to install the SimpleCaptcha Version. My current impression is that SimpleCaptcha is not supported and it should be used together with te FancyCaptcha addon. I found the following problems:
 * You need a third file ConfirmEdit_body.php and require_once it in the LocalSettings.php. You can get this file using the given svn checkout.
 * My version of PHP complains about a missing "ConfirmEditHooks::confirmEdit". The cause seems to be that the Hook-Mechanism interprets this as a function name containing colons rather than static function confirmEdit from class ConfirmEditHooks. The $wgHooks assignment should probably be in the form array('ConfirmEditHooks', name of the static function) to conform with PHPs callback pseudotype.
 * After commenting out the calls to wfLoadExtensionMessages SimpleCaptcha seemed to work except that the MediaWiki software showed something like names of the message handles rather than the message contents contained in ConfirmEdit.i18n.php. I am still trying to find some way to display these contents.
 * --09:20, 17 November 2007 (UTC)

My guess is that you are using the latest version of this extension, which might be using functions, like wfLoadExtensionMessages, which did not exist in 1.10, but where introduced in 1.11 or even only 1.12alpha. The 1.10 branch of ConfirmEdit can be found here: http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_10/extensions/ConfirmEdit/ -- Duesentrieb ⇌ 15:53, 17 November 2007 (UTC)

Thank you for the tip - version mismatch seems to be the actual problem. I spent a lot of time analyzing problems related to not working combinations of Mediwiki-Software and ConfirmEdit versions. I think to have found an error like 11082 in includes/Hooks.php, line 106, MediaWiki 1.9.3. Therefore I put a table summaring my experience and hoping that it will fill up.


 * -- Albrecht Müller 18:55, 18 November 2007 (UTC)

"warning First argumented is expected to be a valid callback..."
I've attempted to add the latest ConfirmEdit (rev 27622) to a mediawiki 1.6.10 (which I'm limited to as host, sf.net, runs PHP 4.3.10). However, I now get this warning on the top of some pages (those that use the extension, it seems):

Warning: call_user_func_array: First argumented is expected to be a valid callback, 'ConfirmEditHooks::injectUserLogin' was given in mediawiki-1.6.10/includes/Hooks.php on line 114

...and no captcha. I'm not familiar with PHP, so this stumps me. Any ideas?

john --19-11-2007

Ah, I missed the note about PHP4 in the main page. Anyone know precisely which version in SVN I should try using?

john --20-11-2007

OK, some updates and version bisecting later, I can tell you the last vanilla version to work with PHP4 is SVN rev 21970. Useful for those people stuck on a PHP4 host (sourceforge, I'm looking at you)

john --22-11-2007
 * I am having this same problem with the same specs as you. Thanks for the rev #. --HenryWS 04:33, 26 November 2007 (UTC)


 * My Mediawiki says on Special:Version - MediaWiki: 1.6.7 and PHP: 5.1.6-1 (cgi-fcgi) -, however, I get the same error as you. -- JanCK 10:00, 19 September 2008 (UTC)


 * I've now also installed rev 21970. It works. But I needed to patch the i18n file with the workaround described here: http://www.mediawiki.org/wiki/Extension_talk:ConfirmEdit#Locale_setup_problem and it took me 2minutes (which is more than I expected) to find the link: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/?pathrev=21970 to rev 21970 and I still don't know how to download all of the files (for example as a gz) instead of downloading every file on its own. -- JanCK 10:35, 19 September 2008 (UTC)

Invalid argument supplied for foreach in/home/stephen/public_html/usmoi/wiki/includes/MessageCache.php on line486
This is the error I am getting on my wiki. Here is my ConfirmEdit.php. I am using MW 1.6.10, PHP 4.4.7. Thanks. --HenryWS 20:46, 27 November 2007 (UTC).

Blank screen after installing confirmedit
I installed confirmedit, but now I can't make any updates anymore. After I press save on any edit page I'm getting a blank page. No error message whatsoever. I'm using mediawiki 1.11 and the newest cofirmedit plugin (jan 2008). Does anybody have any idea where to look?

Ronald - 06-01-2008

Same...

Thomas -05.02.08

Are there any screenshots available?
It would be nice to have a look on this captcha implementation before you decide to install it.

It is the ConfirmEdit standalone. One Shoot ConfirmEdit --Neoshinji 06:45, 2 January 2009 (UTC)

Can't find file/Don't Understand Directions
Where am I supposed to find the fonts files and word files? I don't see them in the Imaging folder I downloaded.

Also, I'm new to python - when you say run...

... do you just mean to input the correct values into captcha.py and save it?

it works:-)
hallo everyone, i've installed the extension. but there is nothing to see.. http://ol-wiki.de is the wiki.

here you can try it: http://ol-wiki.de/index.php?title=Testseite

this is mediawiki 1.6.6.

i've installed it as i should. (upload the files and include it in the localsettings)

please help me:-) 84.189.126.205 21:26, 23 March 2008 (UTC)


 * Works fine for me - when I try to add a URL to thatpage, it triggers. If you want it on all edits, set $wgCaptchaTriggers['edit'] = true; as the manual sais. -- Duesentrieb ⇌ 09:27, 24 March 2008 (UTC)
 * ups^^. my english is not the best. so i thought always there is the quastion. not only when i'm posting urls.  so thank u very much for the help and the extension!! 84.189.110.25 20:53, 24 March 2008 (UTC)

Place captcha on first edit page
Hello, I want to use this extension on every edit, so it doesn't matter what the user typed in. Therefore I would like to have the captcha already on the first edit page right after clicking on edit, maybe just above the save button. Is there an option for this? --Jorges 17:20, 22 April 2008 (UTC)


 * I'd also like to know this. --Naught101 00:35, 6 November 2008 (UTC)

Captcha anonymous edits
I had a bot posting quite embarrassing stuff - no links but just very inappropriate language. So I've added captcha on all edit's by anonymous users.

$wgCaptchaTriggers['anonymous'] = true; .... function shouldCheck( &$editPage, $newtext, $section ) { .....         if( $this->captchaTriggers( $editPage, 'anonymous')) { if ($wgUser->isLoggedIn ) { return false; wfDebug( "ConfirmEdit: user is logged in, skipping captcha\n" ); }                       wfDebug( "ConfirmEdit: anonymous user trying to edit - showing captcha \n" ); return true; }

Move the Link
When the confirmedit is triggered, we only do it for external links, the more info link is causing problems in the sentences: "Your edit includes new external links. To help protect against automated spam, please enter the words that appear below in the box (more info)". We are using the simple algebra captcha and we want to stay with that. But on some resolutions when the page is still loading, the user clicks on the box but the toolbar then loads and the click goes to the more info link instead. Some browsers don't save POSTDATA and so they have lost all their changes. Is it at all possible to move the link to another part in these sentences or to remove the link altogether?--Mjr162006 16:51, 21 June 2008 (UTC)


 * Is anyone going to answer?--Mjr162006 13:20, 25 June 2008 (UTC)


 * You could alter the message to make it longer or shorter, so the link would be less likely to appear right at that spot. You can find all editable UI messages at Special:Allmessages; it should be MediaWiki:Captcha-addurl or a related one specified by the captcha variant you're using. --brion 19:48, 4 July 2008 (UTC)

Thanks a lot. We've got it fixed now.--Mjr162006 21:26, 5 July 2008 (UTC)

Error logged when ConfirmEdit Hook is called
Hi,

I am using mediawiki 1.6.8 and ConfirmEdit trunk-r37988 version. I have created the images as explained in the page. However, when ConfirmEdit is called following error is logged and image doesn't come.

PHP Warning: call_user_func_array [function.call-user-func-array]: First argument is expected to be a valid callback, 'ConfirmEditHooks::injectUserCreate'

Please help

Thanks, Mohan Cheema

Redeclaration error / on MediaWiki 1.12.0 - including solution
I tried to install ConfirmEdit on MediaWiki 1.12.0, and got problem.

Error message was like this(not exatly same). => redeclare the class SimpleCaptcha

I solved this problem by adding an "if" statement at every declaration of classes, like below.

(class declarations are in "ConfirmEdit_body.php")

Plus, a function "confirmEditMerged" is needed for editing page, so I added this function that just returns true on SimpleCaptcha(and whatever captcha class you want to use) class.

Now my wiki works well with working above.

- inornate

wgCaptchaBadLoginExpiration Not Working?
Hi, I am using Mediawiki 1.13.2 with ConfimEdit, badlogin set to True and CACHE_DB enabled. I am getting the expected Captcha prompt on user login failures but I have the wgCaptchaBadLoginExpiration set to 9999 * 60, and the login prompt (with Captcha prompt) still immediately returns to the screen upon failure. I am expecting it to delay to 9999*60 seconds. What am I missing? Thanks!


 * You may be misunderstanding $wgCaptchaBadLoginExpiration. Until $wgCaptchaBadLoginExpiration seconds have passed after $wgCaptchaBadLoginAttempts from an IP, that IP will have not be able to log in without solving a CAPTCHA.  —Emufarmers(T 21:11, 6 November 2008 (UTC)


 * This is very helpful thanks. I'm trying to prevent bots potentially brute force attacking my mediawiki user accounts. Adding Captcha's will help prevent attacks, but I would also like to automatically ban IP's that fail to login a certain amount of times. Can this extension help with that or do you have any idea of any that could? Thanks! --Timvaverchak 15:33, 12 November 2008 (UTC)

Bad login
Does Bad login detection only work if caching is enabled? It doesnt work on my wiki. --Kenny5 15:10, 17 December 2008 (UTC)

Restricting $wgCaptchaTriggers to certain user groups
I'd like to restrict the 'edit' and 'create' triggers to anonymous users, while registered users should only have to solve the CAPTCHA if they add new external links. Any idea how I could accomplish this? -Wormbo 18:50, 9 January 2009 (UTC)

Mediawiki version 13.4
With the latest Mediawiki version on my site under construction Eco-Diving.Org I get the following Fatal error: Cannot redeclare class SimpleCaptcha in /home1/twofouap/public_html/eco-diving/extensions/ConfirmEdit/ConfirmEdit_body.php on line 66

....Anybody any idea what might be wrong? Thanks in advance --Horst Salzwedel 23:08, 16 February 2009 (UTC)
 * Are you certain you're using the 1.13 version? At Special:ExtensionDistributor/ConfirmEdit, select "1.13.x" from the drop-down and install that instead of whatever you're using now. —Simetrical (talk • contribs) 00:04, 17 February 2009 (UTC)

MediaWiki version 1.14.0
I get the following error when I install this: Fatal error: Cannot redeclare class SimpleCaptcha in /home/content/w/a/t/watc1/html/extensions/ConfirmEdit/ConfirmEdit_body.php on line 66

Any idea why? I am using the correct version.

I've been getting a lot of bot/spams and the recaptcha just isn't working like it should. I need something that works! Help!

MediaWiki 1.15.0 and PHP 5.3.0
The extension doesn't seem to work on the newest MediaWiki Version (1.15.0) and the newest PHP Version (5.3.0) - this is the error I get: Parameter 1 to ConfirmEditHooks::confirmEditMerged expected to be a reference

Please fix that. --Regexpert 23:30, 9 July 2009 (UTC)


 * Use the 1.15.x version of the extension. —Emufarmers(T 13:02, 11 July 2009 (UTC)


 * Choosing the 1.15.x release results in the svn error: "Working copy '/mnt/upload5/private/ExtensionDistributor/mw-snapshot/branches/REL1_15/extensions' locked". Cannot proceed :( 66.162.32.234 18:16, 21 July 2009 (UTC)


 * I can confirm that this extension doesn't work with MediaWiki 1.15 and PHP 5.3.0. When I want to edit an article I get an internal error:

''Detected bug in an extension! Hook ConfirmEditHooks::confirmEditMerged failed to return a value; should return true to continue hook processing or false to abort. Backtrace:
 * 1) 0 /users/mydomain/www/wiki/includes/EditPage.php(956): wfRunHooks('EditFilterMerge...', Array)
 * 2) 1 /users/mydomain/www/wiki/includes/EditPage.php(2483): EditPage->internalAttemptSave(false, false)
 * 3) 2 /users/mydomain/www/wiki/includes/EditPage.php(449): EditPage->attemptSave
 * 4) 3 /users/mydomain/www/wiki/includes/EditPage.php(340): EditPage->edit
 * 5) 4 /users/mydomain/www/wiki/includes/Wiki.php(510): EditPage->submit
 * 6) 5 /users/mydomain/www/wiki/includes/Wiki.php(63): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 7) 6 /users/mydomain/www/wiki/index.php(116): MediaWiki->initialize(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
 * 8) 7 {main}''

Can that be fixed? --Plati123 20:23, 30 July 2009 (UTC)
 * I have the same problem. Is there anything that can be done with this? Happy Joe 16:41, 20 August 2009 (UTC)
 * I also have the problem! I think it is a ConfirmEdit bug!
 * same here, mediawiki 1.13.0 and I think php 5.3.0 :/ 195.240.173.128 14:08, 1 February 2010 (UTC)


 * You are using an old version of the extension. Use the version appropiate for your mediawiki version. Special:ExtensionDistributor/ConfirmEdit. And if you have an old 1.13 wiki, update it. - Platonides 21:18, 3 February 2010 (UTC)
 * upgraded to MediaWiki 1.15.1 and the latest ConfirmEdit release. Special:Version. Still the same problem. 195.240.173.128 10:05, 4 February 2010 (UTC)

Page blanking
It seems StrategyWiki was hit by a wave of page-blanking bots that replace entire sections with a single line of text. I suggest adding a new captcha trigger based on excessive shrinkage of a page (e.g. 10+ lines removed), since this will stop most of these bots that operate on open proxies. This is useful for sites that don't explicitly block Tor nodes or other open proxies, while catching any bots that try exploiting them. The catch is that it may snag a few legitimate edits... --Sigma 7 14:29, 15 September 2009 (UTC)
 * You can captcha all edits. 212.179.134.33 16:10, 15 September 2009 (UTC)


 * Use AbuseFilter (see bug 18110). —Emufarmers(T 15:57, 16 September 2009 (UTC)

Doesn't work
Hi, i installed confirmedit on my debian lenny server. But it doesn't work for me. No captcha showed. My wiki version: MediaWiki 	1.15.1 PHP 	5.2.6-1+lenny3 (apache2handler) MySQL 	5.0.51a-24+lenny1-log In version special page, i don't find any ConfirmEdit entry.
 * Have you read the installation instructions? If you don't see it on Special:Version, it's not installed properly. Max Semenik 09:06, 30 November 2009 (UTC)

A note about php.ini
Captcha works great for us at the Venciclopedia. Spam has been reduced to zero since we installed it.

Today, however, we changed our php.ini settings and set the session.save_path to a path that produced the following error.

''PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0''

Captcha didn't work until this was fixed. It kept asking for yet another addition. Hope this info is good for something.--Mark 10:09, 24 December 2009 (UTC)