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 :-)