You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a new deploy with a multisite installation, the multisite variable will create a new name for the sites/mysitename/ folder. This causes an error with the code registry, which means Drush can't bootstrap, and thus can't clear the cache, and the whole deploy process rolls back
PHP Fatal error: require_once(): Failed opening required '/home/aaimmta/domains/mnmusicteachers.com/code/staging/current/sites/mnmusicteachers.com/modules/contrib/entity/includes/entity.inc' (include_path='.:/usr/local/php5/lib/php') in /home/aaimmta/domains/mnmusicteachers.com/code/staging/releases/20111017151748/includes/bootstrap.inc on line 2913
You can get around this by doing a regexp replacement on the database, but it'd be nicer and safer if we could find some sort of variable or method that protects our DB a bit more than simply replacing all instances in the DB. Ideally we'd rebuild the registry, though most ways I can find to rebuild the registry require Drupal to bootstrap. So we have a problem where Drupal can't bootstrap because the registry is wrong, and we can't fix the registry because Drupal can't bootstrap.
When creating a new deploy with a multisite installation, the multisite variable will create a new name for the sites/mysitename/ folder. This causes an error with the code registry, which means Drush can't bootstrap, and thus can't clear the cache, and the whole deploy process rolls back
PHP Fatal error: require_once(): Failed opening required '/home/aaimmta/domains/mnmusicteachers.com/code/staging/current/sites/mnmusicteachers.com/modules/contrib/entity/includes/entity.inc' (include_path='.:/usr/local/php5/lib/php') in /home/aaimmta/domains/mnmusicteachers.com/code/staging/releases/20111017151748/includes/bootstrap.inc on line 2913
You can get around this by doing a regexp replacement on the database, but it'd be nicer and safer if we could find some sort of variable or method that protects our DB a bit more than simply replacing all instances in the DB. Ideally we'd rebuild the registry, though most ways I can find to rebuild the registry require Drupal to bootstrap. So we have a problem where Drupal can't bootstrap because the registry is wrong, and we can't fix the registry because Drupal can't bootstrap.
There may be some workarounds to this. http://drupal.org/project/registry_rebuild is a module for rebuilding the registry for these types of situations, so maybe we can automatically download this and/or write a script based on it. There's also a method to rebuild the registry in Drupal's API: http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/registry_rebuild/7. We might be able to use something from there to create a workaround.
The text was updated successfully, but these errors were encountered: