Blog

Very few migrations are simple and straight-forward enough that a simple field mapping gets all of the little bits you need. In this week's Importing Data With Migrate and Drupal 7 lessons, we take a look at some complicated field mappings. We are going to add some new data we need to import, with team information. The team data is related to our player data through a relationship, and a player can have multiple teams they've played for.

We are super excited to introduce you to our new Interactive Designer, Justin Harrell. Justin started with us right before DrupalCon Prague, and so came over to Europe with the rest of the team for an intense introduction to the Drupal world.

In this week's lessons for the Importing Data With Migrate and Drupal 7 series we get a good look at our field mappings. This is the time that we make sure our source data is being properly handled and getting to the right destination fields in our Drupal site's database. We walk through basic field mapping, and see how that looks and works in the site UI, as well as with Drush. Then we explore different ways we can transform source data during the migration process, so that it matches what our destination field is expecting.

The entire Drupalize.Me team went to Prague, along with a number of other Lullabots, for DrupalCon Prague. In our latest podcast episode a few of us share what it was like, and the excitement and energy of new things on the horizon.

When is Drupal 8 coming out? What's going to change in the new version? How do I keep track of it, and most importantly, how am I going to learn what I need to know? These are the questions we're going to answer in a Drupal Association webinar on October 22. Joe Shindelar is going to give an update on where things are with Drupal 8, covering a raft of new features and changes that you'll want to know about. He's going to look at it from different perspectives — as a site-builder, themer, and module developer.

This week we're finally ready to dive in and write our first custom migration with the Migrate module. To get things set up, we need to get our source data, and create the content type in our Drupal site so that we have a destination. Joe walks through grabbing some baseball stats in SQL format for the source, and then building out the content types we'll need for teams and players.

This week, we are continuing our Importing Data With Migrate and Drupal 7 series, by getting oriented with the Migrate module. We take a look at two different ways of working with our migrations, through the UI and by using drush. Then we open up the Migrate example module to get an overview about what files are needed, and the main pieces of code used, to create a migration. This sets us up with a foundation to begin writing our own custom migration next week.

With so much data in so many places on the web, more and more site builders find that they need to get external data into their Drupal sites. It's a common problem with many ways to solve. One of the best ways to tackle this in Drupal is to use the Migrate module. The new Importing Data With Migrate and Drupal 7 series will teach you how to use the Migrate module to take data that exists in different source locations and import that into a Drupal 7 website.

Today we are going to wrap things up on the Using Drupal Chapter 3: Job Board series. We've created a site that meets the Epic University requirements, and learned the fundamental building blocks of putting together a Drupal site. In our last two lessons we are going to look at modules we could use to make our site even better, and then we are going to do our final tour and review of the site we've built, looking at what we've done, and how we built it.

In Episode 25 of the Drupalize.Me Podcast, Kyle Hofmeyer takes time to gather some Lullabots to discuss "developer workflow".

We are getting close to completing our site in the Using Drupal Chapter 3: Job Board series. This week we are going to finish up our requirements by building out the Applications view. This view gets a little tricky though, because we need to create three very different displays, and control who has access to some of those displays. This means we'll be doing a lot of overrides in our different displays. We also get to work with Views relationships to pull even more information into our view.

You've probably heard of this magical land of version control where you can undo bad things, start over, and share your work effortlessly. It's a wonderful place that, let's face it, actually takes a bit of work to get to. It's a lot like Drupal: the more time you spend with version control, the more you forget how hard and complicated it was at the very beginning. And even when you understand it, you can still get yourself into a fuddle sometimes.