The project page states that honeypot_add_form_protection() can be called inside your form builder function. This does not seem to be the case. The function references $form['form_id']['#value'] which does not exist until after the form has been built.

It seems you have to use hook_form_alter to avoid errors. Not sure if this an error in the code or the documentation.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geerlingguy’s picture

Version: 7.x-1.14 » 7.x-1.x-dev

It's probably an error in the documentation; I'm assuming I meant in a hook_form_alter(). But it would be convenient if you could call that in either the form builder or a form alter, so I'll leave this issue open to see if that would be easy to make work.

michaellenahan’s picture

@geerlingguy - thank you for this excellent module.

Adding the honeypot code in my form build function works just fine for me.

function _mymodule_form($form, &$form_state, $node) {
  honeypot_add_form_protection($form, $form_state, array('honeypot', 'time_restriction'));

  $form['name'] = array(
    '#title' => 'Name',
    '#type' => 'textfield',
    '#description' => 'Your name is required.',
    '#required' => TRUE,
  );
	
  // etc etc

However as @gigabates points out, when a form is being built it doesn't have a form_id yet.

As a result we get this error notice after adding honeypot protection to the form build function of a custom-coded form.

Notice: Undefined index: form_id in honeypot_add_form_protection() (line 187 of /path/to/drupal/sites/all/modules/honeypot/honeypot.module).

Can I suggest something like this in honeypot.module to prevent the notice:

  // Allow other modules to react to addition of form protection.
  if (!empty($options) && isset($form['form_id'])) {
    module_invoke_all('honeypot_add_form_protection', $options, $form['form_id']['#value']);
  }

Another small thing, can I suggest adding a note to the README, something like this:

When testing honeypot on your website, make sure you are not logged in as administrator or user 1. These users will bypass honeypot protection.

I know it should be obvious, but a note like this would be helpful for dummies like me :)

geerlingguy’s picture

The README suggestion is a very good suggestion indeed; you're not the first person who has been stymied by this behavior!

I think I may just pass through a null form ID or something for the invoke hook... We'll see. I'll try to get this fixed tomorrow, one way or another.

geerlingguy’s picture

Assigned: Unassigned » geerlingguy
Status: Active » Needs review
FileSize
1.13 KB

This actually requires a slight API change; in the honeypot API documentation, I say that the entire $form array is passed to modules implementing hook_honeypot_add_form_protection(), but until now, that was false—in some cases, I passed the Form ID, and in other cases, NULL.

So, as long as this patch comes back green from the testbot, I'm going to commit this fix (which includes the README suggestions above), and add a note that this introduces a slight API change (to make the API behave as the documentation suggests), then I'll port to D6 and D8.

geerlingguy’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Needs review » Patch (to be ported)
Issue tags: +release notes

Commit: http://drupalcode.org/project/honeypot.git/commit/471a52e

I'm going to fix this next in 6.x, then 8.x.

geerlingguy’s picture

Version: 6.x-1.x-dev » 8.x-1.x-dev
Status: Patch (to be ported) » Fixed
michaellenahan’s picture

Thanks. I can confirm that the D7 dev release fixes the error for me!

geerlingguy’s picture

Title: Can't call honeypot_add_form_protection() in form builder function » PHP Notice: Undefined index: form_id in honeypot_add_form_protection()

Updating title to reflect the error that appears in logs (for easier discovery of this issue via search).

Automatically closed -- issue fixed for 2 weeks with no activity.