So long, drush cache-clear
In previous Drupal versions, whether you were - for instance - moving your site from one host/stage to the other or wanted to see your latest CSS or JS changes applied, using cache-clear (all) was your best bet and the first step into troubleshooting a site.
In Drupal 8, things have changed. Per #2097189 - Add a rebuild script we have a new function called drupal_rebuild() that can be used to invoke a site rebuild for clearing Twig’s dumped php caches, regular caches and the DIC (Dependency Injection Container). There’s a new Drush command for that called cache-rebuild.
Excerpt from cache.drush.inc
/** * Rebuild a Drupal 8 site. */ function drush_cache_rebuild() { require_once DRUPAL_ROOT . '/core/includes/utility.inc'; // drupal_rebuild() calls drupal_flush_all_caches() itself, so we don't do it // manually. drupal_rebuild(); // As this command replaces `drush cache-clear all` for Drupal 8 users, clear // the Drush cache as well, for consistency with that behavior. drush_cache_clear_drush(); }
Hello config commands!
Do you remember how the variable-get and variable-set commands allowed you to query/edit configuration on a Drupal 5/6/7 site? This is gone in Drupal 8 (read more) as we’ve shifted to the Configuration Management Initiative (aka CMI) instead. CMI provides a central place for modules to store (portable) configuration data. In other words, whether you’re willing to update a simple configuration such as the site name or manage much more complex configuration entities (content types, views, form modes…), this is all handled by the Configuration API. But wait a minute? How is this related to Drush? Enter config commands.
Up to Drush 6.x |
New in Drush 7.x |
---|
variable-get |
config-list |
variable-get name |
config-get config-name key
e.g. $ drush config-get system.site page.front
|
variable-set name value |
config-set config-name key value
e.g. $ drush config-set system.site page.front welcome
|
Drush 7 also provides a very neat config-edit command which allows you to edit any active configuration object on the fly.
$ drush @sitename.env config-edit Choose a configuration. [0] : Cancel [1] : bartik.settings [2] : block.block.bartik_breadcrumbs [3] : block.block.bartik_content [4] : block.block.bartik_footer [5] : block.block.bartik_help [snipped]
Just select a file to edit by entering its numeric identifier. Once you save your modifications, Drush will do the heavy lifting for you and apply the changes to your active configuration directly.
But there’s more! You can fully export your active configuration with the config-export command. What this will do behind the scenes is to export your Drupal 8 configuration stored in the database to plain YAML files in your staging
directory.
In the below example, we run the config-export command (in quiet mode) to dump the active configuration to YAML files. Note that Drush warns us if the target dir is non-empty.
$ cd path/to/drupal/sites/default/files/config_HASH/staging ; drush @sitename.env config-export -qy staging ; ls -l | wc -l ; ls | head -n5 168 bartik.settings.yml block.block.bartik_breadcrumbs.yml block.block.bartik_content.yml block.block.bartik_footer.yml block.block.bartik_help.yml
Conversely, you can synchronize the configuration and thus apply any modification with the config-import command:
$ drush @sitename.env config-import -y staging
Note that “staging” in both commands refer to the same directory but has a different meaning. For the config-export command it refers to the destination directory whereas for the config-import command it refers to the source directory instead. This can be overridden by defining a different key in the $config_directories
array in your settings.php
file.
If you’re interested to know more about CMI and how Drush can help with configuration workflows and deployments, please make sure to read our Moving Your Drupal 8 Configuration from Local to Server and Back (with video) and Drupal 8 Configuration Workflows using Git blog posts on the Acquia blog.
Are you excited, yet?
Drush 7 brings a few more gems. The one that I want to quickly talk about today is so called Boris. Simply put, it’s an interactive shell for typing and executing PHP commands, also known as a REPL (read-eval-print loop). Here it is in action. You can invoke Boris with the core-cli command or its convenient `php` alias.
$ drush @sitename.env php [1] sitename.env> echo "Hello from the Boris Shell!\n"; Hello from the Boris Shell! [2] sitename.env> $array = ['Do', 'you', 'like', 'it?']; // array( // 0 => 'Do', // 1 => 'you', // 2 => 'like', // 3 => 'it?' // )
If you want to dive into more Drush 7 goodness, check out Moshe Weitzman and Mark Sonnabaum’s joint session at DrupalCon Austin: Config commands, a Boris shell, Views support, and other new features in Drush 7.
We hope you like Drush 7 as much as we do and can’t wait to see what you build with Drupal 8.
Note: special thanks to Moshe Weitzman for reviewing this post.