Warn that 'protect all forms' disables caching on certain pages [#1982848]

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 commented 30 April 2013 at 16:41

Even 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 commented 1 May 2013 at 02:57

Title:

Doesn't warn that 'protect all forms' can break caching across site

» Warn that 'protect all forms' disables caching on certain pages

This 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.