Open justintadlock opened 7 years ago
Hey Justin
I'm not sure I agree with this one. If you say used custom actions on other registration forms, the benefit of using a captcha such as this is effectively nullified. Bots would just use the other endpoints.
WooCommerce does use register_post action so captchas are output on the forms, which I think I'm going to remove/prefix shortly. But I also wonder if the reason why this one has problems is the use of register_post
action to do the validation?
The codex here reveals that this hook should not be used for custom validation:
https://codex.wordpress.org/Plugin_API/Action_Reference/register_post
Please note that this hook should never be used for custom validation. Any custom validation rules should be performed using the registration_errors filter
This won't work in our case either because we don't fire that filter, but just making you aware in case you want to change it :)
Core WP needs a proper registration form function like it has a login form function. Until then, I don't think this plugin should attempt to display fields anywhere but on the core WP registration screen. That was always the intention anyway. Changing that will only make sure that it works as intended.
Thanks for the tip on the registration_errors
hook for validation.
Actually, looking back through the code, I see why I avoided registration_errors
in favor of register_post
. From what I understand, registration errors get printed to the screen when the user is returned to the registration screen. I wanted to kill the entire process and not return errors. We're assuming it's a spambot 100% of the time and don't want to give it another chance to fill in the form.
Anyway, I'm getting a bit off-topic. This issue is about displaying the honeypot field when not on the core registration screen.
Some plugins incorrectly call WP core hooks to display a custom registration form. See: http://themehybrid.com/board/topics/honey-pot
When this happens, we should bail and not show the honeypot fields.