Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Dec 29 2011
Dec 29

It can be difficult to remember all of the usernames and passwords that you use to log in to various websites across the internet, so why force users to create a new username for your web site? It's easier on everyone to simply combine the username and email address fields. It also cleans up your registration form a bit.

In Drupal, there are two modules that can help you to accomplish this:

These two modules are mutually exclusive— they are not compatible with each other, so you'll have to pick one. I prefer to use Email Registration, and I'll explain why.

Email Registration

Email Registration simplifies the user registration form by removing the 'username' field. By default, the module will automatically generate a username for a new user based upon the first part (before the @) of his/her email address. For example, if I registered for a new account with email address [email protected], I would end up with username madmatter23.

That's great, but it's not exactly what I'd like. I'd like my username to be my full email address. Luckily, Email Registration provides a hook_email_registration_name() to let you customize exactly how the username will be generated. I used the hook in this way:
* Implements hook_email_registration_name().
function grasmash_email_registration_name($edit, $account) {
return $account->mail;

Adding a similar snippet to your own custom module will give you complete control. That's all there is to it!


This module still forces users to choose their own username during registration. However, after they're registered, it will allow them to login using either their username or their email address. Hence my preference for Email Registration.

LoginToboggan also has a number of other nice features, such as redirecting users after registration or login, and providing a login form on the 403 Access Denied page. If you really need one of these features, there are a number of alternative modules that provide the same functionality:

Final Thought

Using this method does have at least one major drawback: you no longer have the option to display a user's username while preserving the privacy of their email address. However, this problem can easily be circumvented by simply using an optional 'alias' field, or by utilizing a programmatically applied handle for users based on other field values.

Dec 23 2011
Dec 23

As of Drush 4.5, migrating a Drupal site between servers became much easier. The new, little-known drush archive-dump and drush archive-restore commands make it an essentially three step process.


A basic Drupal site is made of two fundamental elements: the codebase and the database. When you migrate a Drupal site, you need to migrate both of these elements, often with a bit of re-configuration to boot.

The Old Way

Before using Drush to migrate a site, my standard procedure for site migration looked something like this:

Database Migration

  1. create a new, empty database
  2. create a new user
  3. associate the new user with the new database (with correct permissions)
  4. create a db dump from the source environment
  5. import the db dump to the target environment

Codebase Migration

  1. compress the codebase into a tar.gz file
  2. transfer files
  3. unarchive tarball
  4. edit the settings.php file to reflect the new database settings
  5. check file ownership, group membership, and permissions

The New Way (for me)

I'll run through the first iteration using psuedo [tokens] as placeholder for file and sitenames.

Open up the command line on the source machine (or SSH in) and cd to your Drupal installation.

  1. Create a Drush archive dump (code and db in one)
    drush archive-dump [site]
  2. Transfer the dump to your target machine (clearly, you could just FTP it)
    scp [new-backup-archive] [user]@[target-machine]:[target-folder]
  3. Now switch to the command line on your target machine, cd to the folder above your to-be-created Drupal installation and type:
    drush archive-restore [new-backup-archive] [site] --destination=./[new-folder-name] --db-url=mysql://[msql-user]:[mysql-password]@[target-server]/[db-name]

Drush will then create the new directory, unarchive your tarball into it, create a new database, populate it, and edit your settings.php file accordingly. Wow. Awesome.

Here's how the process looks for me when moving to my local MAMP stack (without tokens):

  1. drush archive-dump default
  2. scp /home/grasmash/drush-backups/archive-dump/20111256023713/grasmash.20116223_023613.tar.gz [email protected][my-ip]:/Applications/MAMP/htdocs
  3. drush archive-restore grasmash.20116223_023613.tar.gz default --destination=./grasmash --db-url=mysql://root:[email protected]/grasmash

Now it's important to note that you can use an existing directory or an existing database. If you'd like the contents of the existing directly overwritten, you can use the --overwrite flag. Likewise, you can grant Drush sudo MYSQL privileges to modify your dbs by adding a --db-su flag, followed by the correct credentials.

Furthermore, you don't need to use --destination or --db-url flags at all. If you leave these out, Drush will attempt to unarchive to the current working directory, and will attempt to use the database credentials defined in the settings.php file.

For more information on these commands, use drush's --help flag, e.g., drush archive-restore --help


Quick disclaimer:  There are many ways to migrate a Drupal site between servers. You should certainly be using SCM (like git), which can be used to move the codebase. You can use drush or backup_migrate to transfer the database. Or, you could simply move around Virtual Machines.

At present, it seems that the --db-url flag only works with Drupal 6. Please leave a comment and let me know if this is not the case!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web