I've noticed that the BOA caching mechanism is caching CiviCRM mailings and group memberships, and Webform results. To duplicate:

1. Create and submit a webform
2. Go to the Results tab and see the new submission
3. Click Delete for the submission
4. Notice that the page has refreshed and the nonexistent submission is still there
5. Click Delete again and receive error that the node is not found

The same issue occurs when deleting items from the CiviCRM CiviMail component, and on a contact record when adding or removing the contact from groups. I've seen it occur when renewing memberships and performing other actions as well.

Caching for the site is left at the BOA defaults (Purge and Cache Expiration enabled and on default settings). Boost or other caching-related modules are not enabled.

This is a Drupal 7 site on a Linode with the following relevant items and versions: Ubuntu.lucid i686 XEN / Aegir BOA-2.0.3 / Barracuda BOA-2.0.3 / Nginx 1.3.0 / PHP 5.2.17 and 5.3.13 / MODERN-NO / FPM 5.2 / CLI 5.2 / MariaDB-5.5.24 FQDN / Wildcard NO

Comments

omega8cc’s picture

Are those URLs standard of freely defined? Any path pattern we could add to no-cache by default?

narayanis’s picture

For CiviCRM, the path is standard; it's http://drupalsite.org/civicrm, where the /civicrm* path would not be cached. On sites with clean URLs there are additional URL parts (like /civicrm/mailing), and on sites without them the arguments are added to the end (/civicrm?arg=value&arg2=value).

Webform is like any other entity/content type, so I don't think we have a standard path for them. The only thing they would have in common across all sites is that default classes added to webform pages always contain the word "webform". I'm guessing that's not specific enough, or can't be checked early enough, to disable caching. On the sites I've worked with, the results page path is http://drupalsite.org/node/1234/webform-results, so perhaps that final part of the path is standard.

omega8cc’s picture

Status: Active » Postponed (maintainer needs more info)

OK, thanks. I guess we need more confirmation on this to make sure we can safely exclude only requests including webform-results. Excluding entire /civicrm* or /civicrm/mailing* is not a good idea, IMO.

narayanis’s picture

The /civicrm path is generally internal only. There are a few situations where there is a public-facing donation page or event registration page, but 95% of pages that start with the /civicrm path are only accessible to the users who spend their day working inside CiviCRM.

omega8cc’s picture

Component: Documentation » Code
Category: support » bug
Status: Postponed (maintainer needs more info) » Needs work

Thanks for the info. This issue is a bit strange, because Speed Booster cache is using just 10 seconds TTL and every POST request creates cookie valid for 15 seconds which is used to skip Speed Booster cache for both logged in and anonymous users, so I'm not sure if this is Speed Booster related.

Could you try to disable Speed Booster first (temporarily) - by creating /data/conf/override.global.inc file with just one line: header('X-Accel-Expires: 1'); - and if that doesn't help, try to disable Redis cache using empty control file sites/<domain>/modules/cache/NO.txt and let us know?

Thanks

omega8cc’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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