After my last post, I decided to try my hand at porting content from the old site to a clean Drupal 7 installation. The experience has been enlightening.
Drupal 7 often feels like a completely different content manager compared to Drupal 6. It quite literally thinks differently compared to its previous version. Fields are everything, right down to the structure of the database. This became more than apparent as soon as I created the first node.
There are many blog posts that include images alongside their written content. Many of these relied on the old Image and Image Attach modules. This effectively inserted an Image node as a thumbnail into a Blog post. It was very convienent at the time, but as CCK and ImageField became the preferred way to do things, this old pattern became very, very cumbersome.
The solution seemed obvious, covert those image references to file attachments. This took me down an interesting path. Drupal 6 allowed you to desegnate which nodes allowed files to be attached, and which didn't. Drupal 7 assumes that if you're going to attach files, you'll create a specific field for the file attachment on the content type. It seemed a simple enough solution...
The problem is that there are two ways to go about attaching images to a node in Drupal 7. You can create a FileField, or an ImageField. The former handles files generically, allowing file of any (allowed) type to be attached to the node. ImageField aguments those file handling abilities with special display options. An ImageField can specify the maximum dimension of the image, and which image profile to use to display it in the post. It's this ability that I wanted to leverage.
Image profiles in Drupal 7 are similar to the ImageCache module (in fact, it's exactly the same idea if not the same code). An image profile specifies how to display an image in a particular way. For example, you can create a profile that will resize the image to thumbnail size. A thumbnail image is important as relying on the <img> tag's "height" and "width" attributes to resize it is not an effective solution. The large image file still needs to be loaded even when displayed at a smaller size. The display is also not anti-aliased in many browsers, leaving the preview jagged and hideous.
Using a FileField would be functional, but using an ImageField is a better solution. ImageFields, however, can only handle image files. If I were to attach a non-image file, the display may be rudimentary or worse, crash the site. This means that if I want to attach non-image files to a Blog Post, I'd need two fields -- one for images, and one for files.
After thinking about this for a few hours, I couldn't think of many instances we've attached images to a Blog Post that aren't images. Unless my memory is faulty, I doubt there are more than a half-dozen instances of non-image files being attached to Blog Posts. Image attachements, however, are far, far more common. Furthermore, attaching files to a blog post almost seems like a bad practice. Images, yes, are important to directly attach to a Blog Post. Other documents, however, would be better served by creating another content type. That type would have the explicit purpose of representing that file. I have a few ideas toward that end, but nothing serious as of yet.