Ramblings

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

becomes

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

There are many ways to get Drupal running on your Mac. OS X comes preinstalled with PHP and Apache, so theoretically, you'd only need MySQL. Acquia makes a separate version that includes Drupal, Apache, MySQL, and PHP (aka DAMP) already set up. This version is great if you really want to get up and running quickly. It's tied to the Acquia distribution of Drupal which has some extra features that we don't tend to use for our development.

(No drush!?!? #inconceivable)

With all of the fancy ways to upgrade Drupal core floating around: drush, git, diff, patching. What if you only have FTP?

As always, the first steps are to a) plan, b) backup, and c) be flexible.

It always helps to have a plan. Write it down, think it through, practice on something other than your production site.

When new security releases come out for Drupal, updating is definitely something that you want to do sooner rather than later. My philosophy has generally been to update my local setup immediately, let all of our developers/users know that I am going to update the shared dev server within two days, then schedule a time to update production based on any issues we find with the dev server. Since we run most of our sites as a rather large multisite, it means updating everybody at once, but hey, that's what dev's for, right? Well, we'll leave that for another discussion.