Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
It's worth pointing out to the user that pages where honeypot is active get a drupal no-cache header. If you have a search or login block, as many sites do, this will break page caching across the whole website (rendering things like varnish useless).
While this is the expected behaviour, it's worth pointing this out to the user, because it looks like a bug somewhere else in caching stack. (i.e. it took me two weeks before I realised what was up!).
Comment | File | Size | Author |
---|---|---|---|
#6 | 1982848-6-clarify-page-caching.patch | 2.09 KB | geerlingguy |
#4 | 1982848-4-clarify-page-caching.patch | 9.53 KB | geerlingguy |
Comments
Comment #1
joshk CreditAttribution: joshk commentedEven better would be if this could be made compatible with page caching. It's pretty much a deal-breaker for production sites not to be able to cache for anonymous visitors.
Comment #2
geerlingguy CreditAttribution: geerlingguy commentedThis setting will only disable caching on pages where non-admin forms are present. On some sites, this could be many pages, if there's a particular form you have in a block that's displayed across most of the site.
However, on most sites, this setting will only disable caching on pages like the User Registration page, and Webforms (pages where user-fillable forms are present). At least, that's how it should be working.
Finally, it would be a good idea to show some warning if this option is checked that any page where a form is present will not be cacheable. Another option would be to allow users to disable timestamp-based protection on forms entirely—but that's would defeat about half the effectiveness of this module's spam fighting capability.
The best solution, if you have a site where performance/cached page hits is extremely important, is to simply not check 'Protect all forms', and to enable protection on only the forms you need. Maybe the documentation should make it clear that this is the typical/preferred use case.
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedComment #4
geerlingguy CreditAttribution: geerlingguy commented8.x patch attached.
Comment #5
geerlingguy CreditAttribution: geerlingguy commentedDone with 8.x: http://drupalcode.org/project/honeypot.git/commit/04d4aff
Comment #6
geerlingguy CreditAttribution: geerlingguy commentedD7 patch attached.
Comment #7
geerlingguy CreditAttribution: geerlingguy commentedComment #8
geerlingguy CreditAttribution: geerlingguy commentedD7: http://drupalcode.org/project/honeypot.git/commit/e595108
D6: http://drupalcode.org/project/honeypot.git/commit/4e3b30f