background image

Content tagged with: shell

Eric's picture

Drush is a great command line module for administering a Drupal site. It's core features are listed here. Check out the README.txt for usage and installation documentation.

Drush can be used to setup a base Drupal installation with a few quick commands, awesome. One of it's biggest time saving features is downloading all the contributed modules when setting up a new site. Here are a few commands I use to setup a new Drupal site based on feature sets. The following commands should be run in the root directory of your drupal installation.

# Download development modules and themes:
drush dl admin admin_menu coder devel devel_themer reroute_email simpletest views_bulk_operations --destination=sites/all/modules/contrib/ --uri=http://yourhostname.com

# Download common/essential modules:
drush dl cck views date wysiwyg pathauto token captcha recaptcha location emfield link jquery_ui webform htmlpurifier luceneapi vertical_tabs --destination=sites/all/modules/contrib/ --uri=http://yourhostname.com

# Download SEO modules:
drush dl google_analytics xmlsitemap globalredirect site_verify --destination=sites/all/modules/contrib/ --uri=http://yourhostname.com

# Download structural/building modules:
drush dl context features ctools panels --destination=sites/all/modules/contrib/ --uri=http://yourhostname.com

# Download image handling modules:
drush dl imageapi transliteration filefield mimedetect imagefield imagecache imagecache_actions --destination=sites/all/modules/contrib/ --uri=http://yourhostname.com

NOTE: the destination and uri flags on the drush command are optional, but I recommend using them. In recent Drupal development I stopped using sites/default in favor of sites/hostname.com, to ensure that if I ever decide to move the site into a multi-site configuration, I will not have overlapping sites/default/files directories.

You can even enable the downloaded modules from the command line by using the "drush en" command..

drush help en

Eric's picture

When I got my new MacBook Pro, I installed Xcode which comes with subversion (version 1.6.x):

$ which svn
/usr/bin/svn

$ /usr/bin/svn --version | head -1
svn, version 1.6.2 (r37639)

After installing Xcode I checked out some repositories to my local filesystem. Soon afterward, I realized I needed to be running an older subversion client to stay compatible with some 1.5.x repositories, so I decided to install CollabNet's OSX subversion binary (registration is required for older releases).

After downloading and installing the package (which defaults to /opt/subversion/bin/svn), I edited the /etc/profile file to override priority of my $PATH variable (since I now had 2 versions of subversion installed):

# lines added to /etc/profile:
export PATH=/opt/subversion/bin:$PATH

Now, if I ran a "which" command for svn, the appropriate svn executable is returned:

$ which svn
/opt/subversion/bin/svn

Unfortunately, the subversion projects I checked out using Xcode's subversion were inaccessible due to differences in the .svn structure:

$ cd /path/to/my/1.6.x/repo

$ svn stat
svn: This client is too old to work with working copy '.'.  You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

Luckily, CollabNet has a downloadable python script which allows you to switch checked out repositories to different versions. I downloaded this file and copied it into /opt/subversion/bin.

I was now able to update/downgrade my repositories using this python script:

$ svn --version | head -1
svn, version 1.5.7 (r36142)

$ cd /path/to/my/1.6.x/repo

$ change-svn-wc-format.py . 1.5
Converted WC at '.' into format 9 for Subversion 1.5

Eric's picture

I recently got a new MacBook Pro laptop (awesome!) and went through my usual rigmarole of setting up a new [VirtualBox] virtual machine for LAMP development. In previous situations I used bridged network connections which allow my virtual machine to have its own network connection, and acquire an IP address via DHCP. Now that I plan on being more mobile, I was concerned about having a static IP address for my virtual machine (for samba connections, scripting, and any other processes that relies on a static IP address). I decided to explore alternative virtual network connections and changed my virtual NIC to use NAT (the default network connection for VirtualBox). This configuration establishes a virtual NAT for your virtual machines which is great, but the downside is I know have to setup port forwarding to connect to my virtual machine. In bridged network configurations, I could simply SSH or use Samba to connect to my virtual machine by IP address. With NAT I have to setup port forwarding for the services I need to connect to. Initially I decided to setup port forwarding for SSH (port 22) and HTTP (port 80). While my virtual machine was powered down, I executed the following commands. NOTE: you'll have to replace "Centos" with the name of your virtual machine.

$ VBoxManage setextradata "Centos" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP
$ VBoxManage setextradata "Centos" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22
$ VBoxManage setextradata "Centos" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222
$ VBoxManage setextradata "Centos" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/GuestPort" 80
$ VBoxManage setextradata "Centos" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/HostPort" 8080

Now, I can SSH to my virtual machine..

$ ssh -p 2222 Eric@localhost

Or, connect to Apache by browsing to http://localhost:8080

The benefit of this network configuration allows me to travel anywhere with my laptop, use any type of network connection, and not have to worry about changing the way I connect to my virtual machine for development.

Eric's picture

Version control is an essential tool when it comes to maintaining your code and properly tracking filesystem changes. In this quick tutorial, I'll show you how to update a Drupal module in a subversion integrated environment using rsync. Since simply copying the contents of a new module update on top of your current directory structure is a bad idea (since it will NOT account for file deletions), rsync is a great solution for syncing module update changes. NOTE: it is a bad idea to update a module in a production environment without proper testing; this code assumes you are working in a development environment.

The first step is to download the latest (and in most cases, stable) package for the module you'd like to update to a directory outside your drupal path. For my Drupal installations, I browse to the Available updates page (admin/reports/updates) and copy the URL from this page. Next I go to my shell, use wget to fetch the package to my home directory, and unpack the file:

$ cd ~
$ mkdir Downloads
$ cd Downloads
$ wget http://ftp.drupal.org/files/projects/xmlsitemap-6.x-2.x-dev.tar.gz
$ tar -xzf xmlsitemap-6.x-2.x-dev.tar.gz

Now you can run the rsync command to apply the filesystem changes to your Drupal module directory. You'll have to update the paths listed below to match your filesystem and Drupal installation.

$ rsync -avCz --delete ~/Downloads/xmlsitemap/ /var/www/vhosts/tdb.erl.dev/httpdocs/sites/all/modules/xmlsitemap/

If executed properly, you can change directory to the module you are trying to update and run an "svn stat" command to see what has been updated. NOTE: the below output is simulated to show common svn status changes.

$ cd /var/www/vhosts/tdb.erl.dev/httpdocs/sites/all/modules/xmlsitemap
$ svn stat
?      xmlsitemap.newfile.php
!      xmlsitemap_taxonomy
M      xmlsitemap.module

At this point, you should see a list of all the files that have changed with this module update. You can now run the update.php script in your development environment and verify the changes are working properly. If everything is working properly, you can commit the module update changes...

# remove files that have been deleted
$ svn stat | grep ^! | awk {'print $2'} | xargs -i svn rm '{}'

# add files that have been added
$ svn stat | grep ^? | awk {'print $2'} | xargs -i svn add '{}'

# commit
$ svn commit -m "upgraded xmlsitemap module to version 6.x-2.x-dev"

Now, you can safely deploy the module changes to your production environment (svn update), run the update.php script, and ensure everything is working properly.

Eric's picture

There is nothing more frustrating than not having permissions set correctly on a server. I recently tried to commit a bunch of files to subversion and received the following error:

svn: Can't create directory 'sites/default/files/some/path/.svn': Permission denied

This usually indicates your user does not have permission to alter the .svn folders to execute the subversion commit command. The failed command will leave your subversion status with a tilde (~):

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path

You'll first need to reset permissions and ownership:

# change directories, you don't want to reset every file permission
$ cd sites/default/files

# use a find command and "-exec" switch to reset ownership and permissions
# NOTE: the group, owner, and permissions will vary on every server configuration
$ find . -exec chown Eric.apache {} \; -exec chmod -R ug+rw {} \;

Now, you can revert the files to remove the tilde (~) status:

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path
$ svn revert "sites/default/files/some/path"
$ svn revert "sites/default/files/some/other/path"
$ svn stat
?      sites/default/files/some/path
?      sites/default/files/some/other/path

At this point, you should be able to re-add the files to subversion and commit.