Spam: The other white meat

This past summer, Packt Publishing was kind enough to send me a copy of Drupal 6 Content Administration by J. Ayen Green. Having told clients "hey, you wanted a complicated website, why do you think it's going to be easy to administer?" way to many times, I've been awaiting a book to provide an introduction to Drupal which covers some of the key- and not so obvious- aspects in a short read.

Despite having been a Drupal developer for several years, I still find myself scratching my head at supposedly mundane tasks (what recipe is best for uploading files with a WYSIWYG editor for example). A book that can walk through day to day site administration tasks is a fantastic resource, especially for folks are on unfamiliar ground.

This all being said, I was somewhat skeptical of this book for precisely what it aimed to do and what I've found myself telling clients- Drupal is complicated and its strength and weakness (from my perspective) lies in the fact that there are about sixty two zillion ways to do any one thing, much less having a naive site administrator trying to figure out information architecture with Drupal's foreign vocabulary (case in point- not taxonomy groups, but words!).

Funnily enough, a friend of mine was in the process of starting up an athletic center in my hometown, focusing providing athletes with a training facility that wasn't just your normal gym. He needed a website. On some long bike rides, between town line sprints, we chatted about what he needed- obviously Drupal right? Though he had experience using Dreamweaver to maintain sites previously, he had never really used a CMS, much less Drupal, before.

Now that I had a guinea pig, I did a quick Drupal 6 install, threw a dozen or so modules in, and had him choose theme he liked. I gave him a quick tutorial at my dining room table (i.e.: "this is what a node is"), gave him this book, a password, and told him to never use Dreamweaver again.

The report back was both surprising to me and interestingly in sync with the book. He said he read most of it, used it for a day or two, and busted out his site- The Confluence. From what I can tell, he is exactly the audience this book aims for: "This book is designed for those who run the site day-to-day but didn't set it up and aren't necessarily that well versed in Drupal or web technologies."  When I asked how comfortable he was running the site, he said that he had a good sense of how things functioned and felt in control. When I asked him if he'd recommend the book or tell other people in his position to use it, he said absolutely yes. In this instance, it really seems like Green is providing a solid manual for the target audience of the book. While it took me awhile to get the book back, that somebody could turn out a site that functions for their needs with relative speed is a strong testament to the book's effectiveness.

My read of the book lines right up with this- Green does do a very good job of introducing administrators to some of the more opaque aspects of Drupal- for example, there is a brief note in a discussion of taxonomy that the taxonomy module is not enabled by default- something an unsuspecting Drupal administrator would not know. If you've been using Drupal for awhile you likely know about taxonomy and know that if it has gone missing that you should check admin/build/modules. For the person who has just installed Drupal there is no hint about taxonomy- missing or otherwise. I think the framing of the book around real world activities is its strength. Green's venture into the Views module does this well. By walking the administrator through the steps to create a view, Green signposts critical elements that a new administrator needs to be aware of. This is what I like about this book- Green has done a good job in choosing activities that an administrator needs knowledge of and alerts the administrator to the critical elements.

Additionally, Green does almost all of the example activities with a reasonable set of modules- nothing really arcane is in use here. While I personally don't like FCKEditor which dominates the examples in the book, I understand why he's doing it and further, it is crazy to think that Drupal still does not have a seamless WYSIWYG editor. Perhaps a more legitimate complaint is that his recipe does not use the WYSIWYG module to implement FCKEditor, but that also incurs its own set of problems. So I'll chalk this up to me whining and move on.

From my perspective, what seems must useful in this book (and one of the main reason why I'd give to people new to Drupal) is the workflow/permissions section in chapter 7 (Supporting an Editorial Team). This is a great walk through on how to understand the relationships between user roles and permissions and content. I find that this is often a very unclear area for most people who are starting to administer Drupal and can result in people installing modules they don't need to to control access to content that is easily done with the core of Drupal. A pipe dream of mine would have been to throw the Workflow module on top of this but that is beyond the scope of what Green is trying to do.

As a Drupal developer, the only thing that struck me as out of line about this book is the liberal discussion of the PHP filter option. Though this module is part of Drupal core, it is arguably the biggest security hole you can create by turning on a module. Though Green does note that it is a security concern (not strongly enough from my perspective), I do not see the value in the given examples. Call me a curmudgeon if you will, but I loose sleep when this module is enabled. Of course there are reasons for it, but given who this book is aimed at, I think this is way out of scope.

I was really excited to see Green's walk through with Views. The one thing lacking here for me was an explanation of Views arguments. I think these are really powerful and great for an administrator to have an understanding of- it would make the taxonomy example that he gives more robust.

Obviously there is only so much that one can stuff in a book, but I would have rather seen chapter 8 devoted to advanced Views or Panels rather than offline editing. Perhaps I am just out of touch with what content administrators need but it strikes me that these are not the most common uses of Drupal. There is of course a question here about what the scope of a "Content Administrator" is- is it someone creating Panels and lots of Views, or are they someone who is more concerned about creating and editing node content? From Chapter 7 which focus on building an editorial team, my sense is that it is a broader view which approaches administrator more than merely content administrator, but that is perhaps a bad read on my part. This is also not a criticism of Green- Drupal provides a huge amount of flexibility that allows these kind of questions to remain ambiguous.

Overall I think this book not only hits its intended target audience correctly, but it demystifies many of the basic Drupal tasks in useful, real world ways. From my own read and looking at The Confluence it seems pretty clear that this is a great book for someone who is jumping into Drupal administration for the first time or needs to build a good foundation.