Details
-
Type:
Bug
-
Status: Won't Do
-
Priority:
Minor
-
Resolution: Won't Do
-
Affects Version/s: 4.6.14
-
Fix Version/s: 4.6.16
-
Component/s: Extension System
-
Labels:
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Contributed Code
Description
Step to reproduce
Installed civicrm 4.6.14
Configured Extension path, url and enabled few extensions
(e.g. com.cividesk.normalize, com.cividesk.helptab )
Enabled Multilingual for English and French
Now on every page load / language switch, it showing following error
Error loading module file (). Please restore the file or disable the module.
This is my observation
While Prepare config object first time, uf_match table is updating to store language against logged in contact id (CRM_Core_BAO_ConfigSetting::retrieve). CRM_Core_DAO=>save() method calling hook CRM_Utils_Hook::postSave($this); call reached to CRM_Extension_System->__construct()
where $config object get used to get details about 'extensionsDir' & 'extensionsURL'. at this stage config object is not prepared and this information not present at all.
attached file with back-trace and config object output in CRM_Extension_System->__construct()
For background/reference: CRM_Core_Config has some deep flaws in <=v4.6. We spent a ton of time working on them for v4.7.
Wonder if this applies to v4.7. My hunch is that v4.7 will work better in this use-case. There, the extension-system explicitly boots before the localization/ufmatch stuff. (Observe https://github.com/civicrm/civicrm-core/blob/4.7.3/CRM/Core/Config.php#L101 – Civi\Core\Container::boot() comes before CRM_Core_BAO_ConfigSetting::applyLocale()):
If you absolutely must patch v4.6, you could maybe look at breaking apart CRM_Core_BAO_ConfigSetting::retrieve() so that CRM_Core_BAO_ConfigSetting::applyLocale() is a separate function. Then fire applyLocale() later in the process. (Initializing session-scoped locale data while retrieving domain-scoped settings is... silly...)
In
CRM-10250, I offered a comment which also applies here: "It would be nice to get some bugfixes in them (v4.4/v4.6), but bugfixes to central/complicated code (like CRM_Core_Config) come at the risk of regression, and it's safer to do that as part of major-release (with alpha/beta testing cycle). The LTS crew is a bit more permissive/adventurous about bugfixes, and (if someone wants to file a PR) it sounds like they'd welcome a PR whenever 4.6 moves to LTS maintenance."