I was working on setting up a role migration from Drupal 6 to Drupal 7. After some time, I noticed that the role id's were not being preserved, which was going to cause a problem for me when I went to take the migration to the live server. I initially tried using the addFieldMapping function to link the source rid to the destination rid (similar to preserving the nid for nodes or the uid for users). However, this failed to save any of the roles during migration.

Finding failed login attempts from the maillog:

Back in late December the hard drive on my iMac failed... kaput! Disk utility couldn't fix it nor could it erase the drive. It had become a paper weight. Thankfully, I had time machine running for selected files/folders on the iMac (but not the whole system), which allowed me to restore to a new computer in a timely fashion. This week I found myself wanting to reference an article on my blog site and realized it wasn't loading (it was only a local blog at this time). No problem, I went to the time machine backup and pulled the code for the site.

We have a shared hosting server that handles many Drupal sites within their own Apache virtual hosts. We had a need to track all available log messages for long periods of time, which the core watchdog module wouldn't allow us to do. So, we enabled the syslog module to write the messages to log files on the server.

To get all of the sites into their own log files we had to add the following code to /etc/rsyslog.d/drupal.conf

You can use Google Maps API to get a JSON string with the distance, including driving directions, between two postal codes. The code is below:

Today I was working on a feature on a site that was using Ubercart's uc_roles module. By default, whenever a customer would buy a product with a role attached to it, an email would be generated stating what role that customer bought. However, in my use case, we did not want these emails generated and we needed to keep our settings in code.

Today we were in the process of changing the hosting on a domain. The client wanted us to keep their original DNS records but they only gave us access to change their name servers. So, we needed to investigate how to get a list of all of their current DNS records so we could replicate those on our name servers. I came across this post: http://serverfault.com/a/294370 and the following command:

Today I was trying to setup a site behind an Elastic Load Balancer (ELB) on Amazon's EC2. I was able to set the configuration array to on in settings.php:

Drupal's calendar module is a great tool for building calendars quickly with views. However, the default theme is still using tables, blech! After some searching, I came across a sandbox module to fix this, https://drupal.org/node/1675894#comment-7903527. Like some of the user's in that thread, I did not want to add another module to my site. So, I set off to theme the calendar in a responsive way. Surprisingly, this was much easier than I anticipated. You only need to override two theme files and add roughly 88 lines of css.

This morning started off okay, until I checked my email and found an alarm ringing about one of our file servers being offline. Luckily, we have a replicated setup, so no customers were affected, but it is a little worrisome not having the safety net of two replicated servers.

The server didn't technically crash, rather, it was a problem with the EC2 instance being unavailable likely due to some unforeseen problem in the Virginia datacenter. Regardless, the first step I took was to get the server accessible via SSH.