Captcha issues in CB Antispam

Hello, I have some issues with Captcha:

• The Icons Display function is not working for the Captcha (antispam_captcha) field. The only icon displayed is the required icon regardless of the settings in the general configuration.
• In the parameter (layout) field settings of Captcha the Icons Display override does not function.
• When publishing the Captcha in reCaptcha mode the required icon is not properly aligned next to the reCaptcha module.
• The language string is the same for the front and back end.

Can you please provide me some feedback if these issues might be bugs, or are being worked on.

Thank you in advance for your help.

Why exactly is the icons of issue? What specifically are you wanting to do with them? CB AntiSpam does not have that parameter implemented as it was added after the CB AntiSpam upgrade so it doesn't know that parameter exists. The captcha is always required, that's forced. The captcha can never display on profile, also forced. So 2 icon states are forced. I've added a bug ticket for the layout icon override parameter not working.

forge.joomlapolis.com/issues/5249

Please clarify your issues as you didn't provide any questions, but just facts. You need to provide what you're wanting it to do for me to suggest anything.

I want to be able to turn on and off the display of icons. It makes a lot of sense if this is optional for all fields, why would it not be for the Captcha field regardless if certain conditions are forced or not. It is a means to provide the necessary feedback to users and to keep it consistent throughout, which is important for the user friendliness. If you disagree and decide that it should not be as such, then at least the options should be removed from the Captcha layout parameters altogether. As far as the forced state to never show it on the profile goes, I was trying to say that that icon also does not display regardless of any setting. The only icon that displays regardless of any setting is the required icon.

In regards to the language string, I think it is important to be able to change the name or description separately for the front and back-end. In case of the Captcha field, when changing to anything else it will be used in the back-end as well. For example it will be displayed as such in the parameter settings of the CB AntiSpam plugin. I thought that language strings for the back-end area are handled separately in the admin_language.php file, aren't they?

Thank you!

I want to be able to turn on and off the display of icons. It makes a lot of sense if this is optional for all fields, why would it not be for the Captcha field regardless if certain conditions are forced or not. It is a means to provide the necessary feedback to users and to keep it consistent throughout, which is important for the user friendliness. If you disagree and decide that it should not be as such, then at least the options should be removed from the Captcha layout parameters altogether. As far as the forced state to never show it on the profile goes, I was trying to say that that icon also does not display regardless of any setting. The only icon that displays regardless of any setting is the required icon.

I've added a bug ticket to fix the parameter, but certain icons will never display. For example the profile display icon should never display as the profile display of the captcha is forced off. Required state is forced on so it should always be required. The most optional one is probably description.

In regards to the language string, I think it is important to be able to change the name or description separately for the front and back-end. In case of the Captcha field, when changing

We don't have support for something like that, but I don't understand why you'd need it. An example of what you want it to show on frontend vs backend would help.

to anything else it will be used in the back-end as well. For example it will be displayed as such in the parameter settings of the CB AntiSpam plugin. I thought that language strings for the back-end area are handled separately in the admin_language.php file, aren't they?

They are, but they're additive to frontend language strings. So backend first loads frontend then loads backend. This means if you add a string to backend and frontend language files the frontend language string will replace the backend one.

I've added a bug ticket to fix the parameter, but certain icons will never display. For example the profile display icon should never display as the profile display of the captcha is forced off. Required state is forced on so it should always be required. The most optional one is probably description.

Yes, the description is the most optional.

We don't have support for something like that, but I don't understand why you'd need it. An example of what you want it to show on frontend vs backend would help.

In this particular implementation the client requested that I changed it as follows: to This way the client feels that his website visitors get better instruction as to what to do.
In the back-end it it would make more sense that it would say "Captcha" instead it is saying "Please check the box to show us that you are human"
I have noticed in the past that this is an issue with some other fields as well.

to anything else it will be used in the back-end as well. For example it will be displayed as such in the parameter settings of the CB AntiSpam plugin. I thought that language strings for the back-end area are handled separately in the admin_language.php file, aren't they?

I didn't know about this. Thanks!

This way the client feels that his website visitors get better instruction as to what to do.
In the back-end it it would make more sense that it would say "Captcha" instead it is saying "Please check the box to show us that you are human"
I have noticed in the past that this is an issue with some other fields as well.

I see, we don't really have a way of doing this due to how language strings load. Only way to implement it would probably be to load frontend first then backend so backend can override the frontend strings. I can't really see any issue with doing this so have created a feature ticket to look into it further.

forge.joomlapolis.com/issues/5252