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
Comment #1
omega8cc CreditAttribution: omega8cc commentedAre those URLs standard of freely defined? Any path pattern we could add to no-cache by default?
Comment #2
narayanis CreditAttribution: narayanis commentedFor 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.
Comment #3
omega8cc CreditAttribution: omega8cc commentedOK, 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.Comment #4
narayanis CreditAttribution: narayanis commentedThe /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.
Comment #5
omega8cc CreditAttribution: omega8cc commentedThanks 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 filesites/<domain>/modules/cache/NO.txt
and let us know?Thanks
Comment #6
omega8cc CreditAttribution: omega8cc commentedFix committed: http://drupalcode.org/project/octopus.git/commit/f0f83d1