Drupal Answers is a question and answer site for Drupal developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have projects configured with multisite configuration, with folder structure as follows: sites/local.domain,sites/staging.domain.com, sites/domain.com.

All is well, except for one detail: I cannot run drush from project root directory anymore. I need to cd up to the current configuration folder.

Is there a way around this?

share|improve this question

Try drush --uri=http://local.domain status from the root directory.

Also, you can create a file $HOME/.drush/aliases.drushrc.php, and define site aliases for each of your site. Then, drush @local status can be used.

Your aliases file would look something like this:

$aliases['local'] = array(
   'root' => '/path/to/drupal',
   'uri' => 'http://local.domain',
);
$aliases['staging'] = array(
   'root' => '/path/to/drupal',
   'uri' => 'http://staging.domain.com',
);
$aliases['live'] = array(
   'root' => '/path/to/drupal',
   'uri' => 'http://domain.com',
);

However, although it is off topic for your question, I must also mention that the multisite configuration you have set up here fails to meet the basic requirements for a viable dev -> test -> live workflow. In this configuration, your code is shared between all three environments. This means that when you update Drupal core on your dev site, the updated code will also be immediately applied to the live site, which affords no opportunity for testing. A propper dev -> test -> live workflow should use completely separate codebases for each environment, so that you may publish code on a controlled schedule.

Multisite can be useful in certain environments where you have a very large number of copies of the same code, e.g. separate live sites that want to share the same opcode cache. For simpler setups, it's easier to stick with single codebases for each environment.

share|improve this answer
    
Thanks for your feedback, currently the codebase is kept separate with git tags. Features and changes are merged onto dev branch, jenkins moniters dev for changes. When a change is detected it is merged onto stable, then tests and code sniffer runs. If all passes, stable is merged onto master and tagged. Deployment script push tags on staging / prod, again via jenkins. PS: I saw the -l parameter can also be used to target multisite configurations. Thanks again. – stefgosselin Feb 23 at 2:30
    
Sounds like you have separate checkouts of your code; that is fine. – greg_1_anderson Feb 23 at 4:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.