Hello community,
my testing shows
a) Bigo Catcha does
not conflict with PHP safe mode (using current XAMPP)
b) Bigo Catcha does
not conflict with SEF (at least with Joomla! 1.5.3)
c) Bigo Catcha has
no special problems with IE7, Opera 9.27, Safari 3.1.1 (and probably IE6 neither, though who is that dumb nowadays (self::answer(JText::_('probably over 90% of those damn users');))
d) What will cause problems, and where we can do nothing but inform the users, is Cookie blocking and settings to suppress GIF animation.
e) There's templates out there which neglect to pass on entries from the message queue. Those here experiencing just a drop back to the form when they submit their captcha incorrectly (or even with a correct one) might want to check whether the main index.php in their template has a "<jdoc:include type="message" />" or not.
Cookies: No, as far as I can tell, Joomla! does not have the capability to maintain a session without cookies (which one would implement using GUIDs in a return URL). For users blocking Cookies, the experience will often be frustrating. I have yet to look into the code to determine if a simple but reliable test might enable a specific message in this case. Probably, the 'word' request var comes back as null or an empty string, we might want to return a special message for that case.
Animation settings: I believe it to be a widely adopted practice with Internet Explorer users to disable animation. After all, lacking extensions like noscript or adblock it's one of the very few things they can do to ease headaches. With firefox, a similar setting is possible, though as far as I know not through the standard options dialog. I'll try a list: IE7:
Alt(

),Extras,Internet Options,Advanced,scroll down to Multimedia,First entry. FF2: go to url about:config, select setting image.animation_mode, 'normal' is OK, the others are as far as I remember 'once' and 'none'. Safari: no idea. Opera: Tools,Preferences,Advanced,Content,first entry.
JavaScript: Disabling JS will not render a captcha-using form inoperable, if that form was JS-blocking-tolerant before. Still, one can do much using JS to ease user experience (hints: hasTip class, the validator built into Joomla, allow requesting a fresh captcha without a postback,...)
To all potential admins who might want to activate captcha usage by just unzipping one of the patch archives: I urge you to learn to 'think for yourself'. As far as I can tell, the one I checked is
not derived from the 1.5.3 codebase, so at least do yourself the favor to merge the patch with the current code using one of the many diff/merge tools out there. I myself use WinDiff (no special endorsement meant), which makes that task a breeze: Just skip over those changed die-exit sequences with Alt-down, merge in the captcha-specific stuff with alt-left/right (depending on which version you opened first), save, done. Example: see attachment. Captcha integration for register,reset,remind,contact with a few whistles. Won't work without looking at what you're doing: You'll notice I show the markup generation in a template as the template needs to kill all those layout tables the joomla core still throws around anyway. So you'll either have to copy them into *your* template (adapting css if necessary) or merge them back to their core places. Additionally, you'll have to provide the languace-specific strings which I have not included. If you look into the source you'll readily see where I have stored those...
Errors: No Image and nowhere an error message to be seen? Entering the img's url directly might show that error message. That one gives you an "invalid image" or so? Try the request in a tool that allows you to examine the response in raw form. It might just be that the browser is trying to interpret an error message as gif, because it has been told to in the headers...