Introduction

With version 7, the web-publishing system Drupal stands at that frightening moment when it either enters the mainstream or falls into the abyss of niche enthusiasts. Until now its complexity has kept it mostly in the province of technology professionals, but I believe Drupal 7 will succeed for two reasons: The public is ready for it, and it’s ready for the public.

First, the average web site builder understands—and demands—features that plain old HTML can’t offer without extensive programming, such as user management and form processing. Drupal provides those features. Its architecture is elegant, its features broad and varied, and its community base unparalleled in the open-source software world (except by Linux, whose lead Drupal trails in terms of contributors).

But it’s not the only contender, and in fact several others are easier to use. Drupal’s boosters (Drupalistas) point out that their software does well against Joomla and other full-featured CMSes (content management systems), but I think they’re missing the point: The real competition is anything that gives people the features they want. So for simple personal sites, it’s Facebook and MySpace; for businesses, Yahoo Merchant Solutions, eBay, and Amazon; for publications, WordPress.com and Blogger.com; and for the rest, a hosted solution like Google Sites. Drupalistas would argue that none of these are technically CMSes. It doesn’t matter—they have enough CMS-like features for the masses.

But time spent learning Drupal rewards its student handsomely. None of those other solutions compares to it in terms of flexibility, security, or support. Learning to exploit Drupal’s advantages just takes time and attention.

I wrote this book because I wanted to help non-technical people discover the joy I found when I started building sites in Drupal in late 2007. Freshly downloaded, Drupal gave me the ability to run a blog (like WordPress) and host polls (like MySpace) in addition to everything I could do before with plain HTML. Dipping into the vast wealth of Drupal extensions (modules) gave me plug-and-play access to features I hadn’t even considered before. My first Drupal site (savemyhomebook.com) looked and functioned far better than anything I’d built since learning HTML in the mid-’90s; later sites included shopping carts, user interaction, and complex data display.

Which brings us to the second reason Drupal 7 is right for non-technical site builders: Its developers have focused on making it the easiest version of Drupal. In early 2009, project founder Dries Buytaert made it clear that he wanted “radical improvements in usability” to this version, even funding design improvements through his company, Acquia. Eye-tracking studies at the University of Baltimore pinpointed items of greatest confusion among first-time Drupal administrators, and outreach programs encouraged the participation of graphic designers and user-interface experts.

The results have fallen short of some of the more ambitious goals, but are impressive nonetheless. The Drupal community (as the saying goes) shot for the sky and missed—but landed among the stars.

Is This Book for You?

Drupal 7: Visual QuickStart Guide was written for anybody who wants to create a dynamic, easy-to-update web site that looks good and performs well. Unlike most current books about Drupal, it’s written for anybody with even the most basic computer skills. That means you should be already able to:

• Use a computer to access the Internet through a web browser

• Download files

• Install software on your computer

Depending on how you intend to host your Drupal web site, you might also need to:

• Access a remote computer through programs other than a web browser

• Navigate by typing on a non-graphical, command-line interface such as is found in *nix operating systems

• Change file permission settings

• Understand written instructions from your web hosting provider

What This Book Will Teach You

By the time you’ve finished this book, you’ll have all the skills you need to create an attractive and complete Drupal web site. Specifically, you’ll learn how to:

• Install Drupal on your home computer (to prototype your site)

• Install Drupal on a remote server (to make your site available to the world at large)

• Give your site its basic identity

• Add, change, and delete text and images

• Modify your site’s visual design

• Modify your site’s functional interface, for example changing where information appears on the page and what links show up in menus

• Monitor and maintain your site to prevent malicious activity

• Make a backup for safety, and restore your site from that backup

• Allow site visitors to become members with their own user names and passwords

• Control member access

• Run interactive features, such as blogs, polls, and forums

• Find and add any of hundreds of modules that extend Drupal with new and interesting functions

• Find help from experienced Drupal administrators when you get stuck

• Further your Drupal career by understanding and participating in the project’s vibrant user community

What This Book Won’t Teach You

Alas, there are some Drupal-related subjects too big or tangential to include here, such as:

• Finding and signing up with a web host to make your site available to the world. (There is a list of companies that provide Drupal-ready hosting services at drupal.org/hosting.)

• Accessing files on, transferring files to, or navigating around your remote host’s file system. In Chapter 1, “Getting Drupal Up and Running,” I briefly show how to navigate one of the most common host interfaces—the command-line interface of *nix. But there’s an enormous variation in how web hosts operate and what they allow their customers to do. If the instructions in this book don’t fit, ask the support desk of your web host for help.

• Registering a domain name or making it refer to your Drupal site. Again, your web host’s help desk is the best place to go.

• Suggesting anything about the kind of content to put on your site. That’s your job!

• Programming or advanced theming.

How This Book Is Organized

Drupal 7: Visual QuickStart Guide is intended to take you from a standing start to running a web site that’s both functional and useful. Because the definition of “useful” varies from person to person, this book makes only basic assumptions about what you’re going to do with Drupal. The book is divided into four sections based on those assumptions:

I      Setting Up (Chapters 1 and 2)

II    Managing Content (Chapters 3–6)

III   Managing Drupal (Chapters 7–9)

IV   Appendix and Glossary

As you can see, the biggest section is devoted to creating and managing content: That’s probably why you’re learning a content management system! But this book also assumes that you’ll want to:

• Open your site to a wider community, and therefore need to understand Drupal’s user-management features (Chapter 7)

• Change your site’s appearance (Chapter 8)

• Take advantage of Drupal’s huge library of modules to extend what it can do (Chapter 9)

• Go beyond this book to interact with Drupal’s user community, one of the most active in the open-source software world (Appendix)

In making these assumptions—and to best use limited space—I’ve left out some of Drupal’s finer points. Typically these were features that will matter to you only after you’ve been administering Drupal sites for a while. For example, I decided not to discuss performance or security enhancements, because Drupal’s built-in features are sufficient for all but the busiest web sites. The appendix, “Getting (and Giving) Help,” gives you pointers about where to find such information should you need it.

At times, I use a very simple, fictional Drupal site to demonstrate various points. If you’d like inspiration from people who have taken Drupal much further, see drupalsites.net.

Standards Used In This Book

I use some conventions to provide guidance. This book:

• Uses this font whenever showing something that you should actually type (also known as code).

• Shows the code font in italics to indicate that you should replace the text with the equivalent for your situation, for example, http://domain-name/user/user-id.

• Italicizes the first occurrence of words that are defined in the glossary.

• Refers to locations on your own Drupal site in the form http://domain-name.

• Refers to other web sites in the form example.com (without the http://).

• Refers to directory paths on your web server in the form /path/to/location (with a leading slash, which indicates the top directory of your Drupal installation).

• Assumes that you’re always logged in as the superuser (user/1)—that is, the user that you created when you first installed Drupal. (For details, see Chapter 1.) This user has full access to every administrative feature in a Drupal site. If you get the message “Access Denied” when you try to do something in this book, try logging out (by going to http://domain-name/logout) and then logging in again (http://domain-name/user).

• Gives instructions for Mac first, followed by Windows and *nix in those instances where differences among them arise. (Since you manage Drupal mostly through web browsers that work pretty much the same on all platforms, these distinctions are rare.)

• Provides screen shots of the drupal.org web site as it appeared immediately after its October 2010 renovation. In an example of bad timing, the site was undergoing profound reorganization as we were putting this book to bed. Some screen shots you see here are of the prerelease beta site, and might be different from what you see when you visit drupal.org.

What is Drupal, Anyway?

Drupal is in the content management system (CMS) category of web site tools. CMSes excel in letting you create dynamic sites, which show different information depending on a number of factors, such as the input of previous visitors, or whether the current visitor is logged in. Sites that don’t have such features are called static and are typically created using a page-description language such as HTML. (You can also use Drupal to create sites that don’t take advantage of its dynamic features.)

Drupal has many features common to CMSes, including:

• Administration through a web browser. You manage your Drupal site mostly by visiting it in a web browser such as Firefox or Safari, logging in as an administrator, and going to pages that let you change site settings.

• A user-management system that lets you identify, track, and control visitors’ access.

• Fine-grained permissions that allow you to grant specific rights to specific groups of users.

• Streamlined methods for changing content. In Drupal, you edit basic pages (or other types of content) by clicking a tab labeled Edit and filling out a form. To do the same thing on a traditional HTML site, you’d need to download a file, figure out what parts to change, make the changes, and then upload the file again.

• Flexible methods of displaying content. One example is Drupal’s Summary feature, which shows a shortened version of content where appropriate.

• Consistent appearance throughout the site. Certain features (such as menus and graphic design) remain the same regardless of what part of the site you visit.

• Changeable overall appearance. In Drupal, you change the look of the site as a whole by switching to a new theme, hundreds of which are available from drupal.org or through private designers. The content remains the same regardless of what theme you select.

• Extensibility so you can add features by writing (or downloading) a bit of programming code, typically in the PHP language. Drupal is usually extended through the use of modules, which you can read about in Chapter 9, “Extending Drupal with Modules.”

How Drupal Works

The best way to understand how Drupal works is to compare it with other systems, specifically static HTML and hosted sites.

• Static HTML sites comprise text files that end in .htm or .html; image files (.jpg, .gif, .png); other media and downloadable files such as Adobe Portable Document Format files (.pdf) or QuickTime movies (.mov); and any custom programming files. These reside on a remote computer (the host) that’s always on and connected to the Internet and that runs a program called a web server.

When someone types the domain name of a static HTML site into a web browser, the web server finds a file called index.html (or index.htm) on the host. That file typically contains all the text on the site’s home page, along with references to other files such as images and formatting information. The web server gathers all these pieces together and sends them back over the Internet to the web browser, which reassembles them into a web page .

How static HTML sites produce pages

To change a static HTML site, you either modify files directly on the server or on your personal computer and then transfer them to the server through a program such as FileZilla (filezilla-project.org), Secure Copy (SCP), or a web browser–based interface. Likewise, to copy your HTML site to another computer, you only need to copy its files.

• Hosted sites such as Yahoo Merchant Solutions and Google Sites vary widely in how they’re set up, but they share some common traits. For one thing, you almost always build and modify your site through a simplified, web browser-based interface that hides the underlying HTML and programming code from you. As a result, such solutions tend to be easy to create but hard or impossible to customize beyond pre-defined limits. You neither need to know nor are able to know exactly how the site runs beyond what you can see through the web browser . It’s sometimes impossible to copy a hosted site to another computer in a useful form—you’re stuck with the host for life.

How hosted sites produce pages (as far as we know)

• Drupal sites essentially comprise three parts: the Drupal software itself, which is written mostly in the PHP programming language; a database that contains your site’s content and settings; and images and other files.

When someone visits a Drupal site, the web server first finds the index.php file. Whereas a static HTML site’s index.html file simply describes what the page should look like, Drupal’s index.php file is a program that causes the host to look into dozens of files and the content database to determine what information should be sent to the visitor. When the process is finished, the web server responds with files from the host and content from the database, formatted (mostly) as simple HTML. The web server sends that HTML over the Internet to the web browser, which interprets and displays it just as if it had come from a static HTML site .

How Drupal produces pages

Although this process seems impossibly complex to the human eye, the host interprets this chain of PHP and database instructions quickly and easily. Along the way, Drupal has opportunities to modify the output based on its own programming, modules you’ve installed, and any other circumstances.

You make most changes to a Drupal site by manipulating content in the database through a web browser–based interface. Except for Chapter 1, this book is almost entirely about how to use that web browser–based interface.

To copy a Drupal site to another location, you need to transfer both its files and its database. You’ll learn how to do that in Chapter 2, “Establishing Your Drupal Site.”

Drupal, CSS, PHP, JavaScript, and SQL

I mentioned that Drupal is mostly written in PHP, which was designed specifically for web development. Technically, PHP is a scripting language, which (among other things) means that programs written in it are stored in a form that you can easily read; an interpreter turns them into machine language at the time they’re run. (By contrast, programs written in compiled languages such as C++ are converted into machine language before they’re run, and then the computer uses the converted version from then on.) As a result, anyone who knows PHP can look at the Drupal program and understand how it works.

PHP is a server-side language, meaning that all of this interpretation happens on the host—typically, on the same remote computer that stores the files and sends the final HTML code out over the Internet.

But PHP isn’t the only language involved in a Drupal site. Others are:

• SQL (Structured Query Language), a server-side database language that Drupal uses to add, change, and remove information. When someone posts a page to your site, for example, Drupal sends a command in SQL to the database that says, “insert this information into the node table” (actually, Drupal sends several SQL commands). When somebody reads that page, Drupal says, “retrieve that information from the node table.” Here’s an example.

• CSS (Cascading Style Sheets), a descriptive language that defines typography, layout, and other display properties. One of the fastest ways to give your Drupal site the appearance you want is to download a free theme that has the basic layout you like, and then change its CSS files to indicate your preferred fonts, colors, and images. (You’ll learn how to do this in Chapter 8, “Customizing Drupal’s Look and Feel.”)

Unlike SQL and PHP, CSS is a client-side language that’s sent over the Internet and then interpreted by site visitors’ web browsers. Here’s an example.

• JavaScript, a language that mostly adds interface “spice” to your site. If an image changes when you move your mouse over it, that’s JavaScript at work. Drupal itself includes several user-interface portions of the jQuery library, a JavaScript extension that allows developers to easily include lots of “eye candy,” such as animations, resizable dialog boxes, and drag-and-drop effects.

Like CSS, JavaScript interpretation happens in site visitors’ web browsers, not on the server. A very small number of site visitors turn off JavaScript on their browsers and won’t be able to see these effects. Fortunately, Drupal always tries to present them the same information without the effects. Here’s some sample JavaScript.

You don’t need to learn any of these languages to use Drupal! But doing so lets you create unique features for your sites and improve your overall computer knowledge. Besides, Drupal provides both motivation and opportunity to learn them: Why not take advantage of it? I personally had a hard time wrapping my head around CSS—until I started modifying Drupal themes. Likewise, my real first forays into PHP were to display information that couldn’t be extracted in any other way.

Having said that, contributed modules sometimes take the place of these languages. For example, the Views module (which you can download for free from drupal.org/project/views) makes most custom SQL programming unnecessary.

The Long Road to Drupal 7

Drupal has come a long, long way since Belgian student Dries Buytaert started creating it in 2000 to stay in touch with his friends at the University of Antwerp. It received a big publicity boost in 2003 when supporters of U.S. presidential candidate Howard Dean organized campaign activities using Drupal 4, and since then it has grown by leaps and bounds.

By the time version 5 arrived in early 2007, Drupal ran such notable web sites as theonion.com and mtv.co.uk. Drupal 6 came a little over a year later, including features that eased installation, maintenance, content translation, and general administration.

Mr. Buytaert listed 11 key improvements he wanted when Drupal 7 development started in earnest in February 2008 (see buytaert.net/starting-to-work-on-drupal-7). As I mentioned, the one that got the most attention—and that’s most visible to anyone who’s tried earlier versions—is usability. That focus has frankly required a change within the community’s social structure, as the text-minded developers who make up its inner circle needed to see the value of good visual design and user interaction. But with Drupal 7, they’re beginning to see the light. They belatedly follow in the footsteps of Mr. Buytaert’s own conversion, which he described in a January 2006 post:

“For long I focused, completely and utterly, on the aesthetics of Drupal’s code, neglecting eye candy and ease of use... The aesthetics of Drupal’s clean code has attracted many developers, but has also given Drupal the reputation of being developer-centric and hard to use... I have since learned that elegant design and ease of use are equally [as] important as clean source code.”

A secondary goal of Drupal 7 was, put bluntly, to not repeat certain mistakes of the Drupal 6 launch. Three practices have given the Drupal 7 release plan a level of professionalism that any organization would envy:

• Drupal development tools are better. Testing, communication, and project tracking have all benefited from advances of the past two years.

• Drupal 7’s release schedule was defined better. A series of “code freezes” set deadlines that both revved motivation and imposed discipline. While those finish lines moved a few times (introducing the giggle-worthy phrase “code slush”), and there were occasions of blatant disregard for some of those deadlines, there’s no denying the clarity they attempted to give Drupal 7’s development process.

• Support by Drupal module developers is better. One of the biggest complaints surrounding Drupal 6’s release was that most modules—including those that nearly every Drupal site administrator needed—lagged the release by months or even years. This time around, Moshe Weitzman lobbied for developers to pledge release of their Drupal 7–compatible modules for the same time that Drupal 7 itself is released. That effort has garnered over 100 pledges. Of the 20 most popular modules, only six have neither taken the pledge nor been incorporated into Drupal 7 itself. Even without the pledge, Drupal 7 versions of every one of those six are in active development. (For details, see “Modules: The Drupal 7 Challenge” in Chapter 9.)

Drupal 6 vs. Drupal 7

So what finally came out of the Drupal 7 sausage grinder? Dozens of changes, described in minuscule detail in the periodic release notes linked from the Drupal project page at drupal.org/project/drupal. Although you could rightly argue about which are the most important, here’s my take (summarized from my article on the Peachpit Press web site at peachpit.com/articles/article.aspx?p=1433049):

• New themes. Drupal 7 adds a new default theme (Bartik) as well as a separate theme, appropriately called Seven, that makes administration easier.

• Lighter workflow. For version 7, links to Drupal’s administrative functions have been radically reorganized into what its developers hope is a more user-friendly configuration, although it might leave Drupal 6 administrators scratching their heads for a while. Drupal 7 also puts commonly used commands in easy reach, in the Toolbar and customizable Shortcut bar. Finally—and most visibly—there’s now an administrative overlay that floats controls in front of the screen they affect, reducing the feeling that you’re navigating through a maze of screens.

• Improved installation and update procedures. What probably most often tripped up users of Drupal 6 was installation and updating, both of which have been fundamentally improved in Drupal 7. First, the installer has some nice touches that make it more foolproof. Second, help texts during installation are a lot more, well, helpful. Once you have Drupal installed, you can now install and update themes and modules through Drupal’s web-based interface instead of needing access to the server (via its sometimes obscure commands).

• Smarter defaults. User studies and administrator experience have made Drupal more ready for use immediately upon installation. You can still override such behaviors, but on the whole, Drupal administrators will do a lot less initial work to make their Drupal 7 sites work the way they want.

• Easier, more flexible content management. For a content management system, the procedure for entering content in Drupal has historically been more difficult than it needed to be. But Drupal 7 makes up for lost time with three standout features. First, a neat visual trick called “vertical tabs” makes the content-entry form cleaner and easier to navigate. Second, you no longer need to download additional modules to put images in content. Finally, you can define highly customized types of content, for example catalog pages that include fields for price, color, and size. Before Drupal 7, you needed a module called Content Construction Kit (CCK) for this functionality. (See Chapter 4, “Customizing Content,” for details.)

• Fields in core. Drupal 7 has many improvements that are hidden from view—unless you’re an experienced administrator or Drupal developer. “Fields in core” is one of those changes, but it has far-reaching benefits for everyone who uses Drupal. It essentially lets you break information into separate parts (fields) for truly original results. Fields in core actually goes beyond content, extending profiles, comments, and how you categorize content.

• Easier programming. As long as I’m talking about less-visible improvements, I should mention a huge raft of changes that have made programming for Drupal easier. The list is far too long to include here, but you can see it at http://drupal.org/node/224333 and http://drupal.org/node/394070.

• Clean-up of unneeded bits. Some things removed from Drupal 7 include the little-used Throttle, Ping, and Blog API modules; the “related terms” feature for taxonomy (which never did anything, anyway); and the ability to block posts that don’t have a minimum number of words. Of course, every bit of obsolete technology has its fans, so such removals are always controversial. If you find yourself needing those old Drupal 6 features, most (if not all) will still be available through downloadable modules.

• Better organization of user permissions. Drupal has long offered extremely fine-grained permission controls. For example, you could allow users to edit (but not delete) their own blog entries. With that flexibility comes confusion, though, and the dozens of check boxes on Drupal 6’s default permissions screen often threw new administrators for a loop. Those permissions have been reworked for clarity, and there’s a new “administrator” role.

• Contextual edit links. When you’re logged in as the administrator, a Drupal 7 site now presents options as you hover your pointer over certain items you can control. For example: To edit a block in Drupal 6, you had to go to the Blocks configuration page, guess the name of the block you wanted to change, and click “configure”; in Drupal 7, you just point at the block and click. Much better!

Acknowledgments

“No man is an island,” wrote Renaissance poet John Donne, whose separate Elegy XIX (“To His Mistress Going to Bed”) is a gleeful celebration of erotic anticipation. So mix the profound and the profane, as they do in everyday life. These acknowledgments, too, mix thanks to both central and incidental influences. Some made the book what it is; some made me what I am. Which is which is left as an exercise for the reader.

First, the obvious. Robyn Thomas has been an attentive and friendly development editor: She kept me (comparatively) honest. Project editor Nancy Peterson gave difficult decisions about timing and content the attention they deserved, ensuring this book’s relevance and longevity. Technical editor Emma Jane Hogbin (emmajane.net) has been the real Drupal expert here, insisting on (among other things) the correct spelling, usage, and politics of “*nix” until I got it right. [Emma: I did finally get it right, didn’t I?] Greg Knaddison (growingventuresolutions.com) took time away from his busy schedule to step in when we needed some emergency fact-checking.

Darren Meiss and Scout Festa polished the copy swiftly and silently, like literary Rumpelstiltskins. When it was all finished, product marketing manager Glenn Bisignani ensured that the resulting volume would find its way into your hot little hands.

Thanks also go to the two people who got this project off the ground: my agent, Neil Salkind of the Salkind Literary Agency (salkindagency.com), and Peachpit’s senior acquisitions editor Wendy Sharp. By the same token, I’d like to thank the mob of computer book professionals who have guided me to this point over the years, particularly those met through various technical communities and the Studio B discussion list.

This list doesn’t include the many, many people involved in the book’s production and distribution, some of whom toil with names unknown to me. That they’re not explicitly included shouldn’t suggest a diminishment of their services or of my gratitude.

Thanks for other reasons go to Joanne Brodie, Laura Sherwood, Lisa Carlotta, and Ali Leal, along with others who recognize a pattern and believe they should be in that list. It’s cliché to say “You keep me sane,” so here’s a greater truth: You keep me happy.

It’s shocking that this is my third book, yet I haven’t thanked the ultimate originators of this project: my parents, Mimi and Conrad Geller. What kind of son would do such a thing? And comb your hair, it looks like a rat’s nest.

I’d like to also thank the good people of Oberlin, Ohio, where I decided to make my home a few weeks before starting this book. It was written almost entirely at the facilities of Oberlin College and the Oberlin Public Library, with occasional stints in several of the town’s restaurants, bars, cafes, and lobbies, and in the Wi-Fi–enabled town square. I couldn’t have chosen a better place.

Lastly, one more shot at the obvious: This book would have no purpose, and the web would be a poorer place, if not for the tens of thousands of people who program, test, use, document, critique, and otherwise enjoy Drupal. Its success has put high-quality, 21st-century web publishing within the reach of millions of people who’d otherwise be stuck with harder and less-capable options. It’s my sincere hope that this book continues the community’s work in some small way and strengthens the project’s goals.