Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.1.0
-
Fix Version/s: 4.2.0
-
Component/s: Core CiviCRM
-
Labels:None
Description
Originated here: http://forum.civicrm.org/index.php/topic,25209
Solution discussed by email:
1. Continue to register the class-loader as we currently do.
2. Additionally, update the civicrm.settings.php template to register classloader on new installations
3. Additionally, modify CRM_Upgrade_Incremental_php_FourTwo to update civicrm.settings.php
4. Change the convention from
require_once 'CRM/Core/ClassLoader.php';
$classLoader = new CRM_Core_ClassLoader();
$classLoader->register();
to
require_once 'CRM/Core/ClassLoader.php';
CRM_Core_ClassLoader::singleton()->register();
5. In CRM_Core_ClassLoader::register(), guard against redundant registrations.
6. Mark CRM_Core_ClassLoader::__construct as 'protected'
This approach has a few properties:
a. Avoids chicken-and-egg problem during upgrades.
b. Doesn't require major refactoring
c. If the upgrader fails to modify civicrm.settings.php (eg due to permissions), the core app will still work.
d. If a custom script author is overly diligent and calls register() on his own, it won't screw anything up.
e. Scripts can be compatible with both old (Civi 4.1) and new (Civi 4.2) bootstrapping processes.