I've been playing around with using the new version of migrate for a little while. But its been on the more boring side and learning how to use migrate with CSV files (which admittedly feels quite good ^_^) And it was only after an email from Tom Camp and in an effort to get my presentation on Migrate ready for NYC camp and Drupal Camp LA.
A few months back, I blogged about creating dynamic migrations. With a small amount of code, you can do something very powerful. You can bring in large amounts of data that need to fit into different places with one simple class. And when all of these containers are holding close to the same kind of data, it makes it an obvious choice. Commerce Migrate approaches migrating data from Ubercart to Commerce in such a way and does a great job of bringing over the core fields of an Ubercart product. But what do you do when you need to add additional sets of data for a particular type of entity bundle? The client that needed my help had various kinds of information attached to their products - taxonomy terms for various vocabularies, additional image fields, text fields, stock, etc. Fields that do not get associated with Commerce products / product displays in the initial migration. When I initially saw this, I was completely stumped - it meant rewriting all the dynamic migrations that were being done by commerce migrate as actual migrations (not a task I was looking forward to given that I would essentially copying/pasting code to get the desired effect without actually using Commerce Migrate).
As many folk know (and as folk can see by my posts on the topic), I am very big fan of Migrate. It takes a while to figure out what you want to do and how to do it, but the power is absolutely immense. And having complete control over the source object down to manipulating the destination node/user/entity while still working within a framework has made this my favourite module.
I was recently tasked to import data from a deprecated database table (Q&A) into a Drupal 6 site. Regarding the data that was being imported in:
- It is a one-time import.
- It boiled down as one flat database file
- No new content of this type will be added again. Ever.
- It should not appear in search results
- They need an easy way to go through all the data.
- It would be great if it could be filtered through and made searchable.
(Updated June 4, 2011 - address new handler requirements with Migrate 2.1 by removing
In this finale (?) on using the Migrate module, I will go through how to go about writing your very own field handler to pull in content into a field type that does not yet have a mapped path. In this example, we will be migrating an events (so the date field from the date module will require a migration path). At the time of writing, http://drupal.org/node/1021076 had not yet been resolved (or have the ability for date_to and date_from to be established) so we will write out a field handler that handles just this!
(Updated November 10, 2011 - Updated information about file actions. Thank you Patrick Thurmond!)
(Updated June 4, 2011 - File Handler Compatibility with Migrate 2.1)
(Updated June 8, 2011 - Image to show how to write out your destination field names)
Updated August 29, 2012: I wrote out a blog post on the new image/file handler changes from Migrate 2.4+ a few weeks ago which you can read about here. I've not updated this blog post with those changes so take a bit of what you learn from these blog posts, and add in all the things from the new one for anything file related (or just look at the new one since I link out to the new reference codebase from there as well). and hopefully it helps :)
Its been a while since I wrote about using the migrate module to migrate content from various sources. The last time, I covered migrating users into Drupal and this time, I will write out how to migrate content into drupal as nodes. Because the migrate module is so flexible, it makes doing such things quite easy.
This evening, I had the pleasure of once again presenting at a Los Angeles Drupal meetup. This time, I changed focus from showcases and module demonstrations to a module howto. The migrate module is fantastic at migrating content into drupal but as has been noted, a bit lacking as far as documentation / presentations are concerned. Since I have been working at migrating a site at CalArts to Drupal 7, this was a good opportunity to present on how to implement content migration. The slides have now gone up on SlideShare (the slides will be embedded below as well) and John Romine should have the video up within the next few days. I am really happy with how the presentation went and look forward to talking more content migration with others in the community in the near future. I'm hoping to carve out some time and write out the node migration process sometime this week.
Last week, I posted about performing a content/user migration from Drupal 6 to Drupal 7 using the migrate module (instead of going via the upgrade route or the 'use the interns at work and make them undergo hell for a few days' of copy content and users one-by-one for migration).
UPDATE - March 13, 2012: Added in findings by Andre and my thoughts.
Over the past 2 weeks, I have been working on a project whereby the site owners wanted to update the look and feel of their site (along with adding a slew of new features in there - I will be posting about it once the site launches). In talking with my coworkers, we (I) essentially decided that instead of updating their current site (which was in Drupal 6), it would now be done in Drupal 7. What we (I) also decided is that instead of running the site through a site upgrade path, we would create a fresh install of Drupal 7 and copy the content from the old site into the new one.