Local synchronization for multisites

[bobbygryzynger]

One hole that still remains in BLT's support of multisite development are the local synchronization tasks.

Currently, they can only be run easily against the default site, even if run as, for instance,

blt local:sync -Dmultisite.name=not_default

The biggest stumbling block seems to be this section of local-sync.xml:

<drush command="sql-sync" alias="">
    <option name="structure-tables-key">lightweight</option>
    <option name="create-db"/>
    <option name="sanitize"/>
    <param>@${drush.aliases.remote}</param>
    <param>@${drush.aliases.local}</param>
</drush>

At present, there is no way to configure the aliases without overriding the drush.aliases variables directly. E.g,

blt local:sync -Dmultisite.name=not_default -Ddrush.aliases.remote=notdefault.remote -Ddrush.aliases.local=notdefault.local

While this works, it is cumbersome and error prone.

I think it would be better if BLT could facilitate defining different aliases for non-default sites (with the fallback being that everything is run against the default site).

#827 attempted to do some of this, but never got to the point that it could be incorporated. I'd be interested in hearing from others (paging @danepowell) who are using BLT in a multisite context. What would you see as a good solution to this issue? @grasmash suggested site-by-site files for defining values (which I'm not opposed to), but if all that is required are aliases, perhaps this isn't necessary.

I'd love to hear some thoughts as perhaps there's a solution to this issue that I'm overlooking.

[grasmash]

The current architecture would actually allow you to use a yml file per site.

E.g., create docroot/sites/secondsite/site.yml with:

drush
  aliases:
    remote: @myap.secondsite.test
    local: @myapp.secondsite.local
multisite.name: secondsite

Then execute blt local:sync -propertyfileoverride -propertyfile docroot/sites/secondsite/site.yml

You could wrap this with a bash script pretty easily:

#!/usr/bin/env bash
# $BLT must be set to absolute path for vendor/bin/blt.
"${BLT}" -propertyfileoverride -propertyfile docroot/sites/$1/site.yml "$@"

Then execute .myscript.sh secondsite local:sync

[danepowell]

I agree with @grasmash , I'd like to see all site-specific configuration get moved to individual yml files in the docroot/sites/*/ directories. What I'd like to improve is how developers reference different sites. Passing a yml file is a little awkward, but works for now, and the bash script could help. But I'd like BLT to be multisite-aware so that you could do something like blt local:refresh --site=foo.com and it will know to pull the aliases from the yml file in docroot/sites/foo.com.

On a related note, I'd also like to improve the multisite setup experience (see #1086 and #1087).

[bobbygryzynger]

I'd have no problem with the bash script approach if it were part of BLT. What I wouldn't want is for that to be on implementing projects to provide themselves and then have it start breaking setups when BLT starts migrating functionality to Robo or some other task runner. It seems like something that should be supported out-of-the-box.

@danepowell what are your thoughts about keeping the config files in blt/sites?

It's not that I don't think keeping them in docroot/sites/*/ is a good idea, but I would be worried about Drupal eventually scanning these directories for settings.php-style configuration and this then causing problems. But here the file could be namespaced to guard against this E.g, foo.blt.yml.

[grasmash]

I think we can make some pretty minor modifications to BLT to support the following syntax:

blt local:refresh -Dmultisite.name=secondsite

BLT would then look to see if docroot/sites/secondsite/site.yml exists, and if so, would load its properties to override the defaults.

How's that sound?

[danepowell]

Sounds good to me. Ping me if you want to coordinate work on this... I don't have any free cycles today but might next week.

[bobbygryzynger]

Sounds good to me too.

[bobbygryzynger]

@danepowell & @grasmash I made an attempt at this behavior in #1117.

@grasmash you're right that nothing dramatic needs to be changed to support the behavior, but one surprising change was needing to override drush.uri any time a non-default site is in play.

See here for instance.