FrontendForms - A module for creating and validating forms on the frontend

[HMCB]

@Juergen amazing stuff. Thank you very much.

[Andy]

Hi @Juergen

There appears to be a useful captcha in modules. Do you think it could be attached to your forms?

 

[Juergen]

Hello @Andy

I have seen this CAPTCHA and it looks good. I have to test it first to see how it works and if and how it could be implemented into FrontendForms.

But this is not on top of my priority list. At the moment I am working on an upgrade of the FrontendFormsManager to implement an UI for blocked IPs.

Currently this will be handled inside the module config, but I want a better UI outside of the module config. This should help site owners to identifiy and block suspicious IP addresses, so I am working on to include this inside the FrontendFormsManager.

But I will keep the new CAPTCHA on my list ?.

Best regards

[Andy]

Hi @Juergen

Thank you for your work. I have implemented your form in a working project. And so far it is working without any problems.

Tests show that your project is sufficiently robust.

My advice for the future, it's just an interesting opportunity.

[Juergen]

Thank you @Andy

If you have a live site online with FrontendForms, you can give me a link to your site and I will add it to the "Live examples" section of the readme file. This is a brand new section so there are only 2 examples there at the moment, but I will add more examples over the time.

In this case you get a backlink for free to your site, but I will point it to the page where the form is included.

[Andy]

Thanks @Juergen

This site is on the list of this forum and it states what I use. your form.

If you are interested, your form is here:

https://surfdacha.com/en/booking/

Website published here

 

 

 

Edited August 3 by Andy
correct this

[Juergen]

Thanks @Andy

I have added your site to the live examples. ?

 

[Andy]

Thanks @Juergen

I announced your module in the site description too.

 

[Juergen]

Version 2.2.13 comes with an upgrade for the FrontendFormsManager module.

The FrontendFormsManager module shipped with FrontendForms was added a few versions ago. The usage of this module is optional.

This module now also supports the management of suspicious IP addresses. These are IPs that have been temporarily banned due to many unsuccessful form submission attempts (logging must be enabled in this case). A new section for managing these IP has been added.

As you can see, a table of statistical data and a chart have been added to the FrontendFormsManager. When you click on the "Go to all temporarily blocked IPs" button, you will be redirected to a new page that contains all the temporarily banned IPs. The data is taken from a log file. Below you will see a screenshot of this page.

Inside this table you have a button to view more details about this IP and a button to add/remove this IP to/from the blacklist. If you click the "View details about this IP" button a panel will be opened with more information about the IP and the number of blockings.

With this information, you can now decide whether you want to block this IP permanently by adding it to the blacklist or not.

Happy testing!

[HMCB]

@Juergen great work. I’ll be using this for upcoming landing pages for a sales/marketing company. Thank you.

[Juergen]

Version 2.2.14 is out!

This new version comes with a new CAPTCHA type: a slider captcha. Now FrontendForms supports 7(!) different CAPTCHA types and I guess this will be the last one.

There is a fabulous module in the module directory which also creates a slider captcha that can be used with other forms: Slide Captcha. But the slider Captcha in FrontendForms is an extra coded and integrated captcha, that has nothing to do with this module. To be clear: The slider captcha inside FrontendForms is similiar to the Slide Captcha module, but it has nothing to do with it. So there is no need to install the other module. The only thing you have to do is to enable the slider captcha in the module configuration - that is all.

You have 1 additional configuration field where you can select the accuracy of the puzzle piece to the goal. 5 means that the distance of the puzzle pieces to the target must be less than or equal to 5px in order to solve the captcha correctly.

Here you can see the new slider captcha in action:

As always, please report any bugs on Github!

[HMCB]

@Juergen you are awesome. Great final addition to this module.

[Juergen]

Version 2.2.15 is out!

This update comes with a small performance upgrade. Now you can choose on which pages you want to embed the JS and CSS files of the FrontendForms module. This means that you can prevent the files from loading on pages that do not contain a form. This also allows these pages to load faster

This version includes a new configuration field in the backend where you can select all the pages where you want the files to be embedded.

 Best regards

[DrewPH]

I'm trying this module out in a site I'm building, and it looks like being ideal. I appreciate you developing and supporting it.

However, I've run up against a class naming conflict...

In frontendforms.css, in the "Slider Captcha" section, there is 

.block {
    position: absolute;
    left: 0;
    top: 0;
}

This has instantly nuked my entire page layout, since I'm building the site with RepeaterMatrix fields and am using "block" as the main class for each matrix!

I know I can use a different class name or override the attributes, but I'd like to suggest that modules should be as specific as possible in their CSS usage in order to avoid conflicts, especially with a word as generic as "block".

Is it possible for you to use a wrapper class in the css file, so that other classes named "block" are not affected when this module is installed? Something like this:

.sliderCaptcha .block {
    position: absolute;
    left: 0;
    top: 0;
}

Then, in AbstractSliderCapture.php, you could have something like this on line 48:

return '<div class="sliderCaptcha" id="' . $formID . '-captcha" data-validated="false"></div>';

I may have missed something you'll need to change but I'm sure you get my point.

Hope you can consider this - thanks!

[Juergen]

Hello @DrewPH

Thanks for reporting this issue and you are absolutely right. I have changed all class names (not only the "block" class name) of the CAPTCHA element by adding the prefix "ffm" to all classes. Now it should be very unlikely to get class names conflicts in the future. So please update to the latest version 2.2.17 in order to get all changes.

You can read the full changelog here.

Important information to all other users: If you have modified the styling of the Slider Captcha by adding your own CSS by overwriting the default CSS, please take care that the class names have been changed now and your changes will no longer affect the the styling of the CAPTCHA. So please adapt your custom CSS with the new class names.

[DrewPH]

11 minutes ago, Juergen said:

So please update to the latest version 2.2.17

That was unbelievably quick... thanks very much :-)

[DrewPH]

I'm almost done with my integration of this module, and it's working great. WireMail and WireMailSMTP integration was easy.

I have 2 issues though:

1. On AJAX submission, the loading message "Please be patient... the form will be validated!" seems to be hard-wired. Would you be able to offer some way for developers to override it with their own custom text? For example, I'd like my site to simply show "Submitting your enquiry...".

2. Whenever I type into my textarea form field, my JavaScript console gives me this error:

Uncaught TypeError: Cannot read properties of null (reading 'children') at HTMLTextAreaElement.<anonymous> (frontendforms.js?v=2.2.17:455:29)

I think it's something to do with the character counter, which I have not enabled. And the form still submits OK.

Thanks in advance for looking into these issues!

[Juergen]

Hello @DrewPH

Thanks for you issue report and your suggestion for a new feature!!

I have fixed the JS error. Please replace the JS file with the new one on GitHub (https://github.com/juergenweb/FrontendForms/blob/main/frontendforms.js) and let me know if the error is gone now.

Your suggestion to be able to customize the info message during an Ajax request: I will take a look to add a new configuration field in the backend to change the message text to your needs. BTW, it is not really hard coded - it is a translatable string, so you can change it in the backend to your needs if you have the language option installed in PW.

But I will take a look to make it possible to change it independently.

Best regards Jürgen

[DrewPH]

JS error resolved with the new file, thank you!

I'm not using the language option at all (and don't expect to in the near future), so an independent override would be really great when you have the time, thanks.

[Juergen]

Hello @DrewPH

I have added your request to the new version 2.2.18.

Now you can find a new text field inside the module configuration under the AJAX tab, where you can change the info text for the user during an AJAX request. If you enter a custom text into this field, then this text will be displayed globally on each form on the site.

In addition I have added a new method too, where you can change the text on per form base, which means that you can use a different text on each form (if needed). I guess this is a use case, that will not be needed very often, but if so.....you can.

This new method is called setAjaxMessage() and has to be used with the form object:

$form->setAjaxMessage('This is my custom submission text');

This method overwrites the default or global text on per form base.

BTW, I have discovered 2 other JavaScript problems beside the problem you have described  during the development of this new feature and I have fixed these problems too. You will find the complete description of all changes inside the changelog of this version.

As always, please keep an eye if everything works as expected after the update!!

Best regards Jürgen

[DrewPH]

3 hours ago, Juergen said:

This new method is called setAjaxMessage()

Brilliant, and once again very fast. I'll try it out as soon as I can.

[DrewPH]

Now tested (I used the module configuration field) and it works perfectly. Thanks again.

[Juergen]

Version 2.2.21 comes with an UI upgrade!

The new version has no additional new features, but a UI upgrade for better userfriendly selection of the global email template.

As you can see, the old select input field has been replaced by a stylish image picker select. Now you can see how the template looks like. This is realized via a Jquery image picker script and thumbnails of each template.

The templates you will see above are the default email templates shipped with this module. If you have created your own custom template, you can also display it here.

You will find more information inside the changelog file.