Most folk that talk to me about linking content within a Drupal site (and use a wysiwyg module) know that I am a big fan of the Linkit module with pathologic. It provides a nice way to reference content within your site, keeps a simple url, and pathologic will convert it to the nice url. However, I recently ran into a problem with the course catalog on our campus.
Yesterday evening, I was working with a client on their site who are doing some interesting things with one of their custom search pages. They send ajax requests to the backend to get 2 types of values for their user:
Instead of opting to go with straight database queries to get the data, they were using the EntityFieldQuery manner to get the initial list of X since they were using fields. Its not quite as fast, but its a much more flexible approach (and if they opt to change their field storage in the future to something like MongoDB, they can have something really fast without having to change a single line of code!). The one problem with EntityFieldQuery, however, is that it will only return back a listing of entity IDs. Meaning that if we want to get other pieces of data, we have to load up the entity. In their scenario, the only other piece of data that they wanted to retrieve was the reference field data. And performing an entire entity_load (or node_load to be specific) would mean they would also need to load up the 50 other fields that they are storing. So doing a retrieval like this on uncached content meant that the retrieval of this data alone took 3 to 4 seconds.
Last week, Jakub Suchy proposed an action for Drupal developers to contribute 30 minutes each day for 5 days (this week) towards the Drupal community. This can involve anything from providing support on forums/irc to writing/reviewing patches to documentation (and so on and so forth). So I am laying out some of my plans and join us in making Drupal better for everyone.
I like problem solving. My good friend Oliver knows this and recently came to me with a Drupal problem that involved nodes related to other nodes and presenting them to the user in the correct order. For the Food Republic, he had galleries which contained story nodes which you could go through via a pager (showing the photo content one item at a time). Both an issue of views and *not* an issue of views, we needed to figure out a way to continue utilizing views while giving correct results.
(Updated June 4, 2011 - address new handler requirements with Migrate 2.1 by removing stdClass)
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).
(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.
