We would like to share a tool with you that has helped speed up our development process as a team.
If you work on Drupal sites with a team of other developers you will know the problem: You pulled code and all of a sudden you get strange errors. Eventually you find out you need to run update.php or revert a certain Feature or clear the cache. Maybe you even got into the habit of just doing all of that after each pull and it takes up some valuable time that you need elsewhere. To avoid these problems we introduced shell scripts a while ago. Within just a few months they have evolved into a multi-file system with subscripts, but I want to share them in their simplest form.
Here's a few examples of what you can do in a script, combined with the powers of Drush:
- Enable and disable modules or themes
- Revert your Features
- Clear your caches
- Run database updates
- Delete content types and fields
- Index content for solr
- Whatever else Drush can do
- Output some audio when the script is finished!
Our scripts live in sites/all/scripts. Drupal by default disallows access to .sh files so there's nothing we need to do there to keep our files private.
################################################################################
# Shell and drush commands to update the given installation
#
# Go to sites/all/scripts (e.g. cd sites/all/scripts) and type "sh update.sh"
# in your console/shell/Terminal.
#
# The commands have to be functional for any case after the initial installation
# installation. So on any set up after calling that script, the configuration
# must be the same.
#
# For example:
# ------------
# When the script enabled a module in an earlier revision and that module shall
# not be enabled in the current revision, we have to add a "drush dis" and a
# "drush pm-uninstall" command for that module to this script.
#
################################################################################
# Change directory to drupal root
cd ../../..
# pwd
# Check drupal status
drush status
# Disable these themes to make sure they are never enabled.
drush --yes pm-disable seven
drush --yes pm-disable bartik
# Enable some modules that must be enabled.
drush --yes pm-enable features
drush --yes pm-enable strongarm
# Enable project features.
drush --yes pm-enable ok_base
drush --yes pm-enable ok_event
drush --yes pm-enable ok_i18n
drush --yes pm-enable ok_menus
drush --yes pm-enable ok_news
drush --yes pm-enable ok_page
drush --yes pm-enable ok_search
drush --yes pm-enable ok_slideshow
drush --yes pm-enable ok_sidebar
drush --yes pm-enable ok_theme
drush --yes pm-enable ok_user
drush --yes pm-enable ok_wysiwyg
# Enable project theme.
drush --yes pm-enable ourprettytheme
# Update
drush --yes updb
# Disable unused modules and features.
drush --yes pm-disable features_override
drush --yes pm-uninstall features_override
# Remove an old content type and some fields.
drush --yes php-eval "node_type_delete('page');"
drush field-delete field_news_tags --bundle=news
drush field-delete field_news_link --bundle=news
# Index content for solr
drush sapi-i ok_sitewide_index 10000 25
drush sapi-s
# Revert all features and clear cache.
drush --yes features-revert-all
drush cache-clear all
# Display list of features to check status manually.
drush features
# Check for available notification system
# Checks in preferred order and only uses one: Notification Center, Growl, Audio
# For OS X 10.8 use terminal notifier "sudo gem install terminal-notifier" http://rubygems.org/gems/terminal-notifier
# For Growl, download and install growlnotifier http://growl.info/downloads#generaldownloads
if [ $( find /Library/Ruby/Gems/ -name 'terminal-notifier*' -type d | wc -l) -ge 1 ]; then # Notification center output for finished update.sh terminal-notifier -message "$USER, the update script run is complete" -title "undpaul Update Script"
elif [ -f /usr/local/bin/growlnotify ]; then # Growl notification growlnotify -n "undpaul Update Script" -m "$USER, the update script run is complete"
elif [ $(command -v say) ]; then # Vocal output for finished update.sh say "$USER, the update script run is complete"
fi
Because the script tells us when it's finished, we can just go do something else while it runs.
We also use an installation script so everyone on the team can get started quickly. Basically, we expect to be able to set up the project from scratch at any time by just running install.sh and update.sh:
[gist:5848790]
This is really helpful if anyone wants to test their development with a fresh database, but using the current code base. It helps avoid problems that occur if someone forgot to export some setting in a Feature.
What do you think about our scripts? Does your team use something like this during development?
