Command-line Drupal

  • 12,442 views
Uploaded on

Discovering Drush: …

Discovering Drush:
Drupal's Swiss Army Knife

Presented by Joshua Schroeder on April 9, 2010
at the Calgary Open Source Software Festival

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
12,442
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
214
Comments
1
Likes
14

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

  • By way of introduction, I am Joshua Schroeder.

    In 2009 I co-founded a web design and development company called Redwall Studios. We specialize in custom-built Drupal solutions for small and medium-sized business.

    I am also a developer at the University of Lethbridge, and have been heavily involved in introducing Drupal to our projects there since 2007.

    My educational background is in management. I have a degree in management information systems from the University of Lethbridge.
  • My Drupal experience began in late 2007 when I attended a Lullabot training workshop. Lullabot are among the premier Drupal consulting companies and are on the forefront of providing Drupal-specific training. If you are looking for such training opportunities, I would encourage you to visit their web site for more information.

    Since that time, I have been working nearly exclusively with Drupal 12 hours a day, 6 days a week. Along the way I have built two modules that have made their way into the Drupal.org contributions repository. One is a jQuery-enabled floating menu for site content managers, and the other is an API integration piece for Etsy.com, a marketplace for artisans.
  • Generally, you can find me around the web using the handle jdschroeder. These are some of the common places I hang out, and there is a more complete list on my web site. These slides will be available at the Slideshare page listed here.
  • This presentation should be at a reasonably accessible level; however, I did put it together with a particular target audience in mind.

    You will benefit the most from this presentation if you don’t feel out of your element at the command-line, and you have a basic understanding of Drupal.

    There isn’t any advanced shell or Drupal coding happening here. Our goal is to understand what Drush is, see it in action, and revel in its beauty.
  • Drush stands for Drupal Shell.

    It is not a module that needs to be installed on any site, but a collection of scripts that can be run on your server to execute tasks on your Drupal installation. This is important because Drush is independent of any particular Drupal installation and can be used on any Drupal site that is installed on the same server.
  • What exactly is it that makes Drush such an important tool in the Drupal developer’s tool kit?

    I expect that many developers are like myself in that they keep a terminal window open at all times. If you’re of that persuasion, you’ll probably also find Drupal at the command-line is just really convenient.

    Those of us using a lot of command-line utilities probably generally favour keyboard strokes over mouse gestures, too. Sometimes it’s just far easier to clear Drupal’s database cache with a few keystrokes than it is to click through to do it in the web interface.

    The real power of Drush often comes when you want to script mundane tasks. Migrating sites between servers and running cron jobs can be greatly simplified using Drush.

    Finally, keeping up with security updates can be a headache sometimes. Drush can take care of it for you. Now you don’t have any excuses.
  • Drush has some cool ease-of-use features to it as well.

    For starters, it knows what Drupal site you’re working on based on your present working directory. It doesn’t matter how many Drupal installations you have on your server; one installation of Drush looks after all of them.

    Drush also knows what version of Drupal you’re using, and it works with versions 5, 6, and 7. Again, no need to install different versions of Drush, and it doesn’t matter if all of your server’s Drupal installs are of the same version.


  • If you’re running Drupal, you probably already have the requirements covered.

    Drush runs on your server alongside your Drupal installations, so it is necessary to have shell access to your server.

    You will also need to have PHP compiled with the command line interface, since like Drupal, Drush is a PHP script. It requires PHP 5.2.
  • You can find the Drush package on its Drupal.org project page at drupal.org/project/drush

    As I was preparing my slides this week, RC3 of version 3.0 was posted as the current recommended release. The development team has hinted that a stable 3.0 release will happen before DrupalCon later this month.

    You can simply download a tarball from the project page and extract it somewhere on your server.
  • The readme file contained with Drush package gives pretty comprehensive information about how to install it.

    The installation process is quite simple:
    - make the Drush script executable
    - create a symlink from /usr/local/bin/drush to the Drush script, or create an alias in your bash profile

    Creating a symlink is useful if you are setting up Drush system-wide for multiple users. If you are installing Drush locally for development purposes, using an alias will suffice.
  • Drush configuration is handled by a drushrc file. A drushrc file can reside in any of several locations. A drushrc within your Drush folder will apply server-wide, while individual site settings can be configured with a drushrc file saved in your individual sites folder.

    Within your drushrc file you can configure path locations, ssh connection information, site aliases, checkout handling via CVS, database dump options, default command-specific options, and Drupal variable overrides. The site aliases and their associated path and ssh information are the settings that I have found most useful.

    There is an example drushrc file in the Drush package that documents the available configuration options available to you.


  • If you’re hanging out in the shell very much, this is going to look very straightforward to you, which is good, because it is.

    As you would expect, just typing ‘drush’ or ‘drush help’ will summon a help page and give you some documentation for deciphering the available options and commands.
  • Here we see the available options for the Drush script.
  • And a listing of commands. We will take a closer look at a bunch of these commands in just a moment.
  • A quick caveat worth mentioning: some commands require a certain version of Drupal. The site-install command, in particular is new to Drush and requires Drupal 7. Several others also require at least Drupal 6.
  • It’s only taken us 17 slides to get here. Now let’s find out exactly what Drush can do for us.
  • The status command provides you with some basic information about your current Drupal installation. This includes the root of the installation, what version of Drupal core it is running on, various paths, database information.
  • pm-download is the first of a number of “package management” commands. It downloads a project from the repositories at Drupal.org. This can be used to download Drupal core, contributed modules, and themes.

    The name to specify in the Drush command is the same as the project name as seen in the URL of the project’s page on Drupal.org.

    Additionally, you can specify a particular release if you do not want to use the current recommended release for your version of Drupal.
  • With pm-list we can see a complete list of all of the modules and themes that are available to our current Drupal installation, including what package they belong to, whether or not they are enabled, and what version we have available.
  • Once you have a module residing within your Drupal tree, you can enable it with the pm-enable command. As with the download command, you can specify multiple modules with a single command.
  • The opposite of pm-enable, pm-disable will disable a module from your site.

    This does not uninstall or remove the module from your site. Variables and configuration will not be wiped, so if you re-enable your module, any configuration will remain intact.
  • Unlike pm-disable, pm-uninstall does wipe the configuration settings and variables associated with the module. Uninstalling the module invokes the module’s uninstall hook, which can perform any required module-specific database clean-up.
  • The pm-update command backs-up your enabled modules and downloads their latest releases. After putting the files in place, it runs Drupal’s update.php script to make any necessary changes to the database schema.

    There is also a command called pm-updatecode that will download the latest versions of your modules, but it will not execute update.php.
  • This one was committed about an hour and a half before this session, so I’ve only been able to skim the code and not actually play with the command yet.

    This command will return the path to a given module or theme directory, or by default, the root of the Drupal installation.

    Here are a couple examples that would allow you to change the working directory to either the Drupal root, or the pathauto module folder.

    Alternatively you could create an alias for cdd (change Drupal directory).
  • In instances where you need to run the update.php script outside of the pm-update command, you can use the updatedb command. This will be useful if you have updated Drupal or any modules manually.
  • Drupal has an internal log module called watchdog. To list the most recent messages logged to watchdog, you can use the watchdog-show command.

    There are various types and security levels associated with watchdog messages that can be revealed using watchdog-list.

    You can also clean up the watchdog table by using the watchdog-delete command to clear out old entries.
  • At various times when developing or migrating sites, it can be useful to flush Drupal’s database cache. Cache-clear is one command that I have found very helpful for saving time while developing sites.

    Some modules add their own cache tables, and cache-clear will accept an argument specifying which cache to clear if you want to target a specific one.
  • Another useful command during development is cron. This command triggers Drupal’s cron script that is typically called via a crontab entry. This will handle things like flushing expired cache items and indexing items for the search system.
  • Drush’s rsync command allows you to use rsync to synchronize files between sites aliased in your drushrc.

    This command can be used to build deployment scripts to deploy from one environment to another.
  • The sql-dump command is very similar to executing mysqldump. Remember that Drupal works with multiple database platforms, so this works independently of the database you are using.

    This also has the advantage of drawing your username and password from your settings file. You can also set up your drushrc to exclude the content of certain tables (such as cache and watchdog).

    Naturally, you can write the output of sql-dump to a file or pipe it to another command.
  • In conjunction with the rsync command, sql-sync is powerful for deployment scripting. It uses rsync to copy databases between servers.

    This works the same as piping a mysqldump to a mysql command, but all of the configuration is taken from the drushrc file.
  • The site-install script allows for complete provisioning of new Drupal sites without ever having to complete installation in a browser window. Prior to this command, we could do some preliminary set-up with the settings file, but at a practical level, you still had to complete the installation through the web interface.

    As of Drupal 7, you can complete this process using site-install, specifying the installation profile and any of the settings that you would normally set during the install and configuration process.
  • The site-upgrade command will perform a major version upgrade of Drupal core and contributed modules. This command runs updatedb when it is complete.
  • And several more commands.

    php-eval allows you to run arbitrary php within a bootstrapped Drupal context

    variable-get and set allow you to control Drupal variables (for example, you could turn clean urls off with this for debugging purposes)

    search-index and reindex will index your content for the search module. Search-status will indicate how many items remain for indexing.

    sql-cli will enter the MySQL command line using Drupal’s database user.

    sql-conf outputs an array of sql configuration settings and sql-connect outputs a database connection string

    sql-query allows you to execute an arbitrary query on Drupal’s database
  • Not only that, but Drush can be extended by other modules that you have installed.

    The link here will display all of the Drupal projects that integrate with Drush, and a list of the notable ones is on the right.
  • Let’s take a few minutes and see Drush in action.
  • For a first example, let’s use Drush to download Drupal 7 onto our server and then rather than configuring our initial Drupal settings through the web interface we will use the site-install command.
  • Now let’s check the status of our Drupal installation, download a few modules and then enable them.

    I install pathauto on all of my sites, so let’s install that module, as well as path_redirect.
  • And now some various Drush tricks.

    We’ll start with a pm-list.

    Next we will take a look at the watchdog entries, delete the entries and view watchdog again.

    On to a sql-dump, and then outputting a sql-dump to a file on the server.

    Finally, we will clear the cache and run cron.
  • Drush can also accept additional extension commands. One of the more notable of these is drush_make.

    This allows you to specify a makefile defining a ready-made Drupal site that can then be built at the command line. Drush_make can be useful for things like distributing installation profiles.

    A popular example of that right now is Open Atrium, a Drupal-based intranet distribution. There is some information on the Open Atrium web site on how to build it from a makefile. Let’s take a look at how that would work.
  • This is what is contained in the makefile for building Open Atrium. Quite simply, it is instructing Drush to download Drupal and the Open Atrium installation profile.
  • By running the makefile here, Drush is downloading Drupal, the required modules, and the installation profile required. Now when we visit the installation page, Open Atrium is listed as an installation profile, and we can go ahead and complete this installation as we would with any standard Drupal installation.
  • Just like that we’ve got an installation profile installed and pre-configured with a bunch of intranet features and some slick themes.
  • We can put some of these Drush concepts together to concoct a common Drupal workflow to save time when setting up sites.

    One way to do this would be to write a makefile that specifies the various modules, themes, and external libraries that would like to have included with our Drupal core. Drush_make will take care of downloading all of these for us.

    Assuming we are dealing with at least Drupal 7, we could then use site-install to complete the set-up of the site.

    Finally, we can enable some common modules that we want to use with this standard profile. As you can see, this is easily scriptable.
  • A particular use case that I have used Drush to address recently has been deploying sites from a development server to a production server: a common workflow task for Drupal shops.
  • To begin with, we can create sites on our development server using dl, si, and en.

    Then once we are ready to deploy our completed development site onto a production server, we can use sql-sync and rsync to push the site out.

    It’s also easy to update the production site using sql-sync and rsync again.
  • To begin with, we can create sites on our development server using dl, si, and en.

    Then once we are ready to deploy our completed development site onto a production server, we can use sql-sync and rsync to push the site out.

    It’s also easy to update the production site using sql-sync and rsync again.
  • To begin with, we can create sites on our development server using dl, si, and en.

    Then once we are ready to deploy our completed development site onto a production server, we can use sql-sync and rsync to push the site out.

    It’s also easy to update the production site using sql-sync and rsync again.
  • To begin with, we can create sites on our development server using dl, si, and en.

    Then once we are ready to deploy our completed development site onto a production server, we can use sql-sync and rsync to push the site out.

    It’s also easy to update the production site using sql-sync and rsync again.

  • I’ll take the next few minutes to field any questions you might have about Drush or Drupal.

    [Questions, and hopefully some answers]

Transcript

  • 1. $ command-line drupal Discovering Drush: Drupal’s Swiss Army Knife Joshua Schroeder April 9, 2010 Calgary Open Source Software Festival 1
  • 2. Who am I? • Joshua Schroeder • Co-founder and Drupal architect at Redwall Studios [www.redwall.ca]. • Web developer at the University of Lethbridge [www.uleth.ca]. • B.Mgt. (Information Systems) from the University of Lethbridge. 2
  • 3. Drupal experience • Trained by robots [www.lullabot.com]. • Full-time Drupal developer for 2.5 years. • Maintainer of two modules in the Drupal contributions repository. 3
  • 4. Where to find me • www.jdschroeder.ca • www.twitter.com/jdschroeder • www.slideshare.net/jdschroeder • www.drupal.org/user/202642 • jdschroeder in various Drupal IRC rooms 4
  • 5. General assumptions • Who will get the most out of this presentation. • You are reasonably comfortable using command-line utilities. • You know the general concepts of Drupal. • See what Drush can do and how to use it. 5
  • 6. What is Drush? • Drupal shell • Not a module • Collection of scripts that allow you to perform Drupal tasks from the command line on your web server. 6
  • 7. So why should I care? • Do you spend a lot of time at a command prompt? • Accomplish admin tasks quicker than via the web interface. • Scriptability of common tasks. • Keeping up to date. 7
  • 8. All that, and smart, too • Drush knows what site you’re working on. • Drush knows what version of Drupal you are using. 8
  • 9. Requirements • To be run alongside your Drupal installations (i.e. on a server). • Requires command-line access to PHP 5.2. 9
  • 10. Getting Drush • http://drupal.org/project/drush • As of April 6, current recommended release is 3.0rc3. • Download and extract on your server. 10
  • 11. Installing Drush • See README.txt • Make the Drush script executable. • Create a symlink in /usr/local/bin or create an alias. 11
  • 12. Configuration • Global and site specific drushrc.php files • Configures path locations, site aliases, checkout handling, database dump options, command-specific options, and variable overrides. • example.drushrc.php is included. 12
  • 13. Using Drush • $ drush [options] <command> 13
  • 14. 14
  • 15. 15
  • 16. Did I say all versions? • Not all commands are available to all Drupal versions. • site-install requires Drupal 7, several other commands require at least Drupal 6. 16
  • 17. Drush commands what exactly does it do? 17
  • 18. status (st) • Basic information about your Drupal site. 18
  • 19. pm-download (dl) • Download a project from Drupal.org. • Can specify releases. # download Drupal core drush dl # download cck module and zen theme drush dl cck zen # download the D6 2.x development branch of backup/migrate module drush dl backup_migrate-6.x-2.x-dev 19
  • 20. pm-list (sm) • List downloaded modules and themes. 20
  • 21. pm-enable (en) • Enable a downloaded module on your site. # Enable the CCK module and backup_migrate drush en content backup_migrate 21
  • 22. pm-disable (dis) • Disables a module on your current site. • Does not uninstall the module. • Variables and configuration will not be deleted. 22
  • 23. pm-uninstall • A step beyond pm-disable. • Triggers the module’s uninstall hook to delete configuration and variables, drop module-specific tables, and any other necessary clean-up. 23
  • 24. pm-update (up) • Downloads and installs the latest release of your enabled modules. • Runs Drupal’s update.php script. • pm-updatecode variant doesn’t run update.php. 24
  • 25. core-directory (cd) • New for today! • “Return path to a given module/theme directory.” • cd `drush cd` • cd `drush pathauto` (alias to cdd pathauto) 25
  • 26. updatedb (updb) • Executes Drupal’s update.php script. • If site or module updates have been applied manually, you can run this instead of the web interface to update.php. 26
  • 27. watchdog-show (ws) • Displays messages from Drupal’s internal log table, watchdog. • Can also list types and security levels using watchdog-list. • Clear watchdog content using watchdog- delete. 27
  • 28. cache-clear (cc) • Flush Drupal’s database cache. • Easily my most frequently used command. • Major time saver during development. • Can specify which cache tables to clear, but typically is used as cache-clear all. 28
  • 29. cron • Runs all registered cron hooks. • Usually triggered by crontab, the cron script handles things like search indexing and cache flushing. • Another handy command during development. 29
  • 30. rsync • rsync the Drupal tree between servers using ssh. • Very useful when writing deployment scripts or for backing-up code. 30
  • 31. sql-dump • Dump the contents of the database in SQL query format (same as mysqldump). • Draws username/password from your site settings. • Ability to exclude some tables (like caches). • Output can be written to a file or piped to another command. 31
  • 32. sql-sync • Uses rsync to copy databases between servers. • Kind of like doing a mysqldump | mysql. • Another useful command for doing site deployments. 32
  • 33. site-install (si) • Complete a Drupal installation. • Can use a specified installation profile. • Requires Drupal 7. 33
  • 34. site-upgrade (sup) • Major version upgrade of Drupal core and contrib modules. 34
  • 35. ...and more... • php-eval • sql-cli (sqlc) • variable-get (vget) • sql-conf • variable-set (vset) • sql-connect • search-index • sql-query (sqlq) • search-reindex • search-status 35
  • 36. ...and more, and more • Other modules can add • backup_migrate new Drush functionality per-site. • views_bulk_operations • www.drupal.org/project/ • features modules?filters=tid %3A4654&solrsort=sis_ project_release_usage • apachesolr %20desc • coder • provision, hosting (Aegir) 36
  • 37. Lights, Camera Drush in action 37
  • 38. 38
  • 39. 38
  • 40. 39
  • 41. 39
  • 42. 40
  • 43. 40
  • 44. Drush Make extension • www.drupal.org/project/drush_make • Create a ready-made Drupal site from the command-line. • Useful for distributing installation profiles. • Example: Open Atrium [www.openatrium.com] 41
  • 45. A Drush makefile • From www.openatrium.com/node/35 core="6.x" projects[] = "drupal" projects[openatrium][type] = "profile" projects[openatrium][download][type] = "cvs" projects[openatrium][download][module] = "contributions/profiles/openatrium" projects[openatrium][download][revision] = "DRUPAL-6--1-0-BETA4" 42
  • 46. 43
  • 47. 43
  • 48. As if by magic 44
  • 49. Putting it together • Build and configure a standard base site profile with a script of Drush commands: drush make standard.make drush si drush en views imagecache imageapi pathauto 45
  • 50. Development Server 46 Production Server Deployment example
  • 51. Development Server 47 Deployment example Production Server
  • 52. Deployment example Development Production Server Server drush dl drush si drush dl [modules] drush en 47
  • 53. Deployment example Development Production Server Server drush dl drush sql-sync [source] [destination] drush si drush rsync [source] [destination] drush dl [modules] drush en 47
  • 54. Want to learn more? • Documentation on Drupal.org • Session from the developers of Drush at DrupalCon 2009: • http://dc2009.drupalcon.org/session/drush-command-line-drupal- productivity • Come to Drupal Camp Alberta this summer. www.drupalcampalberta.org 48
  • 55. Questions 49