Drush 9.2 - not working well / not installing with Composer

Question

I am using Ubuntu 17.10 running Apache 2.4 on a Vultr instance. Using virtual host for my.example.com website. Installed Drupal 8.5.1 per recommended Drupal-Composer/Drupal-Project. Apache docroot points to the "web" folder containing Drupal core (ie, where Drupal's update.php lives, among other things). The project root folder is one level up, containing the composer.json file.

File permissions: the project root folder itself is owned by user:www-data; same for Drupal root (web, and below). Drupal status is fine. It looks like Composer installed the /vendor folder [in the project root] as user:user.

I have seen so many errors, it's hard to know where to start. So far I have not discovered any underlying logic to them. The goal is simple: to get Drush working on my install, which is nothing special. Even on Windows, I can get Drush half-working.

1. After the install, Drush was at least recognizing its own existence. (At one point, I had the drush.phar helper globally installed, per the instructions from that website.) But "drush status" was claiming that it couldn't find Drupal -- even with the -uri flag, and even with the alias set up in example.site.yml contained in /project-root/drush/sites.

Drush status was looking at something that pointed to a deleted docroot folder, but I couldn't find the relevant config, and the only possibility was a path entry in that section of the composer.json file. Which I fixed, but that didn't help Drush.

2. Per the Drush docs, I tried running the drush command from Drupal root, pointing to /vendor/bin; and also in the /vendor/drush/drush folder. Getting permission denied in all cases. [Why? I'm the user running the command, in folders that I own as the user! Does Drush need www-data group permission?]

Adding a path command to ~/.profile [the Ubuntu file for .bash_profile] didn't help.

3. The permission denied error was in addition to the error re "command not found" -- when I'm in the very folder where I know the command file is located. I tried "chmod +x" on both the /vendor/bin version of drush, and the vendor/drush/drush/ version [just the "drush" single word file, not the "drush.php" file], but that didn't solve the problem. I reverted those back.

[And why is the folder structure so convoluted? Why the middle /drush?]

4. So, then, I thought that maybe it was a Drupal-Composer issue. So composer did allow for removal of drush/drush. And I deleted all the left-behind drush folders in my user home and in the project folder.

5. Went to re-install Drush using Composer, per the Drush install docs: "composer require drush/drush"

Which fails for me. The main culprit seems to be a symfony/var-dumper conflict [many versions] with symfony/http-kernel [many versions] -- it's several screens full of the attempted reconciliation, with this conclusion:

• Can only install one of: symfony/var-dumper[v3.4.8, v4.0.8].
• Installation request for symfony/var-dumper (locked at v4.0.8) -> satisfiable by symfony/var-dumper[v4.0.8].

updating for symfony/http-kernel (with dependencies): nothing to update

updating for symfony/var-dumper (with dependencies): nothing to update

In composer.lock, the entry for SHK does have a "conflict" parameter that mentions SVD. But I don't know how to fix that [if that is in fact the source of the "lock" statement above].

I run a simple website, so probably don't need Drush to move to D8 -- except that others seem to get it working and find it helpful -- and I'd like to join that club.

Answer 1

Thanks for the replies. Managed to get things working:

1. I created a new folder (drushtest), and ran composer init to create a drush-only project (myname/drush). Init runs an interactive series of question to create a valid composer.json (with only require: drush/drush [and a version constraint]).

2. Ran Composer to install, and it pulled down Drush and its dependencies.

3. Then went to remote server, and copied to /vendor/bin, the two drush files, and to /vendor, the various folders that were in my Drush-only install versus what was already on the remote folder.

4. Deleted the existing composer.lock. In require section of composer.json, added drush/drush: ^9.2 [with appropriate quote marks], and ran composer update. Which worked fine. [I still don't understand the effect of .lock on .json, but I guess we're all learning in the new Drupal 8 way.]

5. To keep things still simple, went to my Drupal folder (web), and (per Drush docs) ran Drush: "../vendor/bin/drush" -- the first time this generated a shell error re no permission. So ran that again under sudo, and got a no command error. Third time lucky, applied "chmod u+x" to that path-file, and Drush sprang to life, and even identified the correct Drupal installation (with all associated info that one expects when Drush is working) without an alias file. Hurrah!

6. More on file permissions: for ../vendor/bin/drush, added the x flag to the group (permissions are now 754), and can run that command without sudo (under my user name). Which I still find odd, in that my user is the owner (with rwx), and the user:group info is: user:user. But I'm quite new to Linux.

7. File permissions, again: With the above, commands like drush status worked, but running (as the user) drush cc (or cr) gave an error that pointed to another file permissions issue. (Sudo could run those commands OK, but it would be weird to use sudo for some drush commands and not for others -- and who could remember.) Which traced to: in the /home/user folder, there is a hidden .drush folder [with a factory subfolder containing a bunch of php command files]. The install process had set ownership of that to root:root. There is more than one way to handle this, but for now I changed ownership (chown) to user:user, and that at least allows drush cr to work.