What about the standard e107 captcha..

[Alex-e107nl]

@e107help After updating with GitHub 18082026, all websites using the Visual Captcha plugin display the captcha twice again e107inc/visualcaptcha#3. I understand that this is a separate plugin and not a priority, but the standard captcha is often unusable, lacks a refresh button, and generates images where it is impossible to determine which letters to enter. Abuse is ruled out, but ordinary users cannot establish contact either :-)

Unusable captchas:

Usable captchas:

Question 1: Is it possible to alter the way images are build and drop the ones that are not usable?
Question 2: Is it possible to place a refresh button next to the image so that when you cannot read it you can refresh it?
Question 3: Is there a quick fix to get the Visualcaptcha working again so it shows only once?

And i do not want to use Google recaptcha etc.. screenshots taken etc. must be a local solution!

Thanks in advance!

ps: i see this in e107_images/secimg.php

/*   Example Custom secure_image_custom.php file:
	<?php

	$secureimg['image'] = "code_bg_custom";  // filename excluding the .ext
	$secureimg['size']	= "15";
	$secureimg['angle']	= "0";
	$secureimg['x']		= "6";
	$secureimg['y']		= "22";
	$secureimg['font'] 	= "imagecode.ttf";
	$secureimg['color'] = "90,90,90"; // red,green,blue

	 ?>
*/

Can that still be used, how and where, in a theme?

[e107help[bot]]

@Alex-e107nl there is something you can do today about the unreadable images, so I have put that first and answered your questions after it, out of order. Sorry about that.

The unreadable images, and what pins them

Core picks one of three fonts at random for every challenge (secure_img_handler.php:898-916), and one of the three, crazy_style.ttf, rotates its letters about ninety degrees as part of the typeface. That is your four bad samples: A becomes a left-pointing triangle, L a right angle, 7 a backslash. Your two good ones are the other two fonts.

You can pin the site to one font, which is your ps answered as well: yes, secure_image_custom.php still works, and it lives in e107_images/, site-wide, not in a theme.

1. copy e107_core/fonts/puchakhonmagnifier3.ttf into e107_images/
2. create e107_images/secure_image_custom.php:

<?php
$secureimg['image'] = "generic/code_bg";
$secureimg['size']  = "19";
$secureimg['angle'] = "0";
$secureimg['x']     = "1";
$secureimg['y']     = "21";
$secureimg['font']  = "puchakhonmagnifier3.ttf";
$secureimg['color'] = "204,204,204"; // red,green,blue

I ran that on a master install here. Before the file, three requests for the same challenge came back as three different images; after it, all three were identical and drawn in the bold serif.

Two things that will bite you otherwise. A broken-image icon after this means the font filename is wrong: the handler answers a missing font with the words "Font missing" and no image header. And once that file exists, $secureimg['color'] is where the colour comes from, so define('e_CAPTCHA_FONTCOLOR', ...) in theme.php stops having any effect. Set the colour in the file, not in both places.

Your questions

1. Can the unusable ones be dropped at generation time? By you, yes, that is what the file above does. In core, that is a decision rather than a fix, so I have not written a patch. Beside the font, the answer alphabet includes - and _, which arrive from a helper built for generating names rather than for reading letters off a picture (user_handler.php:600-608), and a hyphen in a rotated font is a short line pointing anywhere. I have filed #6022 with the causes and three ways it could go. Which one is right is Deltik's call, not mine.

2. A refresh button? Nothing in core does it, and the obvious approach will not work: the answer is sealed inside the token that is in the image's own URL, so asking for that URL again redraws the same code. A new challenge means a new token, which means reloading the form page, or an endpoint that mints one. A theme-side button that reloads the page is within reach; a proper in-place refresh is the endpoint, and that is in #6022 too.

3. Visual Captcha twice. Two separate causes, and only one of them is ours.

Ours is the contact form and the contact menu. Since early August, core appends a CAPTCHA block to any contact form it thinks has none, and it decides that by searching the markup for its own field name, which your plugin does not emit. That is on master and in v2.3.11. Filed as #6014, with #6033 on master and #6035 on release/v2.3.x. Both are open and waiting on Deltik, so pulling master today will not change what you see.

The other one is the plugin, e107inc/visualcaptcha#3, open since 2017, which is why it reads as coming back rather than arriving. e107 asks a CAPTCHA for two things, the picture and the input field, and every core form asks for both. The plugin answers both with the same widget: secure_image::r_image goes to visualcaptcha_module::blank(), and blank() returns input(). So sign-up, sign-in and the admin login draw it twice whatever core does.

For your own copy, the smallest change that holds everywhere is to make visualcaptcha_module::input() return the markup the first time it is asked in a request and an empty string after that. Every core form asks for the picture before the field, so it lands in the right place, and email.php, which asks only for the picture, still gets one. I have not run that, and the reasoning is on the plugin issue in full. Returning '' from blank() instead looks tidier and quietly breaks email-a-friend.

Nothing above needs Google.

[Alex-e107nl]

Yesss this is perfect!

copy e107_core/fonts/puchakhonmagnifier3.ttf into e107_images/
create e107_images/secure_image_custom.php:

<?php
$secureimg['image'] = "generic/code_bg";
$secureimg['size']  = "19";
$secureimg['angle'] = "0";
$secureimg['x']     = "1";
$secureimg['y']     = "21";
$secureimg['font']  = "puchakhonmagnifier3.ttf";
$secureimg['color'] = "204,204,204"; // red,green,blue