Extension talk:ConfirmEdit/LQT Archive 1

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)

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