Drush 9 support

@Grimreaper The challenge is going to be supporting Drush 8.x and Drush 9.x. I might need to refactor all the existing drush commands and move as much of the business logic as possible into a reusable service.

Config Split is great an example. If anyone else has examples of modules that support Drush9 and DrupalConsole, please post them here.

@NickWilde Thanks. Ping me on Drupal Slack if you have any questions.

Still, rough and needs more testing (haven't got to back-testing the changes on the old Drush code.
However, I'm probably not going to get more work on this done for a few days so here's my WIP.

@Nick Wilde No problem. It is a good start.

I think we need to look at http://cgit.drupalcode.org/config_split/tree/src/ConfigSplitCliService.php and consider moving DrushHelper.php into WebformCliService.php service. The huge perk of a using a service is people can extend it.

Okay, this is now ready for a solid review/testing.
A few notes:
Drush make has been removed in Drush 9.x. Running `drush wfld` will print an error message to that affect.
webform-docs I didn't really test. I'll get tidy installed later and do so.
webform-generate I haven't done (haven't checked if the devel module has a Drush 9 option yet)
All other commands are converted with mostly equivalent functionality/interface.

My heart sank when I realized that drush make is no longer supported, partially cause I like the simplicity of Drush's YAML make file vs composers JSON files and secondly because my main client is on D8 but they are not yet ready to stop using Drush make.

Anyway, I need to setup my system to support Drush 8 and 9 concurrently. I am sure it is no problem. I am trying to take a much-needed break for the rest of the year. This will be one of my first major tasks of the New Year.

@NickWilde Thanks for helping push this forward and happy New Year.

I am going to start reviewing this patch.

I am seeing maintainability issues between the Drush 8 and 9 commands because there are too many changes being made when the Drush 8 commands are being converted to Drush 9.

For example...

Drush 8 uses `drush webform-export WEBFORM_ID` and Drush 9 is now using `drush webform-export --webform-id=WEBFORM_ID`
The `drush webform-purge` command now has dedicated drush 8 and 9 code.

There needs to be a solid bridge between Drush 8 and Drush 9.

I also think the Drupal community needs some code generation tools to help with the conversion. We should be able to use webform_drush_command() to generate a complete scaffold for the WebformCommands.

So far no one has come up with generic helper/bridge class that makes it easy to port and maintain Drush 8 and Drush 9 commands.

@NickWilde I really appreciate you starting to work on this. I might have to reapproach this problem and solution. I am absolutely going to use your code as a reference.

The attached patch uses some PHP magic to create the central CLI service that supports both Drush 8 and 9. There is now a Drush command to generate webform.drush.inc and WebformCommands. My goal is to get a working and maintainable MVP.

"First do it, then do it right, then do it better - this is my mantra for successfully getting things done. It's all about the iteration."
https://twitter.com/addyosmani/status/314785735171518464?lang=en

@NickWilde I am sorry that I did not scope out this work before letting you start working on it. The lesson I learned is to push everyone including myself to estimate before taking on any big issue/ticket.

I hope once you review the patch and change record you can see how my approach makes it easier for us to maintain support for Drush 8.x and 9.x. I also made very few changes to the original Drush commands to prevent any regressions.

Besides my apology, I owe you a beer.

Fixing drush webform-libraries-download.

@Grimreaper Thanks for the review and suggestions.

Here is a new patch. I also updated the branch.

@Grimreaper Are all the existing webform drush commands working as expected via Drush9.

Yep both those commands are working as expected.

I forgot to port the drush webform_scheduled_email_cron command.

I tested it and I don't expect there to be a lot of people using it.

I committed that patch and we should make additional improvements as needed.

I'm getting the following error when trying to download the libraries.

drush webform:libraries:download
Downloading https://download.ckeditor.com/autogrow/releases/autogrow_4.7.2.zip
Extracting to /home/user/Work/Sites/d8.com/libraries/ckeditor.autogrow
 [error]  Unknown method/function 'drush_tarball_extract'.

What version of Drush do you have installed?

drush --version

I figure out the issue is 9.0.0-rc2. It appears that drush 9.x is going to be moving target for a little while.

The attached patch fixes the missing legacy functions and removes a temporary workaround for 9.0.0-rc1.

I committed the patch. Please download the latest dev release to review.

The commands are working and now I'm recieving the following php error.

[warning] rename(): The first argument to copy() function cannot be a directory WebformCliService.php:701

It appears to be related to this php bug which descibes the following workaround.

exec("mv ".escapeshellarg($strOldPath)." ".escapeshellarg($strNewPath));

It was also subject of a Drupal issue here which @jpstacey resolved. The conditions are the same for me as described there, my /tmp directory is on a different volume then my /var/www directory.

Let's use core's file_unmanaged_move() function instead.

I am going to just commit the attached patch. Please download the latest dev release to review.

With the current patch i had to make sure that allow_url_include = On was set in php.ini otherwise I was getting:

Downloading https://download.ckeditor.com/autogrow/releases/autogrow_4.7.2.zip
 [warning] fopen(): SSL: Connection reset by peer WebformCliService.php:680
 [warning] fopen(): Failed to enable crypto WebformCliService.php:680
 [warning] fopen(https://download.ckeditor.com/autogrow/releases/autogrow_4.7.2.zip): failed to open stream: operation failed WebformCliService.php:680
Extracting to /home/user/Work/Sites/d8/libraries/ckeditor.autogrow
 [error]  Unable to unzip /tmp/drush_tmp_1515696941_5a57b32d0e7a2/autogrow_4.7.2.zip.

After changing php.ini and restarting apache, I now get the following error. I can verifiy the files are downloaded and extracted to this point.

Downloading https://download.ckeditor.com/autogrow/releases/autogrow_4.7.2.zip
Extracting to /home/user/Work/Sites/d8/libraries/ckeditor.autogrow
 [error]  The specified file /tmp/drush_tmp_1515700541_5a57c13dc420b/autogrow could not be moved to /home/user/Work/Sites/d8/libraries/ckeditor.autogrow.

@dimmech I am unable to replicate the error. Still, I think there some room for improvements.

The attached is a patch uses native Drush 9 functions with the mv command as a backup. Does this help?

What OS and PHP version are you using?

Does the /libraries directory exist?

Did you check the directories file permissions?

Using Ubuntu 16.04 w/ PHP 7.0, /libraries exsist - yes, file permissions - yes.

This patch worked, all library files are there, nice work! Looks like the cross-volume php bug will still error on the mv function but I'm sure you'll decide how to handle that.

This was the output:

Downloading https://download.ckeditor.com/autogrow/releases/autogrow_4.7.2.zip
Extracting to /home/user/Work/Sites/d8/libraries/ckeditor.autogrow
Attempting to use 'mv' to move files.
mv: cannot stat '/tmp/drush_tmp_1515710188_5a57e6ec16522/autogrow': No such file or directory

Thanks

For now it feels safer to not use the 'mv' command since I can't replicate the error/issue.

Attached is the same patch without the 'mv' command.

I committed the last patch.

Hi, i reopen because i have this error with drush 9

  [Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]
  The service "webform.commands" has a dependency on a non-existent service "webform.cli_service".

Can you help me please ?

thanks

Did you clear drupal's cache?

Yes :(

In fact... "drush cr" is ok, but not "drush status", "drush entup" broken too

A fully update with composer and dependencies to RC4 solved the problem.

Thanks ;)