r00t
r00t

Reputation: 111

Upgraded Drush 8 to 9 Site Alias Not Working

I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:

drush @self(or @local) list and I get some commands and this statement at the end:

[NOTE] Drupal root not found. Pass --root or a @siteAlias in order to see Drupal-specific commands.

Doing drush @local(or @self) cr returns:

In BootstrapHook.php line 32: Bootstrap failed. Run your command with -vvv for more information.

With -vvv:

Exception trace: at /app/vendor/drush/drush/src/Boot/BootstrapHook.php:32 Drush\Boot\BootstrapHook->initialize() at /app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34 Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook() at /app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27 Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize() at /app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145 Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at /app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289 Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at /app/vendor/symfony/console/Command/Command.php:221 Symfony\Component\Console\Command\Command->run() at /app/vendor/symfony/console/Application.php:1005 Symfony\Component\Console\Application->doRunCommand() at /app/vendor/symfony/console/Application.php:255 Symfony\Component\Console\Application->doRun() at /app/vendor/symfony/console/Application.php:148 Symfony\Component\Console\Application->run() at /app/vendor/drush/drush/src/Runtime/Runtime.php:118 Drush\Runtime\Runtime->doRun() at /app/vendor/drush/drush/src/Runtime/Runtime.php:49 Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72 require() at /app/vendor/drush/drush/drush:4

drush status:

PHP binary    : /usr/local/bin/php
PHP config    :
PHP OS        : Linux
Drush script  : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp    : /tmp
Drush configs : /root/.drush/drush.yml
                /app/vendor/drush/drush/drush.yml
                /app/drush/drush.yml
Drupal root   : /app

self.site.yml:

local:
  root: /app/docroot
  uri: example.lndo.site

Can someone please point me in the right direction?

Upvotes: 0

Views: 3146

Answers (2)

JDDoesDev
JDDoesDev

Reputation: 386

I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why @r00t's answer works.

r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.

webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).

Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.

Here is the code from DrupalFinder::isValidRoot()

foreach ($json['extra']['installer-paths'] as $install_path => $items) {
    if (in_array('type:drupal-core', $items) ||
        in_array('drupal/core', $items) ||
        in_array('drupal/drupal', $items)) {
        $this->composerRoot = $path;
  // @todo: Remove this magic and detect the major version instead.
  if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
    $install_path = '';
  } elseif (substr($install_path, -5) == '/core') {
    $install_path = substr($install_path, 0, -5);
  }
....

Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.

I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.

TL;DR:

If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.

Upvotes: 3

r00t
r00t

Reputation: 111

Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer. My composer.json file name went from: "name": "drupal/drupal", to: "name": "drupal-composer/drupal-project",

I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.

Upvotes: 11

Related Questions