Drush / Aegir broken with latest entityreference

I'm having this same issue. Can't figure out a workaround.

Thanks cschaub your workaround in #2 was a success!

It may be some issue in the module itself, but it is not really a design flaw in Aegir or Drush. It is a bad practice to use site specific space for your code, or you are following well known recipe for disaster.

It looks like we have already hijacked this thread, as it is not really module (entityreference) specific, so i would propose to move this issue to the Provision queue.

There are two, only partially related issues here: how Aegir handles the site specific code and why, and the real reason behind "Cannot redeclare class" error.

Again, it is not really a bug in Aegir nor design flaw (call it a missing feature, if you wish - however I would call it a missing workaround), since these modules simply can't be reliably tracked/compared by Aegir and thus will be reported as missing on platform comparison, because they don't and will not exist on the target platform, until the site archive will be extracted in the new place. It was discussed and explained many times in the Aegir project queue. While modules in the site space can't be really supported (for reasons just explained), adding registry rebuild is already in the features queue (and is already added in BOA, btw).

The "Cannot redeclare class" is a result of having the same code in more than one places (in PHP memory, not on the disk, so registry rebuild can't really help). It is php-cli what still remembers already declared class, not Aegir database. Since the module doesn't really exist in two places (unless you have it also in sites/all/modules), the "Cannot redeclare class" error can't be caused by Aegir itself and there is nothing registry rebuild could do on this level. I think it is rather something to fix on the php.ini level. I guess it is realpath_cache_ttl what should be lowered in the php-cli ini file to avoid this. It is a pure guessing, but it would be interesting to try to reproduce the problem with something like realpath_cache_ttl=5.

Or maybe you have APC enabled for php-cli? What is the result of php -i | grep apc command?

I couldn't get the workaround in #2 to work with my omeg8.cc hosted site, but succeeded with following method:

• Created a new platform including entity_reference and removed from site.com/modules folder
• created a vanilla site on new platform
• copied files/ etc. over to new site
• exported database of old site via chive
• imported to new site via chive (backup_migrate backup/restore failed)
• newsite> drush rr

Hope this helps

By the way, this site was using entity_reference-1.0-rc3

I'm having a similar problem; though my error message was slightly different. The clone or migrate failed when the new site couldn't bootstrap due to a missing 'site'/modules/entity/includes/entity.inc file.
Interestingly the address of the old site modules dir. was used inside the new platform.
Like so: 'NEW_PLATFORM/sites/OLD_SITE/modules/entity/includes/entity.inc'

I tried the fix in #2 but it wasn't sufficient. Perhaps because I have modules requiring entityreference? So took it step further.

1. Backup site in Aegir
2. Disable all entity related modules.
   $ drush dis entity
3. This couldn't disable entityreference as it's required so I used the drush sql-cli hack from #2
   

   drush sql-cli
   mysql> update system set status=0 where name = 'entityreference' and type='module';
   mysql> exit

4. Delete all entity* modules on BOTH the hub (and manually on the spoke, as 'verify' didn't remove them)
   $ sudo rm -R modules/entity*
5. Update the db, clear cache and run cron, in an attempt to rebuild the registry without 'drush rr': $ drush updb; drush cc all; drush cron -v
6. Clone via the Aegir GUI - Success!
7. $ cd /path/to/NEW_SITE
8. Download and enable all the relevant modules:
   

   $ drush en entity, draggableviews, entityreference_prepopulate, entityreference_view_widget, field_collection, views_bulk_operations
   $ drush dl entityreference_prepopulate, entityreference_view_widget
   $ drush en entityreference_prepopulate, entityreference_view_widget

9. Give it the drush once-over:
   $ drush updb; drush cc all; drush cron -v

That worked for me. I'm not proud of it... but it worked.

This patch helped us in many issues related to this module: http://drupal.org/node/1459540#comment-6810146

I tried the patch from: http://drupal.org/node/1459540#comment-6810146 but we are still seeing the same error on another site for my specify variation of the issue;
when I clone (or migrate)
site.domain.com on prod-drupal-7.17
to
site.dev-server.domain.com on dev-drupal-7.17
bootstrap's function _registry_check_code() is looking for the new site's copy of the includes/entity.inc with the old path.
require_once(/var/aegir/platforms/dev-drupal-7.17/sites/site.domain.com/modules/entity/includes/entity.inc): failed to open stream: No such file or directory bootstrap.inc:3084

The solution was cschaub's #2 above: http://drupal.org/node/1680000#comment-6272174
I also have entity and entityreference in my site's module folder.

@omega8cc in looking at your comments in #7 above, I wonder;
Could I avoid this issue by moving entity and entityreference into the platform?

I was reluctant to do that in my production platform for just 1 or 2 sites, while both entity and entityreference were in -dev, but now that we have full releases for each module, it maybe worth a try; although, Entity Reference View Widget is still in alpha... if it can live it in

I realize I continue to hijack this issue but my error does appear to share the same solution and entityreference is the only module that I've encountered this problem with, so if creating a new issue is recommended, I can do that. Whether I would post it here or in the provision queue is to be determined.

A little more info on my issue:
We have confirmed that if you clone or migrate (with a new name) on the same platform there is no issue, as the path to the old entity.inc is still accessible to the new site.

Additionally, migrating to a new platform while keeping the exact same name does work.
Which presents an interesting GUI-only workaround:

1. Clone your site (with a new name) to the same platform
2. Migrate that new site (with no name change) to a different platform
3. Repeat step 1, if you need to change the name of your freshly migrated site.

No drush sql-cli or drush rr required.

@ _vid That is why BOA includes registry-rebuild as a part of every verify task, which helps when you are using sites specific space sites/foo/modules instead of platform specific sites/all/modules. Still, using site specific space may cause this kind of problems sometimes, so we don't recommend it. Also, renaming the site during migration between platforms is another recipe for disaster. I would recommend to study recipe #5 at: http://omega8.cc/the-best-recipes-for-disaster-139#fail-e and also discussions linked there. Our modified Aegir version installed by BOA includes extended inline help which helps to understand this better and avoid issues.

@omega8cc; Thanks for your response. BOA has some nice features.

We confirmed that moving entity and entity reference into the platform level avoided this problem.

For anyone else who's curious our steps were:

1. Navigate to the new platform.
2. $ cd sites/all/modules;
3. Download entity and entityreference $ drush dl entity entityreference
4. Verify the platform
   

   ---

5. Navigate to the current platform
6. Repeat steps 2, 3 & 4
   

   ---

7. Navigate to the current site directory $ cd sites/SITENAME;
8. $ cd modules;
9. Remove the modules from the dir: $ sudo rm -R entity entityreference;
10. Run drush registry rebuild (which should fix broken references to the modules and update them) $ drush rr;
11. Verify the site
12. Migrate or clone

On a side note, we encountered one of the issues that comes with using registry rebuild: the feeds module needs to list its plugins in the info file or the site wont verify after registry rebuild. So we patched that and everything else was good. Interestingly there was commit fixing that in feeds years ago: http://drupal.org/node/1201638.

@_vid Good catch with broken again Feeds module. It already hit us a few times and I'm surprised that this patch is no longer there, so I have re-opened #1201638: Plugins should be listed in info file.

The patch in #1423778: Fatal error loading EntityReference_SelectionHandler_Broken should fix this issue. I had the same issue when importing an Aegir site backup into a new site.