If using the honeypot module as an API (nothing configured in the UI) the honeypot_get_protected_forms() internal cache is not working, issuing a query statement on every request.

      // Look up all the honeypot forms in the variables table.
      $result = db_query("SELECT name FROM {variable} WHERE name LIKE 'honeypot_form_%'")->fetchCol();
      // Add each form that's enabled to the $forms array.
      foreach ($result as $variable) {
        if (variable_get($variable, 0)) {
          $forms[] = substr($variable, 14);
        }
      }

      // Save the cached data.
      cache_set('honeypot_protected_forms', $forms, 'cache');

In this code, if $result is empty, $forms will never be initialized (thus remaining NULL) and doing a cache_set with NULL data is not caching anything.

I propose to initialize the $forms array().

Patch attached.

What indeed makes sense would make the honeypot module just an "API", and the UI managed honeypot form alters be a submodule that can be optionally turned on, but that means refactoring the whole thing.

Many modules are now using this approach: separating the "coder" functionality from the "site builder" functionality.

CommentFileSizeAuthor
cache-not-working.patch486 bytesdavid_garcia

Comments

  • geerlingguy committed a8d2799 on 6.x-1.x
    Issue #2480185 by david_garcia, geerlingguy:...
geerlingguy’s picture

Status: Active » Fixed

Thanks for finding this! You're correct that if there were no configured/protected forms, you would get an extra db query whenever honeypot_get_protected_forms() was called. I committed your patch to the D7 version and backported to D6. For D8, the logic is slightly different and this shouldn't be an issue.

In terms of converting the module to a UI submodule + the main API module... that's definitely under consideration for the 2.x branch, and would likely happen in Drupal 8 before coming back to Drupal 7.

Status: Fixed » Closed (fixed)

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