Drupal

Here's a statistic I haven't seen bandied about much. Drupal runs three times as many of the Alexa 10,000 top sites as the next CMS, according to backendbattles.com.

This figure was extracted using Wappalyzer. It's not perfect: The Onion doesn't show up as a Drupal site, for example, probably because it runs an old or heavily hacked version.

It's nice to have this statistic at hand when Drupal supporters feel disheartened by popularity comparisons to Joomla. There are many ways to be successful; capturing the attention of the world's biggest sites is a pretty good one.

Having said that: WordPress is found on nearly three times as many big sites as Drupal. (Backendbattles.com categorizes it as "blog software" rather than a CMS, so it doesn't show up in the comparison.)

Peachpit just published my article, "Top Ten Changes That Make Drupal 7 the Best Version". Peachpit is a publisher of a wide range of technology books, so this article will reach many readers who are savvy enough to use Drupal well, but might not know much about it yet. Comments welcome!

Just want to point people at a terrific new resource maintained by a "Seattle Drupal Beginner" group: a list of Drupal-related books, with bonus links to the authors' Drupal.org profiles! Nicely done, folks.

Regular readers know that I've been working on a Drupal 7 book for beginners. We -- meaning Peachpit Press and myself -- are now faced with a decision. We could release it before, after, or at the same time as Drupal 7's release. Each option has its pitfalls. Release it too early, and it might not match the final Drupal 7 software. Too late, and we could lose the "first mover advantage" to another book.

Whatever our decision, we have to provide some date for potential distributors, booksellers, and customers. So we boldly decided we'd try to release it at the same time as Drupal 7 itself -- and announced the 24 January 2010 date you currently see on Amazon.

Webchick, when asked when Drupal 7 will be released, always says "When it's ready". Neither she nor co-maintainer Dries will set a date at this point, and for good reason: Neither of them are in control of when "ready" will be. Of course they could release it any time they like -- in an unready state. That would be bad for everyone who relies on Drupal, wants to switch to Drupal, has built a business around Drupal, who teaches or writes about Drupal... in short, bad for everybody. So their silence is as it should be.

But we, like IT professionals around the globe, still have to make decisions. In our case, we have to guess at Drupal 7's release date a few months in advance if we're going to hit that goal of simultaneous release. (Book publishing takes time!) And the sooner we make the decision, the better.

I'd personally love to announce the availability of Drupal 7: Visual QuickStart Guide on the same day as Drupal 7's own release. But I'm nagged by unknowns. What would it mean if it came out early? What if it came out after a similar book? Which situation is worse?

What do you think?

I've been busy writing Drupal 7: Visual QuickStart Guide for Peachpit Press over the last couple of months. I'm pleased to say that all the main chapters are done, and most of them are already available for preview on Safari Books Online. (I've given the table of contents below.)

Now it's time to write the appendices, and I'm not sure what would be most useful. We're thinking:

• Extending Drupal, including a list of the most popular modules, and whether they're expected to be available for D7 (thanks to the #D7CX project)
• Differences between D6 and D7
• Interacting with the Drupal community

Here's what the book contains so far:

Chapter 1. Getting Drupal Up and Running

• Fulfilling Drupal's Requirements
• Downloading and Unpacking Drupal
• Creating the MySQL Database Using phpMyAdmin
• Installing Drupal

Chapter 2. Establishing Your Drupal Site

• Performing Common Post-Installation Tasks
• Giving Your Site Its Identity
• Selecting a Visual Theme
• Monitoring Your Drupal Site
• Packaging Your Drupal Site

Chapter 3. Creating and Managing Content

• Gaining More Control of Individual Nodes
• Creating Other Types of Content
• Finding, Editing, and Deleting Content

Chapter 4. Customizing Content

• Defining Custom Types of Content
• Putting Images and Styled Text in Content

Chapter 5. Making Content Interactive

• Enabling Interactive Content Types
• Categorizing Content with Taxonomies
• Mastering Text Formats

Chapter 6. Improving Access to Content

• Making Content Searchable
• Directing Traffic with Menus
• Laying Out Your Site with Blocks

Chapter 7. Wrangling Users

• Managing User Accounts
• Controlling How Users Interact with Their Accounts
• Defining User Roles and Permissions
• Building and Protecting User Community

Chapter 8. Customizing Drupal's Look and Feel

• Creating a New Theme
• Changing Theme Graphics and Typography with CSS

I'm sure I'm not the first to discover this, but...

An online dictionary search for "Drupal" says it's a synonym for "drupaceous": that is, "resembling, related to... [or] producing drupes". A drupe is a fruit whose seed is covered by a tough endocarp, like the red peaches you see here.

Juicy!

Look at the top keyword searches that bring people to my site, according to Google Analytics:

1. tom geller (O.K., that's a gimme.)
2. wamp drupal
3. drupal wamp
4. (content targeting)
5. drupal on windows
6. drupal windows

Further, about one in five requests for support sent through my site's contact form is WAMP-related.

So -- what's the story? Is it that WAMP is hopelessly messed up? Is there a vacuum of relevant information out there? (My Running Drupal on Windows using WAMP article is Hit #4 on Google.) Have you had problems running Drupal on WAMP? Does the Acquia Drupal stack installer for Windows help?

At last I can announce the release of my new six-hour video series from Lynda.com, "Drupal 6: Online Presentation of Data", which you can check out with a free one-day pass. (Of course it's also available to anyone with a Lynda.com subscription, starting at $25/month for all-you-can-stand training in over 600 topics.)

I first talked about this course in January and was able to implement at least one suggestion from your comments (about creating calendars). There are also videos about mapping, charting, and preparing data for tabular export, all built on a foundation of CCK and Views.

Since Lynda.com's audience is mostly graphic designers, the course starts out with an in-depth description of data structure: As you know, data planning is at least as important as implementation! And it's an essential subject whose subtleties elude most beginners.

One wag in IRC questioned the need for such a course. "Presentation of Data?," he said. "Isn't that what Drupal does anyway?" He's right -- in the same way that a car is a tool for going shopping. But I believe that many people who would benefit from Drupal's data-presentation features simply don't know about them, because their knowledge of it stops at Stories, Pages, users, and blocks. They need a bit more information to make the leap, and could become fierce advocates for Drupal when they see all it can do in this area.

Extra bonus: For giggles, check out the Introduction video, which includes some live-action video of me looking goofy. :)

Thanks, as always, to the Drupal community for both helping me to understand these topics myself, and for making Drupal the Web development powerhouse it is.

First things first: I've you've ever looked at Acquia's documentation, read this post and take the survey. You're welcome, jam. ;)

Now, a confession: I went to the Drupal.org documentation sprint at DrupalCon. And I tried to be useful, really I did. But I found myself frustrated, unable to really engage in it, and left mid-day feeling horribly guilty. Why? I think there were two causes:

1. The task is so immense. Drupal.org's documentation has grown like topsy, and now useful information is dispersed throughout several unconnected areas. The search function is really all that brings them together.
2. Quality varies wildly. The biggest sin is, as usual, too much writing. As I often say, writing is easy; editing is hard. Brevity is the soul of wit. Your mama wears combat boots. And so forth.

I wrestled with the task facing doc team lead Addison Berry: What would I do in her place? My answer surprised me: I'd burn it all down and start again.

I'm reminded of the real-estate markets of Detroit, Cleveland, and Buffalo. In those cities there are blocks full of houses that are worth less than nothing: They're too dilapidated to restore, and the cost to demolish them (about $8,000) is greater than the land's value. And ashes are cheaper to truck away than lumber, even if the burning dumps toxins in the soil.

What "city blocks" on Drupal.org are like that?

Such arson is unlikely to happen on Drupal.org. For one thing, it's discouraging to sweat out a long document, and then discover that it's disappeared. How many people would stop contributing documentation as a result? How would the community's soil be poisoned?

I'd still recommend cutting mercilessly. I believe at least 75% of the words on Drupal.org could and should be lost. But who would do the cutting? It's tough work, and without glory. Converting Drupal.org's documentation into a wiki(-like) format might help "crowdsource" the task. Or maybe not. Nobody likes to cut. Editing is hard.

Which leads us back to Acquia.

Acquia is a "third-party documentation provider", like the Lullabots and GotDrupal and DrupalTherapy and many others... and me. It's tempting to say that we thrive because of the weaknesses in Drupal.org -- that is, that they create a vacuum that we fill -- but it's not really true. After all, Apple's documentation is pretty good, but that supports outside writers rather than cannabilizing their work. In a healthy project, there's always a new audience to reach.

But we outside doc providers have an advantage over Drupal.org: a clear field. Arson is unnecessary, and will put no toxins in the soil. Each building we create on these virgin plots can reflect a different architecture, each fitting a distinct family of users.

That's why I think it's great that the Lullabots' CCK and Views videos will be available alongside my own: Theirs reach a certain audience, while mine will reach a different audience. And both of us can only do what we do because of the base provided by Drupal.org's documentation. Together -- we outside doc providers and Drupal.org -- we all grow the Drupalsphere.

I visited my site a couple of weeks ago and discovered a pile of comment spam. That's not unusual, of course; what *was* strange was that Drupal's Comment Notify module hadn't told me about them. Some poking around revealed that, lo and behold, the site wasn't sending any email. The problem's nature meant I had gotten no notification: It was the silent site-killer.

So first off, I want to apologize to anyone who's tried to contact me thorugh tomgeller.com or gellerguides.com and not gotten a response. Simply put, I never got your message: If you remember your query, please send it again. The fault was entirely mine, because I hadn't instituted a simple procedure that would have prevented the problem. To wit: I should have tested the site periodically.

And so should you.

In fact, here are five areas every Web admin should test regularly:

1. Anonymous user experience. Log out, then test your site's appearance and function. One mis-set permission can stop visitors in their tracks.
2. Sign-up experience. The sign-up email is your users' first personalized encounter with your site. Are you sure it represents your current message? And do the sign-up screens lead logically from one to the next?
3. Links and scripts. File paths sometimes change during system updates, but you'll never know until you try to access a link or script... and have it fail. Discover the problems before your users do!
4. Images. Ever had your images disappear after an upgrade? There are two common causes: putting image files in the wrong place (such as /files), and forgetting that you'd modified pieces of a theme when you upgrade it. Which leads us to our last test...
5. Backup and restore. "You're only as good as your latest backup", they say. Further, "Your backup is only as good as your ability to restore from it". Whether a backup is missing or unusable doesn't matter: The result is the same.

I'm sure this isn't a complete list, and fear the next time my site dies a silent death. So help me out: What other areas do you think site admins should test regularly?