Ramblings

I have recently been working on a few projects that involve migrating legacy data to Drupal. In the past, I have used node_import, node_export, user_import, feeds, and migrate (version 1.x) and each has its pros and cons. But this project had a little more complexity and some pieces that I wasn't sure of how to approach with any of these methods. So I decided it was time to dive into migrate version 2.x. Having used migrate-6.x-1.x for a couple of projects, I loved the way it worked. I was able to get everything done that I needed and rarely needed to extend it with any custom functions.

I have been asked and seen some recent posts on folks having trouble setting up Drupal multisites on their shared hosting, specifically Dreamhost, Bluehost, etc. I figured it might be worth giving the basics for any hosting on how to get Drupal multisites to work. Most ISP/hosting companies allow you to host multiple websites on a single account. Either separate as domains or "subdomains", you can host multiple websites on your account. Traditionally, two separate websites are served from separate directories.

I presented a talk on Drupal Multisites at DrupalCamp MA 2012. [edit 1/21/2012] I have uploaded the slides as I presented. Thanks for everyone's support.

One handy trick I've found is that when you're visiting a Drupal page and you notice that you're not logged in, you can simply add user?destination= into the URL right after the root of your Drupal site and keep the path. This means that http://eporama.com/ramblings becomes http://eporama.com/user?destination=ramblings Then when you log in, you're brought back to the page you were viewing with no fuss. I do this often enough that I decided to make it a bookmarklet.

I ran into a problem using the Migrate module where I migrated a series of newsletter issues and then imported a series of articles that were related to each newsletter. Typically, for nodereferences, you can add a dependency of the first migration.

I presented at Drupal Camp New Hampshire 2011 and Drupal Camp MA 2012. This talk was about running Drupal locally and how to set up a good development environment. Edit: [2011-11-10] Just found out there's an error on the location of the my.cnf file. MAMP 2.x wants them in /Applications/MAMP/conf ... slides updated.

Version control is a hot topic in terms of managing and deploying sites. Now that drupal.org has moved from a server-based version control system (CVS) to a distributed version control (git), some developers have been on the push to move their own development strategies into git to have one control system to manage all of their files. Keeping files "under version control" means that you're going to add an extra step to the saving and managing of your files. Git does not automatically track all changes to files that you're working on. Git does not even track files per se.

I'm trying to get a better handle on Drush aliases, so figured it would help to write out my findings and thoughts. This post may update as we go, so look back for changes.

Drush context

Drush runs in specific contexts, if Drush can tell that it's in a Drupal root somewhere, it will assume the --root=/path/to/that/Drupal. It can also detect if you're within a sites/subsite directory and will set --uri=subsite as well.

Drupal multisites are really powerful and a nice way to not have to have all of the core files duplicated for each site that you're working on on a development or local server. Drupal looks for settings.php in a number of places. The more exact of a match that it can find to your sites URL, the better. If your site's address is fun.mywonderfulsite.com the most specific sites/ directory that Drupal will look for is: sites/fun.mywonderfulsite.com.

Once you've set up a development environment, probably the next thing that you've run into is that you're hooked and you need another (and another, and another...). Drupal can easily handle multiple sites run out of the same Drupal codebase. Drupal multisites are super powerful and if you're not hacking core are pretty easy way to keep things a little more centralized.