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)

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 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?

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;

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

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)

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)