While working on the one of the more content-heavy websites at my workplace (over 100k nodes consisting of galleries of photos, with some galleries having well over 2000 photos), I had noticed that while performance for logged in users (which isn't high since only site editors can log in) has mostly stabilized (there are areas where performance can improve), performance for all other site visitors was very inconsistent. Some of the galleries and gallery photos pages seemed to load fairly quickly while others took a few seconds for the page to show up.
At CalArts, I have wanted to move the search functionality on our Drupal powered websites into something better for a long time. We have been using the Lucene API (which is lucene search ported to PHP) module on most of them since September of last year but (even though I am a big fan of the module) we truly wanted a way to offload the search services onto another vps (or server; basically, something more flexible).
(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!
For a site I am currently creating in Drupal 7, I have a bunch of events and I need to show a view of the content in a non-traditional calendar way (Listing of events for a week, a pager to go back and forth in the week, and a calendar block which lets the user select the date (week) they want to see events occurring on).
I have the pleasure of working on CalArt's Photo Archive. From the conversion as a flat-file website into Drupal, the site has come a long way. And for a mid-sized website (a little over 100k nodes) running on somewhat older hardware (at least 3 years old), we are fairly happy with the performance (using the boost module allows us to serve cached content at approximately 2k requests per second). However, I was noticing that some of our content type pages were loading quite slowly prior to being cached.
(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.
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.
A couple of months ago, I presented at a LA User Group meetup on getting rid of 60 - 70 odd gallery blocks on calarts.edu and getting them all powered by one block. I hadn't had a chance to properly present all the material at that time (and I didn't get a chance to share some/most of the code we'd used to get it all up and running so I've decided to type out the whole history behind how the idea and the implementation that came about.