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.

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.

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. If both the newsletter issue table used a primary key and the article table used a foreign key of "issueid" then the mapping is very straight forward.

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.

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.

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.

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...).