Honeypot Instructions

[omartan]

Added instructions for implementing Honeypot

[omartan]

Closed pull request as I've made a few mistakes in the code, right now it doesn't work. Will reopen once it's in working order

[omartan]

fixed honeypot

Changelog:

1. readme.md updated with the latest instructions
2. added a few lines of code in form-submission-handler.js

[mckennapsean]

Thanks for the PR, @wheelhot !

I've been wondering what you/others think, should examples such as these go into a separate folder, in their own file? Currently, the readme is quite long and hard to navigate as-is. I don't want advanced features getting missed because of this!

Also, the form submission handler file would break without a honeypot field (requiring all forms to have a honeypot field). And some people source from this file directly on GitHub, so that is something we shouldn't force people to do. It could be included in the readme, or can you think of another way to implement this? I have been toying around with a PR that is about using data-attributes to control Javascript functionality, and I was thinking that could be of use here (e.g. data-honeypot='honeypot' attached to your form will activate the bit of JavaScript, and it won't use the honeypot checker in other forms).

Lastly, style thing, it may be best not to use console.log excessively, and the script already does it quite a bit. Happy to hear others' opinions on this, but generally code in production shouldn't unless you have a debug mode on.

[omartan]

Made Honeypot as optional

Changelog:

1. Commented out 'if statement' in 'handleFormSubmit function' to allow form submission to work if honeypot isn't implemented
2. Added additional instructions in README.md

[omartan]

That's odd, I'm pretty sure I replied to your post, anyway I made some changes to the file so that it will now work if the user doesn't want to use the honeypot technique to prevent SPAM.

Admittedly, the implementation is a crude one but should serve its purpose as the user only need to add the needed HTML, CSS and to remove the comment from the function in the javascript file. README is updated to highlight the changes and steps needed to get honeypot SPAM prevention to work.

[omartan]

I've been wondering what you/others think, should examples such as these go into a separate folder, in their own file? Currently, the readme is quite long and hard to navigate as-is

I do think separating it into a separate folder will be a good idea as it'll make it easier for the user to learn how to implement certain features and as everyone tends to have their own setup, this allows debugging to be easier in my opinion.

Also, the form submission handler file would break without a honeypot field (requiring all forms to have a honeypot field)

Noted and I've updated it with my changes (see the previous comment).

It could be included in the readme, or can you think of another way to implement this? I have been toying around with a PR that is about using data-attributes to control Javascript functionality

Short term solution would be readme (as in my latest commit), however using data-attributes to control functionality as a long term solution would be great. Besides honeypot, is there any other feature request that will make use of such functionality?

Lastly, style thing, it may be best not to use console.log excessively

Perhaps we can implement something like JQuery? Where we will have 3 versions of form-submission-handler.js

1. Developer Edition: Comments and Console.log to allow easy modification and for those who would like to learn
2. Production Edition: Comments and Console.log is removed
3. Compressed/Min Edition: Google Closure Compiler is used to minify form-submission-handler.js.

[mckennapsean]

Interesting, thanks for the updates! I think, based on the discussion, we can perhaps revise the readme first to separate out the extra features and clean up some of the code with data-attributes first, before pulling this in, unless anyone feels strongly. People can always find the code here to implement themselves meanwhile!

Re: the logging, that may be a little overkill for such a small project. :) We could perhaps just comment out logging, so people looking to debug can try uncommenting on their own, or alternatively set it as a variable or even a data-attribute as well.

[mckennapsean]

Also, another aspect to consider adding to this walk through is that, for advanced functionality, someone could utilize the reCAPTCHA API: https://www.google.com/recaptcha/intro/

[omartan]

We could perhaps just comment out logging, so people looking to debug can try uncommenting on their own

That sounds good!

Also, another aspect to consider adding to this walk through is that, for advanced functionality, someone could utilize the reCAPTCHA API: https://www.google.com/recaptcha/intro/

I haven't able to get reCAPTCHA to work with this yet