Issues with incorrect bindings in civicrm_cache table on Pantheon

I am also seeing similar problems on my test sites when multiple front end servers are used to manage requests. This results in an error like "XML data could not be loaded. Make sure you specified the correct path." I tested this out, but I am still seeing these errors.

In terms of narrowing the problem down, the immediate issue is that getFilterFromXML() seems to not be able to read the XML file at /srv/bindings/0daa2b186e8c47f190c1a4dd0ec815b9/code/profiles/civicrm_starterkit/modules/civicrm/packages/IDS/default_filter.xml because presumably that binding changes.

I believe that CiviCRM regressed. Despite running 4.3.6, I am still seeing trouble with the PHPIDS cache.

Installing https://drupal.org/project/civicrm_base_jumper + using this patch solves the problem.

I believe these errors are related to this issue:

Error loading module file (/srv/bindings/45109f279fb549129fe64392d23cb43d/code/sites/all/extensions/org.civicrm.module.cividiscount/cividiscount.php). Please restore the file or disable the module.

Error loading module file (/srv/bindings/45109f279fb549129fe64392d23cb43d/code/sites/all/extensions/ca.bidon.pcpteams/pcpteams.php). Please restore the file or disable the module.

Unable to write file:/srv/bindings/45109f279fb549129fe64392d23cb43d/files/private/civicrm/upload/latest-version-cache.txt
Please check your system file permissions.

The site is running CiviCRM 4.4.14.

I haven't included this patch because I didn't see it as part of the make file for civicrm_starterkit. Is there a reason it's not included? Even if this isn't perfect I'm tempted to use this patch since this error is "catastrophic" from the perspective of the client.

That file, though, seems to work slightly different now. It seems to be setting the cache with the results of $data. I don't see how that'll change this patch however so worth a try.

There are a lot of potential server paths that might be saved in the database. Instead of taking the approach of listing them all manually and rewriting the paths, I'm trying out the approach of just skipping the cache entirely when loading config from CRM_Core_Config::singleton(). So I've commented out the attempt to load the config from cache and also writing to the cache after rebuilding it.

I haven't seen an appreciable difference in performance nor errors, but I'll have to see how it handle under heavy usage.

Since I've pushed my patch on the live site I've noticed the binding has changed a few times (perhaps as a backup server is spun up) but CiviCRM is still working.

I was almost at my wits end so I hope I'm on the right path here (pun intended?). The bigger goal is to convince the CiviCRM core developers to formally support dynamic systems like Pantheon.

Note, I haven't been using civicrm_base_jumper so I don't think that's a problem AFAIK.

Version for CiviCRM 4.6 of patch to skip cache when trying to load/write config.

Thanks — the patch in #6 seems to have fixed the problem for me. A lifesaver!

I'm leaving this open, even though most of this is solved, especially in 4.7.x. I just noticed in civicrm_cache, a record under group_name = js_strings which saves the paths to various JS files. E.g. snippet:

a:78:{s:108:"/srv/bindings/0fc20ec91ca9478bbd43e0fa82c68999/code/profiles/civicrm_starterkit/modules/civicrm/js/Common.js";a:17:{i:0;s:7:"new tag";i:1;s:10:"%1 Created";i:2;s:5:"Clear";i:3;s:4:"Time";i:4;s:16:"Refine search...";i:5;s:10:"- select -";i:6;s:17:"Toggle fullscreen";i:7;s:25:"You have unsaved changes.";i:8;s:9:"Saving...";i:9;s:5:"Saved";i:10;s:58:"Sorry an error occurred and your information was not saved";i:11;s:5:"Error";i:12;s:7:"Confirm";i:13;s:34:"Are you sure you want to continue?";i:14;s:6:"Cancel";i:15;s:8:"Continue";i:16;s:7:"Preview";}

I'm not sure anyone has noticed an issue with JS when the binding changes so this might not be an issue. It's called in CRM/Core/Resources.php and might be created in Civi/Core/Container.php.