Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drush 9 site-install with drupalvm not finding sites-subdir on single site install #3495

Closed
dgpalmer opened this issue Apr 3, 2018 · 8 comments

Comments

@dgpalmer
Copy link

dgpalmer commented Apr 3, 2018

Hi,

I am using DrupalVM with Acquia BLT for my local development environment. This has been working well until I updated to BLT 9 & Drush 9 last week. When I try to build my VM or install drupal via drush, drush site-install cannot find the sites subdir and gives me an error upon installation.

For example with Drupal VM I get this:

TASK [geerlingguy.drupal : Install Drupal with drush.] *************************
fatal: [umgch]: FAILED! => {"changed": true, "cmd": ["/var/www/umgch/vendor/drush/drush/drush", "site-install", "standard", "-y", "--root=/var/www/umgch/docroot", "--site-name=UMG Content Hub", "--account-name=admin", "--account-pass=admin", "--db-url=mysql://drupal:drupal@localhost/drupal"], "delta": "0:00:00.205538", "end": "2018-04-03 17:54:38.336713", "msg": "non-zero return code", "rc": 1, "start": "2018-04-03 17:54:38.131175", "stderr": " [error] Could not determine target sites directory for site to install. Use --sites-subdir to specify. ", "stderr_lines": [" [error] Could not determine target sites directory for site to install. Use --sites-subdir to specify. "], "stdout": "", "stdout_lines": []}

If I try to install it via drush, see my drush status to see "sites/default" site path.
$ drush @umgch status
Drupal version : 8.5.1
Site URI : http://umgch.vm
DB driver : mysql
DB hostname : localhost
DB port : 3306
DB username : drupal
DB name : drupal
Database : Connected
Drupal bootstrap : Successful
Default theme : stark
Admin theme : seven
PHP binary : /usr/bin/php7.1
PHP config : /etc/php/7.1/cli/php.ini
PHP OS : Linux
Drush script : /usr/local/bin/drush
Drush version : 9.2.3
Drush temp : /tmp
Drush configs : /var/www/umgch/vendor/drush/drush/drush.yml
/var/www/umgch/drush/drush.yml
Install profile : lightning
Drupal root : /var/www/umgch/docroot
Site path : sites/default
Files, Public : sites/default/files
Files, Private : /var/www/umgch/files-private
Files, Temp : /tmp

$ drush @umgch site-install
[error] Could not determine target sites directory for site to install. Use --sites-subdir to specify.

But If I pass in the sites-subdir=default, it works fine...

$ drush @umgch site-install --sites-subdir=default

You are about to DROP all tables in your 'drupal' database. Do you want to continue? (yes/no) [yes]:

I have never had to pass in the "default" sites directory before. Why do I have to now? Am I doing something wrong?

For what it's worth, if you create a fresh blt project

composer create-project --no-interaction acquia/blt-project tests

Run blt vm the first time, then vagrant destroy, and then change a value in the box/config.yml to install drupal (line 60 "drupal_site_install: false" , change false to true so it installs drupal with ansible), When you run blt vm again now iwth the drupal_site_install: true, it will complain about the sites-subdir missing.

How can I get past this without passing in the sites-subdir? I am just using a single site in the default folder...

Thanks,
Donovan

@weitzman
Copy link
Member

weitzman commented Apr 3, 2018

You have to pass --sites-subdir in situations where you did not have to in Drush 8. Its happens when you pass a uri. Its fixable but low priority. Until then, pass --sites-subdir=default or use Drush config to always set that.

@dgpalmer
Copy link
Author

dgpalmer commented Apr 3, 2018

Thanks Moshe, at least I'm not going crazy. :)

@bkosborne
Copy link

Note that passing --sites-subdir on the command line works, but specifying it in the drush.yml file as a config option doesn't work. The code that extracts it is here:

        $dir = $commandData->input()->getOption('sites-subdir');
        if (!$dir) {
            // We will allow the 'uri' from the site alias to provide
            // a fallback name when '--sites-subdir' is not specified, but
            // only if the uri and the folder name match, and only if
            // the sites directory has already been created.
            $dir = $this->getSitesSubdirFromUri($root, $aliasRecord->get('uri'));
        }

Maybe that code is not compatible with specifying the option in the alias file?

@weitzman
Copy link
Member

I cant think of a reason why that option would not load from config provided by a site.yml or drush.yml file.

@bkosborne
Copy link

weird - maybe something with my setup then

@zaporylie
Copy link
Contributor

I'm having a similar problem with setting sites-subdir. This doesn't work for me (drush.yml):

# This section is for setting global options.
options:
  # Not recommended if you have more than one Drupal site on your system.
  sites-subdir: 'default'

I actually think none of the options in this section works - https://github.com/drush-ops/drush/blob/master/examples/example.drush.yml#L74-L85

neclimdul added a commit to neclimdul/drush that referenced this issue Jun 20, 2018
Look in config for sites-subdir in addition to input.
neclimdul added a commit to neclimdul/drush that referenced this issue Jun 20, 2018
@weitzman
Copy link
Member

Setting the option via drush.yml is working for me. It has to be set as a command-specific option like below:

# This section is for setting command-specific options.
command:
  site:
    install:
      options:
       sites-subdir: 'example.com'

@neclimdul
Copy link
Contributor

So that does allow a workaround site install failing when a uri exists. Should I open a follow up to fix the underlying bug that it can't fallback to the default directory?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants