From e908f37e32081cfaa4a93d774e2ee07c541ff7ef Mon Sep 17 00:00:00 2001 From: Tim Otten Date: Thu, 2 Jul 2020 14:03:34 -0700 Subject: [PATCH] (dev/core#1846) Container, ClassLoader Caches - Separate caches by version number Before ------ If you load a new version of the CiviCRM codebase, then a freshness check should cause the container cache to reset automatically (based on the fact that various files have new timestamps). However, it's possible that some kind of bug or omission prevents this from working. Many developers won't notice such a bug because they're obsessive-compulsive about clearing caches anyway. After ----- If you load a new version of the CiviCRM codebase, then it should use a new container cache - regardless of how well the freshness check works. --- CRM/Core/Config/Runtime.php | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CRM/Core/Config/Runtime.php b/CRM/Core/Config/Runtime.php index 7e927af94f..1fd76d270d 100644 --- a/CRM/Core/Config/Runtime.php +++ b/CRM/Core/Config/Runtime.php @@ -141,6 +141,14 @@ class CRM_Core_Config_Runtime extends CRM_Core_Config_MagicMerge { defined('CIVICRM_DOMAIN_ID') ? CIVICRM_DOMAIN_ID : 1, // e.g. one codebase, multi database parse_url(CIVICRM_DSN, PHP_URL_PATH), + + // e.g. when you load a new version of the codebase, use different caches + // Note: in principle, the version number is just a proxy for a dozen other signals (new versions of file A, B, C). + // Proper caches should reset whenever the underlying signal (file A, B, or C) changes. However, bugs in this + // behavior often go un-detected during dev/test. Including the software-version basically mitigates the problem + // for sysadmin-workflows - so that such bugs should only impact developer-workflows. + \CRM_Utils_System::version(), + // e.g. CMS vs extern vs installer \CRM_Utils_Array::value('SCRIPT_FILENAME', $_SERVER, ''), // e.g. name-based vhosts -- 2.25.1