Drupal has a very flexible taxonomy system for tagging and categorization content (and users, and anything else). This flexibility is one of its interesting differentiating features — you can create as many dimensions of categorization and tagging as you like, which is very attractive for librarians and other enthusiasts of organization. To keep that flexibility from totally bogging down the system, Drupal maintains an index table that maps those terms onto the pieces of content to which they're attached.

Out of the box, Drupal 7 does not have autosave capabilities. The complexity of the kinds of content you can create is probably the reason for this, but that doesn't change the fact that it's a bummer. There are efforts underway to change this for Drupal 8; whether they will actually make it in is another question.

Every year there are two huge Drupal conferences: one in North America, the other somewhere else in the world. North America's was in Austin this year, and just wrapped up. The next one will be in Amsterdam at the end of September. It's a tradition at each con to announce the location of the next one, and next year's will be here in Los Angeles. Yay! I've been to many camps, but never to a con, so this gives me absolutely no way out of finally going. I'm definitely looking forward to this.

I found out about this very shortly before Austin, and helped some of the fine folks in LA's Drupal community put together a video that played during the closing session in Austin, revealing our fair city as the next location. I worked on the music for it, sourcing some material and playing a little bit of ukulele. Check it out!

If you're trying to make your Drupal site as fast as possible, you might consider using a static HTML file for page not found (404) errors. There are various other solutions that can help make Drupal faster in these situations while still letting you take advantage of Drupal-level redirects and whatnot, but a static page is always the fastest.

Update: I've added a patch for Drupal 7 that addresses a similar issue for the core node module. Take a look if you're interested.

I'm working on a Drupal project that requires calculating some custom stats for each registered user. To get it working, I ran my SQL queries right in hook_user_load(), which is wildly inefficient; it's much better to run the queries once and cache the results for a while. Drupal has nice cache functions built-in, and I thought I should use them, but wasn't totally clear on how to do it based on the documentation.

Jeff Eaton of Lullabot wrote a really helpful article on how to do basic caching in Drupal 7, which is a good introduction, but didn't really explain how to cache a bunch of related, but separately calculated, pieces of data using a function you'd call repeatedly. Examples module is also great, and does include a cache_example module, but also didn't have an example that was right up my alley.

So, here's how to write a single function that can be called multiple times on the same kind of object. This is not what you'd want to do for users or other built-in entities (for those, you should use Entity Cache module). Thanks to Planet Drupal readers for the feedback and help clarifying this.

When migrating into Drupal from a CSV file (i.e. a spreadsheet from Excel or LibreOffice Calc if you're an open source nut like me), you use the MigrateSourceCSV class. It works very well.

Depending on where the CSV file originated, though, you might get unexpected behaviors, like Migrate UI telling you there are thousands of source fields you need to map. If this happens, and you don't have that many fields, check the line endings on your CSV file. Open the CSV file in your text editor and check its settings. Today, I was working with a file with the following settings (shown in BBEdit's status bar):

As you can see, the character set was Western (Mac OS Roman), and the line endings were Classic Mac. That means the file originated in Excel for the Mac, and it causes Migrate to freak out. I changed these settings to UTF-8 and Unix-style line breaks, saved the file, and from then on Migrate was happy.

There's also a parameter you'll see in the MigrateSourceCSV documentation called embedded_newlines. It's supposed to help with weird row counts, so I thought maybe that would help this issue, but apparently that's not quite it. It's not a big deal to resave the CSV file anyway, so that's what I'd recommend just to be safe.

This is Part 1 in a series of posts on migrating a site from Squarespace 5 into Drupal 7. This is an overview of what we're doing and why, mostly discussing the format of the Squarespace 5 XML file, which is undocumented. My hope is to make the process of importing Squarespace data easier for everyone else.

The Mission

I'm working on a fairly large site (ApertureExpert.com), currently running on Squarespace 5, migrating to Drupal 7. Squarespace is an excellent platform with many virtues, but it doesn't allow the level of customization that my client is looking for, so we're moving the site to Drupal. Now, of course you lose the built-in, high-availability hosting, and some of the very good polished UI that Squarespace gives you, so this move is not for everyone. But if you want control, and to have your blog, forums, and e-commerce wrapped up in a single package, Drupal is your friend. One example: my client wants users to have all their purchased products, forum posts, and comments available through their user profile. Squarespace can't do that, Drupal can.

This site has been active for several years now, and has a very active community of users, so the first big task was to import all of those items into Drupal. Fortunately, Squarespace 5 will let you export your entire website as XML. Note: it doesn't look like Squarespace 6 (the current version) supports full site export. There is a WordPress-compatible export that you could import into Drupal using WordPress Migrate (or, obviously, into WordPress), but it seems to cover only blog posts. This site is older, running Squarespace 5, so we can get everything.

Now that we have exported data, what can we do with it?