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.

A couple of weeks ago I decided to purchase a new domain name for my new blog on Posterous. I had be considering abandoning LiveJournal for a while now for several reasons: I used it as a direct service. Most people I knew on LJ have left are no longer using it. Those that remained crossposted to other sites, or had grown hostile with time. My LJ account simply felt like a dead weight -- something I was lugging along only for the sense of nostalgia that it provided. Given that I've recently found myself too entrenched in my ways, I thought it best to do something different.

Signing up for a new Posterous account was easy enough, of course. I was initially skeptical given it's most marketed feature is that only an email is necessary in order to post any sort of content. Once I started using it, of course, I found other features I found useful. One of these is private posting.

LiveJournal has the ability to show posts only to authorized individuals. It was one of the first social networking sites to use the phrase "friends list", a term that has since fallen out of favor for good reasons. This worked well in an age where there were few other social networking sites, and centralization wasn't as much of a concern. Today, however, people are members of several social networks, and the prerequisite of signing up for yet another website is an annoyance that most people no longer care to endure.

Unfortunately, this same problem extends to deninet. Viewers for "private" posts require both an account, and to be added to a particular channel in order to see the content. It's even more complicated than LiveJournal! As all three of us -- Pazi, Trice, and myself -- make both public and private posts on the site, the complexity has been a problem.

Posterous has a clever mechanism for getting around this problem. Posts that are flagged as private on Posterous may be shared by passing a unique URL to friends. In the age of Facebook and Twitter, sharing a URL is a simple affair. This is not to say that this sharing mechanism isn't fraught with its own problems. A shared URL is a very low barrier to entry security wise. An accidental public sharing or malicious distribution of the link can be easily imagined. There are ways to prevent this, however. Private links can be set to expire after a set amount of time. A hit detector could be put in place to lock down the link if suddenly an onslaught of traffic is detected. These are just ideas, of course.

I suggested to the girls that we switch to this mechanism for sharing posts stealthfully so that we may drop the current channel mechanism. As you might imagine, this did not go over well. I tend to get excited by new ideas in technology. I enjoy solving problems. My enthusiasm took a hit by their criticism, but it did eventually lead somewhere promising.

While the feature may not be a fit for deninet, it is still a feature of Posterous, and one I hope to make use of. Sharing a link to a post among my friends on my private Twitter feed seems easy enough. Since most of the people I once followed on LJ have since moved on to Twitter and Facebook, Posterous would allow me to continue sharing my thoughts with them in a semi-secluded manner. To encourage this, I decided to buy a domain name.

It was a whim, at first. It was a Friday night and Pazi and I were craving pizza. I had just purchased the domain name and pointed the A records to my Posterous account right before leaving for the grocery store. Shortly after getting to my car, I began to realize the potential problem a new domain name will cause.

Up until now, I've only owned deninet as a top level domain. I would post both public and private posts through the site, leveraging crossposting in order to share the content to friends. Now that I have a new top-level site, where does this leave deninet? Do I only make public posts on the site, and leave private ones for Posterous? This spurred me to think about what deninet is truly for.

After I returned home and started the Pizza, I shared some of my thoughts with Trice. The discussion was unexpectedly productive. I looped Pazi in, and shortly thereafter, she hit upon one of the most apt metaphors for our present situation I've ever heard. To both Pazi and Trice, deninet is our own private clubhouse. We can do what we want with it, and it's our little shared space. We also want it to be more; we want the site to also be our workshop, and our gallery. At present, we rely on several different mechanisms for storing our development notes for our creative projects. We'd prefer to keep this on something that we can share among ourselves, but also something that we own. The site also needs to be our gallery -- our place to show off the results of our creative efforts. As Pazi put it, "but we can't do that right now. We have people walking through our clubhouse because our gallery is dusty and unused."

We had a lot of good ideas in the discussion that followed.