On this page
- Installation
- Compatibility
- Use Drush 12 to fix "Support bash to support `source`" error
- Basic Usage
- Tips
- Updating Drupal the correct way from the command line
- Set base URL for multiple Drupal installations on server
- Easy base URL solution via drush/drush.yml
- Complicated base URL solution with direnv
- Use alias to set PHP version and use just drush
- Hard code PHP version in Drush with alias and patch drush
- Set PHP version with symbolic links
- Cannot use simply drush?
- Drupal 7 and Drupal 10 on same web host
Drush
Drush is one of the most popular, if not the most popular, Drupal development and sysadmin tool out there. Drush is the command line and scripting interface for Drupal. You can use it to speed up installing, developing, debugging and maintaining Drupal sites. It is also capable of generating boilerplate code for custom developments. It takes some getting used to, and there are a lot of commands to remember but, once you do, it is a real time saver. Rather than clicking through the admin interface to achieve something, you simply type in one command. When building Drupal sites and developing custom modules and themes, this can really help.
Historically, Drush was also used to download modules, but this is now done with Composer.
Drush is not a module and its code is hosted outside Drupal code on GitHub: https://github.com/drush-ops/drush
The official documentation can be found at https://www.drush.org (https://docs.drush.org/ for version 9 or less) and here's the basic fact to know about it:
Installation
It's recommended to use composer to install Drush inside your project
composer require drush/drushLocal dev tools such as DDEV or Lando provide aliases to run drush without path and from any directory.
If installed and run globally it will detect the local installation and use it instead. You can use the Drush Launcher, but beware that since drush 12, this method is no more possible.
Compatibility
If you're not using the latest major version of Drupal, you may have to choose an older version of Drush: check the compatibility chart on drush web site.
Use Drush 12 to fix "Support bash to support `source`" error
Downgrading to Drush 12.5 may take care of the error below, from Drush 13.6:
$ drush st
# Support bash to support `source` with fallback on $0 if this does not run with bash
# https://stackoverflow.com/a/35006505/6512
selfArg="$BASH_SOURCE"
if [ -z "$selfArg" ]; then
selfArg="$0"
fi
[...]
Basic Usage
# Commands list : run drush without option
drush
# Help about a command
drush help cache:clear
# Help about a more detailed topic
drush topic [topic]
# Empty cache (The most used command)
drush cache:rebuild
# The same with an alias
drush cr
You will certainly use it for installing (or uninstalling) modules, importing or exporting configuration, run cron, manager users, ... see the list of all commands and options.
You can also extend it by creating your own command.
Tips
Updating Drupal the correct way from the command line
When updating a Drupal site, always respect this order in order to avoid configuration problems.
drush updatedb --no-cache-clear
drush cache:rebuild
drush config:import
drush cache:rebuildIf you want to execute post config import commands you could use a hook_post_update_NAME or the drush deploy command
Set base URL for multiple Drupal installations on server
In Drupal 7, you could set the base URL via settings.php, but this is not supported in Drupal 11. So for a command such as drush user:login to work, you must append the base URL like this:
drush user:login -l https://example.orgDDEV sets a base URL, by defining DRUSH_OPTIONS_URI in its configuration.
Easy base URL solution via drush/drush.yml
The simplest way to set individual base URL's in multiple Drupal installations on the same server, is by adding a drush/drush.yml in each project, with this:
options:
uri: 'https://example.org'See Drush Configuration for more.
If you are using Git, treat drush/drush.yml like settings.php, i.e. only add it on the web server, but don't track it, by adding the below in .gitignore:
# ignore drush/drush.yml for base URL
/drush/drush.ymlComplicated base URL solution with direnv
The direnv program can help handle multiple Drupal installations on the same server, by varying your environment variables, depending on the directory you are in, when you issue a command line request. You can use this feature to define a site URI for each code base.
Install direnv and verify that it works. You can now define a base URL by adding a .envrc file in the Drupal 10 folder on your server, with this content:
export DRUSH_OPTIONS_URI=https://example.orgTest if it works (it should return "nope" if it fails):
~/dev/drupal$ echo ${DRUSH_OPTIONS_URI-nope}
https://example.orgDrush now has a Site URI defined, and you can simply run drush user:login from now on:
~/dev/drupal$ drush st
Drupal version : 10.4.1
Site URI : https://example.org
[...]See also Annoying loading and unloading messages. How to mute?, and how to set global Drush configuration in a config file or via environment variables.
Use alias to set PHP version and use just drush
On shared hosting with different PHP versions, where you cannot set the default PHP version on the server yourself, there are different methods, and combinations which can help solve this.
Using alias can also be an easy method to allow using simply drush instead of vendor/bin/drush, since setting this with PATH in .bashrc can be complicated.
Hard code PHP version in Drush with alias and patch drush
On shared web hosting with different PHP versions available (and perhaps sites using different PHP versions, like production 8.2 and test 8.3) you can call Drush via php drush.
Also, PHP memory limit defaults can be too low for Drush commands like pm:install or config:import. You can define aliases adding this in .bashrc, remember to run source .bashrc afterwards:
alias php='/opt/alt/php83/usr/bin/php -d memory_limit=-1'
alias drush='/opt/alt/php83/usr/bin/php -d memory_limit=-1 /var/www/example.org/vendor/bin/drush'
alias composer='/opt/alt/php83/usr/bin/php -d memory_limit=-1 /usr/local/bin/composer'This may work well for most Drush commands such drush status, but drush updatedb can give this error:
$ drush updatedb
In SiteProcess.php line 214: The command "/var/www/example.org/vendor/bin/drush updatedb:status --strict=0 --uri=https://example.org" failed
Exit Code: 255(Unknown error)
Working directory: Output:
================
Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.2.0". You are running 7.4.33. in /var/www/example.org/vendor/composer/platform_check.php on line 28A workaround is hard coding the PHP version in vendor/bin/drush to this (originally #!/usr/bin/env php). Note: It looks like it changed from PHP to BASH, between Drush 12 and Drush 13:
#!/usr/bin/env /opt/alt/php83/usr/bin/php
<?php
[...]
From Drush ProcessManager does not respect the PHP version Drush was invoked with #6273, thanks @echernyavskiy!
To automate the change, you could create a patchfile for Drush 12, such as what is shown below, then apply it via cweagans/composer-patches:
diff --git a/vendor/bin/drush b/vendor/bin/drush
index 5318cb397..e64b091ab 100755
--- a/vendor/bin/drush
+++ b/vendor/bin/drush
@@ -1,4 +1,4 @@
-#!/usr/bin/env php
+#!/usr/bin/env /opt/alt/php83/usr/bin/php
<?php
require __DIR__ . '/drush.php';However, this patch should only be run on the production server, not local development.
For more, see Drush using different version of php than Drupal on hosted server.
Set PHP version with symbolic links
You can also use symbolic links ("symlink") to set the PHP version, Always run the desired PHP version when your hosting solution has multiple versions available:
Agaric has an article on dealing with this issue—and I can vouch it works very well.
Essentially, any changes made to .bashrc, .bash_aliases, .bash_profile, .profile, etc. by themselves will have no effect on which PHP Drush uses. It requires a different approach to path to the PHP version you want it to run with. One way to set this up:
- Check with your hosting provider to find which versions of PHP are available, and their respective paths.
- On your shared hosting account root folder, create a
/binfolder (mkdir bin)- Create an alias to your desired version of PHP, like this example:
ln -s /usr/bin/[your_php_version] ~/bin/php. Make sure this matches what your provider offers.- Test that the alias works by running:
bin/php -v- Add a path to your Drush site alias to link to this version of PHP in each environment like this example:
env-vars: PATH: /home/[your account]/bin:/usr/bin:/binOnce this is up, test it by running
drush @alias st.
From https://www.drupal.org/forum/support/post-installation/2023-01-18/drush-... by @karolus, thanks!
Cannot use simply drush?
See info on how to add Drush to the $PATH. If this is not possible, you may need to use the full path (relative to you project root):
vendor/bin/drush statusSee Document how to most easily make vendor/bin/drush available as drush #5828 for hints, like how to reset PATH after experimenting. It is recommended to read up on PATH and understand the fundamentals.
Drupal 7 and Drupal 10 on same web host
You may have both Drupal 7 and Drupal 10 on the same web host. In that case you will end up with a complex situation of both a global Drush 8 for Drupal 7 and local Drush 12 for each Drupal 10 installation.
To make this set up work, check if some paths are being registered, for example with something like this in ~/.bash_profile to find out where to place Drush 8:
PATH=$PATH:$HOME/.local/bin:$HOME/binCheck the paths available with this:
$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/var/www/example.org/.local/bin:/var/www/example.org/binIf a path in your own directory is available use that, like ~/.local/bin or ~/bin. Some prefer ~/.local/bin since that folder is hidden. You can install Drush 8 with something like this:
wget https://github.com/drush-ops/drush/releases/download/8.4.12/drush.phar
chmod +x drush.phar
mv drush.phar ~/.local/bin/drushFor more see:
Help improve this page
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion
Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.