Manually managing your Drush aliases is usually the best choice, and the automatic alias generation is more of a convenience to help you get started. multisite or multiple codebases), or if you have any other specialized use case. I recommend you do this if you have more than one site in your VM (e.g. Note: You can disable Drupal VM's alias generation entirely by setting configure_drush_aliases: false in your Drupal VM config.yml. But if you work outside, on your host, then you'll have to make a decision on whether you want to stick to Drush 8 or move on to Drush Launcher and 'the new way of using Drush'. If you always work inside Drupal VM, there aren't many substantial changes you need to worry about. Drupal VM helpfully creates the config file if you don't already have one at ~/.drush/drush.yml: Note that Drush won't pick up custom global alias files like unless you also configure the new Drush config file to look in global paths. The aliases are configured similarly inside the VM (so you can use the same alias), but without the SSH connection details.ĭrupal VM defines these aliases in new Drush alias YAML files, inside ~/.drush/sites/. If you're outside the VM, you need to use a Drush alias to make sure Drush connects to the VM via SSH, then runs the command correctly inside.ĭrupal VM configures Drush aliases for you, for any hosts you have defined in apache_vhosts (or nginx_vhosts if that's your thing), and as an example, with all the default configuration, there's a global Drush alias defined, which you can use outside the VM (in your project folder) like drush cr. vagrant ssh or inside the Docker container), then you just use drush. Note that with Drupal VM, how you use Drush is affected by whether you're inside or outside the VM. Basically, installing Drush is as easy as composer require drush/drush, and then (if you have Drush Launcher installed), you can run drush while you're in your project's directory and Drush will 'just work'. There are so many reasons why this is a good idea (or in some cases the only way to get a working Drupal codebase), and one of them is the ease of integrating Drush with your Drupal site. If you haven't already, it's time to move your Drupal sites over to using Composer to manage the codebase. This blog post isn't about the why's of all the Drush 9 changes it's an explanation of how this affects Drupal VM, and how your workflow might (or might not!) be impacted by the Drush integration changes happening in Drupal VM 4.8. phar file), you now install Drush Launcher, and it detects and uses a site-local install of Drush (or a fallback version of Drush if you have one configured). And even the way you install Drush for system-wide use is much different-rather than installing a global copy of Drush (e.g. And global Drush aliases work a bit differently (I'll get to that soon). All the old standby's like drush cr and drush site-install remain and work as well as ever.īut things like using hook_drush_command() to register a new Drush command are radically altered-now you create annotated DrushCommands (see Porting Commands to Drush 9). It's now based on a number of smaller PHP libraries to provide things like CLI integration, command annotations, etc., and just like Drupal 8, the architecture behind the scenes has changed dramatically, while end-user changes have been (somewhat) minimal. Tl dr: Drupal VM 4.8.0 was just released, and it uses Drush 9 and Drush Launcher to usher in a new era of Drush integration!ĭrush has been Drupal's stable sidekick for many years even as Drupal core has seen major architectural changes from versions 4 to 5, 5 to 6, 6 to 7, and 7 to 8, Drush itself has continued to maintain an extremely stable core set of APIs and integrations for pretty much all the time I've been using it.īut as time has gone on, and the "getting off the island" philosophy has swept across much of the PHP world, Drush has jumped on that train for a major overhaul in Drush 9.
0 Comments
Leave a Reply. |