CiviCRM Community Forums (archive)

I had a lengthy battle trying to resync my production database back to my development environment this week where I kept getting that nasty WSOD with the "PHP Fatal error:  Cannot redeclare class CRM_Core_ClassLoader" issue.

All the testing I was doing as well as searching around the forum was confirming that the issue was related to this kind of migration. In the end, I found that to fix I  had to approach it the following way:

- pull down the db
- manually flush the drupal cache
- delete the variable civicrm_class_loader from variable table
- issue drush cc all
- I was still getting the WSOD, which at this point didn't make sense because the drush cc had been successful where previously it had failed and output my error. So the one other addition I had added was the civicrm_multiday_event module. I then issued drush dis civicrm_multiday_event -y, then again cleared the cache, and then finally everything was good to go. Then re-enabled civicrm_multiday_event without a problem.

I want to try to pinpoint what the issue is and try to help figure out a way to make this easier. I'm on 4.4.3.

I found this on github https://github.com/civicrm/civicrm-drupal/pull/88 which lead me to http://issues.civicrm.org/jira/browse/CRM-13737 that suggests the civicrm_class_loader variable was just added in CiviCRM 4.4 a couple months ago.

So I'm trying to determine:
- is there some kind of code I could add as a patch to civicrm_multiday_event that would force a reload of that variable in these situations where it was holding everything up?
- or is this something that should be attempted to be handled on the civi side itself?
- Why did not just deleting that variable fix everything anyway?

Trying to wrap my head around where things are going wrong here, so pointers would be great. I have a setup where I'm ready to test/debug further. Thanks.

Thanks, Mathieu! I will get this tested out on Monday and report back!

Although this has been fixed, I have been testing with it and still see the issue on my server. I'm using memcache, and I think that's part of the issue. I no longer get fatal errors from this so that's certainly good. But almost daily I get a drush fatal error that will say:

HP Fatal error:  Cannot redeclare class CRM_Core_ClassLoader in/sites/all/modules/civicrm/CRM/Core/ClassLoader.php on line 36
Drush command terminated abnormally due to an unrecoverable error.                                                                                                                    [error]
Error: Cannot redeclare class CRM_Core_ClassLoader in /sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36
Drush was not able to start (bootstrap) Drupal.                                                                                                                                       [error]
Hint: This error can only occur once the database connection has already been successfully initiated, therefore this error generally points to a site configuration issue, and not a
problem connecting to the database.

I can't use drush cc all or drush vdel civicrm_class_loader to fix; the only way I can resolve is to reload memcache. Then all is fine until the next time.

I'm not sure what this means or if others are seeing this; I certainly have a temporary solution as it only affects drush, but it is less than ideal obviously.

Hi,

To help diagnose if this is the same issue as previously discussed, can you check the value of the civicrm_class_loader variable? Since 4.4.x, if I recall correctly, this variable now stores a relative path, so the issue previously discussed should not occur. If it did, you can workaround it during your upgrade by deleting the variable.

In the process you describe, at what point in the migration are you? i.e. presumably Drupal 6 has been upgraded to 7, but was CiviCRM upgraded?

Thanks,
Mathieu

PS: the Drupal issue you link to is specific to provision_civicrm, part of Aegir, a Drupal install/upgrade management system (http://www.aegirproject.org/). It was affected by the new classloader variable because when doing upgrades, Aegir will migrate the DB from one code base (/var/www/drupal-7.34) to another code base (/var/www/drupal-7.35), so the variable had to be reset in the process.

Everything I am doing is to box-stock installs of Drupal Commons and CiviCRM 4.5.6.

Since I began Commons has issued some upgrades which I have not applied as I want to learn to have drush do this kind of thing for me from the command line.   

All modules are as enabled by the Drupal Commons Profile install.

Memcache modules are not enabled, but Entity cache 7.x-1.2 is.

Once again, thanks for the reply.

Here is a clue for you.

I removed ~/.drush/civicrm.drush.inc

Launched a fresh terminal instance from my root.  Navigated to nscf.test folder where the install is.

Issued a drush @nscf.test cc all
Same result:  Fatal error: Cannot redeclare class CRM_Core_ClassLoader in /Users/username/sites/nscf/nscfd7-test/sites/all/modules/civicrm/CRM/Core/ClassLoader.php on line 36
Issued a drush cc civicrm

Nice result:
The CiviCRM cache has been cleared.       [ok]
'civicrm' cache was cleared.
Issued another drush @nscf.test cc all

Same bad result:

rush command terminated abnormally due to an unrecoverable error.                   [error]
Error: Cannot redeclare class CRM_Core_ClassLoader in /Users/larrylowe/sites/nscf/nscfd7-test/sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36

On a hunch, I navigated to:   My Server Root/nscfd7-test/sites/all/modules/civicrm


issued a drush @nscf.test cc all

Same bad result:

rush command terminated abnormally due to an unrecoverable error.                   [error]
Error: Cannot redeclare class CRM_Core_ClassLoader in /Users/larrylowe/sites/nscf/nscfd7-test/sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36

so I cannot use drush @nscf.test cc all

I will look into providing some alias to cc all or modifying it,  or some kind of work around, but I think something needs to be done to the shipping civicrm/drupal/drush/civicrm.drush.inc, which is now in force, to respond nicely to a drush @nscf.test cc all

I am guessing that (civiCRM init) is TRUE if I've gone so far to navigate to the module to run the cc all command.

/**
 * Implements hook_drush_cache_clear.
 */
function civicrm_drush_cache_clear(&$types) {
  if (_civicrm_init(FALSE)) {
    $types['civicrm'] = 'drush_civicrm_cacheclear';
  }
}
I will strive to develop a work around and report here.

Any thoughts you might have would be useful.

Fatal error: Cannot redeclare class CRM_Core_ClassLoader in /Users/username/sites/nscf/nscfd7-test/sites/all/modules/civicrm/CRM/Core/ClassLoader.php on line 36

Core class loader.php, line 36 on:
class CRM_Core_ClassLoader {

  /**
   * We only need one instance of this object. So we use the singleton
   * pattern and cache the instance in this variable
   * @var object
   * @static
   */
  private static $_singleton = NULL;

I have a near identical install one directory over at @nscf.work  Is this the issue?

https://github.com/civicrm/civicrm-drupal/pull/118

https://issues.civicrm.org/jira/browse/CRM-14186

This is absolutely critical and should get fixed. Because of this bug it's very difficult to have two Drupal CiviCRM instances on the same machine, one for live and one for staging/development. That is my exact setup, and when I updated to 4.4.4 the staging site started throwing the "Fatal error: Cannot redeclare class CRM_Core_ClassLoader" error. It took a lot of searching to find a solution. The "drush vdel civicrm_class_loader" command did the trick.
So I do a drush vdel civicrm_class_loader and a drush @nscf.test vdel civicrm_class_loader and got:

civicrm_class_loader not found.

Looking into civicrm.drush.inc I find this:
function drush_civicrm_cacheclear() {
  _civicrm_init();

  // Clear the classloader cache variable
  // Should be done in CiviCRM core so that the system flush always deletes
  // the variable, however, it needs to be done early enough before the
  // ClassLoader initialization. FIXME.
  variable_del('civicrm_class_loader');
FIXME. in the comments stood out.

Over to you.