"Cannot redeclare class CRM_Core_ClassLoader" when sync live site to staging

[Sean Madsen]

I maintain a live installation of CiviCRM as well as a couple different staging installations on the same server.

After upgrading from CiviCRM 4.1 to 4.4 I'm having trouble synchronizing the live site to the staging site.

This topic http://forum.civicrm.org/index.php/topic,25529.0.html helped me narrow down the problem, but not get to a solution.

Here is what I'm experiencing:

• My live site works and is running CiviCRM 4.4.3 on Drupal 7.23
• My live site file-system lives at /var/sites/bikesnotbombs.org/ and my staging site is entirely separate at /var/sites/upgrades.bikesnotbombs.org/
• I run a script that does the following: rsync (with delete) the whole live site file-system to the staging site, except for one very small custom PHP file containing the database credentials for each site (this file is referenced by settings.php and civicrm.settings.php). Then drop and create fresh databases for staging drupal and Civi. Then sync live drupal and civi databases to fresh staging databases. Then run drush cc civicrm from within the staging site. Presto. This technique has been working well for me, mostly unchanged, since CiviCRM 2
• But now when I take these steps after upgrading my live site to Civi 4.4, I visit staging site home page and I get an Apache white screen of death

My Apache error log looks like:
PHP Fatal error:  Cannot redeclare class CRM_Core_ClassLoader in /var/sites/upgrades.bikesnotbombs.org/drupal/sites/all/modules/civicrm/CRM/Core/ClassLoader.php on line 36

I tried the technique described here: http://forum.civicrm.org/index.php/topic,25529.msg108081.html#msg108081 to see all the included files. Strangely enough, files from my live site are being included in the PHP runtime for the staging site. Of the many many files listed, here are the last 6 lines of output I see:
/var/sites/upgrades.bikesnotbombs.org/drupal/sites/all/modules/views/plugins/views_plugin_row_fields.inc
/var/sites/upgrades.bikesnotbombs.org/drupal/sites/all/modules/views/plugins/views_plugin_row.inc
/var/sites/bikesnotbombs.org/drupal/sites/all/modules/civicrm/CRM/Core/ClassLoader.php
/var/sites/bikesnotbombs.org/drupal/sites/all/modules/civicrm/packages/IDS/vendors/htmlpurifier/HTMLPurifier/Bootstrap.php
/var/sites/upgrades.bikesnotbombs.org/drupal/sites/default/civicrm.settings.php
/var/sites/upgrades.bikesnotbombs.org/drupal/sites/all/modules/civicrm/CRM/Core/ClassLoader.php
(I wouldn't expect to see any files under /var/sites/bikesnotbombs.org/ being included. Strange.)

I've tried grep -r -I 'bikesnotbombs\.org' .   to look for any files configured to point statically to my live site's location in the file-system and came up with nothing relevant. So it seems that only leaves the databases as the culprit.

In my staging site I try drush cc all and get the same error that shows in my Apache error log. If I do drush pm-disable civicrm then I am able to run drush cc all as well as load the home page with no errors, but if I try drush pm-enable civicrm I get that pesky "Cannot redeclare..." error again.

How can I sync my live site to a staging site without encountering this error?

[Sean Madsen]

WORK-AROUND: I finally fixed this issue by running the following command on the dev site after the sync is completed from the live site:

drush vdel civicrm_class_loader

I've added this command to my sync script.

I also tried running the command directly on the live site to see if that change would stick (thus eliminating the need to run it on the dev site after each sync), but alas it did not work. Running it on the live site didn't seem to cause any harm, but I still needed to run it again on the dev site after the sync.

Could this be a civi bug? Moving a site around should not be this difficult.

By the way, I figured this out by dumping my drupal database for my post-sync (broken) dev site with the --skip-extended-insert option and then searching the raw dump file for occurrences of the text "/var/sites/bikesnotbombs.org/" (the file location of my live site). I found an entry in the `variable` table which seemed like a potential culprit, so I tried deleting the variable. Kind of a shot in the dark, but it worked. 

[emilyf]

FYI, I had this issue as well last week and started a discussion on it. Also brought it up on irc and I believe there is a plan to deal with this, although I do not have further details on exactly what/when it will be fixed.

http://forum.civicrm.org/index.php/topic,31366.msg134439.html#msg134439

[rchew]

I am new to CiviCRM but encountered this same problem with civicrm_class_loader when copying from the live site to a development sub-domain.  The solution that worked was suggested by Sean in one of his comments above.

I deleted the row in the Drupal DB "variable" table where name='civicrm_class_loader' and then cleared cache in Drupal.  Everything worked fine and I could see that the row was re-created.  I did try the Drush command first but it got some sort of error.

To clarify, the migration method that I used was to (1) migrate Drupal without CiviCRM (no problems encountered); (2) do a clean install of CiviCRM (this is where I encountered the problem); and (3) deleted/re-created/loaded the live CiviCRM data.

Hope this helps someone else...

[howiek03]

Hi All,

I am also having issues with this.

PHP Fatal error:  Cannot redeclare class CRM_Core_ClassLoader in /var/www/dev.domain.com/www/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 /var/www/dev.domain.com/www/sites/all/modules/civicrm/CRM/Core/ClassLoader.php, line 36

I have tried the steps listed by Sean, but no success.

I grep'd the directory and only found a single instance of class CRM_Core_ClassLoader.

Does anyone know if this is perhaps a drush issue?

Any other ideas on how to fix this?

Thanks.

[Laryn]

Following up -- rchew's note about the Drupal variable solved it for me, too.