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.
| Comment | File | Size | Author |
|---|---|---|---|
| cache-not-working.patch | 486 bytes | david_garcia |
Comments
Comment #3
geerlingguy commentedThanks 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.