Using Drupal, 2nd Edition

Chapter 1. Drupal Overview

This book will show you how to build many different types of websites using the Drupal web publishing platform. Whether you’re promoting your rock band or building your company’s intranet, some of your needs will be the same. From a foundational perspective, your site will have content; be it audio or text or animated GIF images, a website communicates its content to the world. You will also need to manage this content. Although it’s possible to roll your own system with enough knowledge of the underlying web technologies, Drupal makes creating your website, adding new features, and day-to-day editing of content quick and easy. And finally, your website will have visitors, and this book will show you many different ways in which you can engage and interact with your community using Drupal.

This chapter will begin by providing the hard facts about Drupal: what it is, who uses it, and why they chose it. It will then dive into a conceptual overview, starting with what this ambiguous term “content management” actually means, and how we arrived at building websites this way. And finally, we’ll define and explain the core Drupal concepts that are necessary to understand how Drupal handles its content.

What Is Drupal?

Drupal is an open source^[1] content management system (CMS) being used by hundreds of thousands of organizations and individuals to build engaging, content-rich websites. Building a website in Drupal is a matter of combining together various “building blocks,” which are described later in this chapter, in order to customize your website’s functionality to your precise needs. Once built, a Drupal website can be maintained through the use of online forms, without any code having to be changed manually. Drupal is free to use, and it has an enormous library of constantly evolving tools that you can use to make your website shine.

Drupal is also a content management framework (CMF). In addition to providing site-building tools for webmasters, it offers ways for programmers and developers to customize Drupal using plug-in modules. Almost every aspect of Drupal’s behavior can be customized with these modules, and there are thousands of them, adding features from photo galleries to shopping carts to talk-like-a-pirate translators. Many modules have been freely contributed to the Drupal community and are available for download and use on your own Drupal-based website, too. All of the functionality that we’ll be discussing in this book is built using a combination of “core” Drupal and these community-created “contrib” modules.

And we would be remiss not to also acknowledge Drupal’s community; the wetware element of Drupal is often cited as one of Drupal’s biggest assets. When Drupal 7 was released in January 2011, nearly 1,000 members of the community contributed code to the core software. Additionally, more than 15,000 developers maintain contributed modules, with countless more helping with testing, documentation, usability, design, accessibility, user support, translations, and other important areas of the project. Those familiar with evaluating open source platforms will attest to the importance of a thriving community base.

Who Uses It?

Over the last few years, the popularity of Drupal has exploded, to the point where some pretty big names have taken notice. Media companies such as Sony BMG Records, Lifetime Television, and Al Jazeera are using Drupal as a means of building loyal communities around their products. Magazines such as Spin, Popular Science, and Fast Company use Drupal to provide interactive online content to their readers. Nonprofits such as Amnesty International, Oxfam, and the Electronic Frontier Foundation use Drupal to coordinate activism on important issues. Ubuntu Linux, Eclipse, and Java are open source projects that employ Drupal to nurture their contributor communities. Bloggers such as Tim Berners-Lee, Heather B. Armstrong (a.k.a., Dooce), and the BlogHer community use Drupal as their publishing platform. Technology companies including Twitter, Symantec, and eBay make use of Drupal to connect with their customers. Many levels of government around the world, including the White House, the United Nations, and the UK government’s open data portal, are also using Drupal to provide more transparency and better connect with their citizens.

What these websites have in common is a need for powerful publishing options and rich community features.

The Drupal Showcase website, shown in Figure 1-1, highlights some of these and other high-profile Drupal websites. Drupal’s own website also has a Drupal case studies section containing detailed case studies and success stories. Additionally, Dries Buytaert, the Drupal project founder and project lead, maintains a list of several high-profile Drupal websites on his blog at http://buytaert.net/tag/drupal-sites.

Figure 1-1. The Drupal Showcase highlights high-profile sites in multiple industries, categories, and countries

What Features Does Drupal Offer?

Drupal provides a number of features, which are explained in greater detail in Chapter 2. These include:

Flexible module system

Modules are plug-ins that can modify and add features to a Drupal site. For almost any functional need, chances are good that either an existing module fits the need exactly or can be combined with other modules to fit the need, or that whatever existing code there is can get you a good chunk of the way there.

Customizable theming system

All output in Drupal is fully customizable, so you can bend the look and feel of your site to your will (or, more precisely, to your designer’s will).

Extensible content and entity system

You can define new types of content (blogs, events, words of the day) on the fly, and even add custom fields for the different content types. Contributed modules can extend this even further by providing new kinds of fields and different ways to manipulate them. Best of all, these fields can also be attached to anything in the system representing itself as an entity, such as users, comments, and taxonomy (categories).

Innate search engine optimization

Drupal offers out-of-the-box support for human-readable system URLs, and all of Drupal’s output is standards-compliant; both of these features make for search-engine-friendly websites. There are also other contributed modules that take SEO capabilities even further.

Role-based access permissions

Custom roles and a plethora of permissions allow for fine-grained control over who can access what within the system. And existing modules can take this level of access control even further—down to the individual user level.

Social publishing and collaboration tools

Drupal has built-in support for tools such as group blogging, comments, forums, and customized user profiles. The addition of almost any other feature you can imagine—for instance, ratings, user groups, or moderation tools—is only a download away.

A Brief History of Content Management

Before looking any closer at Drupal, let’s take a brief trip back in time to the days before content management systems. To understand how Drupal and other CMS packages simplify your work, we’ll take a look at how things worked when the Web was young.

A Historical Look at Website Creation

Back in the dim recesses of time (the 1990s, for those who remember zeppelins and Model T cars), web pages were nothing more than simple text files nestled comfortably into folders on a server somewhere on the Internet. With names like index.html, news.html, about_us.html, and so on, these files were viewable by anyone with a web browser. Using HTML (hypertext markup language), these files could link back and forth to each other, include images and other media, and generally make themselves presentable. A website, as the hipsters of that day would explain, was just a collection of those files in a particular folder, as pictured in Figure 1-2.

Figure 1-2. A historical look at website structure

This system worked pretty well, and it made sense. Every URL that a user on the Internet could visit corresponded to a unique .html file on the web server. If you wanted to organize your site into sections, you made a folder and moved the files into that folder; for example, http://www.example.com/news would be the address to the News section of the site, and the 1997 newsletter would be located at http://www.example.com/news/fall_1997_products.html. When the webmaster (or the intern) needed to fix a problem, he could look at the page in his web browser and open up the matching file on the web server to tweak it.

Unfortunately, as websites grew in size, it was obvious that this approach didn’t scale well. After a year or so of adding pages and shuffling directories around, many webmasters had dozens, hundreds, or sometimes even thousands of pages to manage. And that, friends, caused some serious problems:

Changing the site’s design required an enormous amount of work

Information formatting, layout, and other site design was done individually on every single page. Cascading style sheets (CSS) hadn’t yet taken the web world by storm, so tasks as simple as changing the site’s default font required hand-editing (that’s right) every single file.

The site structure resulted in massive duplication of content

Most designs for websites included a standard footer at the bottom of the page with copyright and contact information, a header image or some kind of recurring navigation menu at the top, and so on. If anything changed, every file had to be updated. If you were very, very lucky, all the webmasters before you had been conscientious about making sure that there were no layout variations, and this would be a scriptable change. Most webmasters weren’t lucky, and to this day mutter darkly about sites built using FrontPage, PageMill, Dreamweaver, HotDog Professional, and Notepad all at once—depending on who edited the files last.

Websites were impossible to keep consistent and up-to-date

Most complex sites were already organized into directories and subdirectories to keep things reasonably tidy. Adding a news story in the news directory meant that you also had to update the “overview” page that listed all news stories, perhaps post a quick notice on the front page of the website, and (horror!) remember to take the notice down when the news was no longer “fresh.” A large site with multiple sections and a fair amount of content could keep a full-time webmaster busy just juggling these updates.

The Age of Scripts and Databases

The search for solutions to these problems prompted the first real revolution in web design: the use of scripts and common gateway interface (CGI) programs. The first step was the use of special tags called server-side includes (SSI) in each HTML file. These tags let web designers tell the web server to suck in the contents of another file (say, a standard copyright message or a list of the latest news stories) and include it in the current web page as if it were part of the HTML file itself. It made updating those bits much easier, as they were stored in only one place.

The second change was the use of simple databases to store pieces of similar content. All the news stories on CNN are similar in structure, even if their content differs. The same is true of all the product pages on Apple, all the blog entries on Blogger, and so on. Rather than storing each one as a separate HTML file, webmasters used a program running on the web server to look up the content of each article from the database and display it with all the HTML markup for the site’s layout wrapped around it. URLs such as http://www.example.com/news/1997/big_sale.html were replaced by something more like http://www.example.com/news.cgi?id=10. Rather than looking in the news directory, then in the 1997 directory, and returning the big_sale.html file to a user’s web browser, the web server would run the news.cgi program, let it retrieve article number 10 from the database, and send back whatever text that program printed out.

All these differences required changes in the way that designers and developers approached the building of websites. But the benefits were more than worth it: dozens or even hundreds of files could be replaced with one or more database-driven scripts, as shown in Figure 1-3.

Figure 1-3. The move from individual files to database-driven scripts

Even with those improvements, however, there were still serious challenges:

Where do I change that setting again?

Large sites with many different kinds of content (product information, employee bios, press releases, free downloads, and so on) were still juggling an assortment of scripts, separate databases, and other elements to keep everything running. Webmasters updating content had to figure out whether they needed to change an HTML file, an entry in a database, or the program code of the script.

Too many little pieces were cobbled together

Dynamic content—such as discussion forums or guestbooks where visitors could interact—required their own infrastructure, and often each of these systems was designed separately. Stitching them together into a unified web experience was no simple task.

The Content Revolution

Slowly but surely, programs emerged to manage these different kinds of content and features using a single, consistent user interface. The older generation of software focused on a particular task or application, but newer CMS implementations offered generalized tools for creating, editing, and organizing the information on a website. Most systems also provided mechanisms for developers to build add-ons and new features without reinventing the wheel. Figure 1-4 illustrates how a content management system uses a single database and script to integrate all of these features.

Figure 1-4. The structure of an integrated, database-driven website

Drupal is one of these next-generation content management systems. It allows you to create and organize many kinds of content, provides user management tools for both the maintainers of and the visitors to your site, and gives you access to thousands of third-party plug-ins that add new features. Dries Buytaert, the founder of the Drupal project, said in a speech to the 2007 Open Source CMS Summit that his goal for Drupal was to “eliminate the webmaster.” That might sound a bit scary if you are the webmaster, but after that first thought, the implications are exciting. Thanks to Drupal, the grunt work of keeping thousands of pages organized and up-to-date vanishes: you can instead focus on building the features that your site needs and the experience that your users want.

How Does Drupal Work?

At a conceptual level, the Drupal stack looks like Figure 1-5. Drupal is a sort of middle layer between the backend (the stuff that keeps the Internet ticking) and the frontend (what visitors see in their web browsers).

Figure 1-5. How Drupal and its conceptual layers fit with other layers of a website

In the bottom layers, things like your operating system, web server, database, and PHP are running the show. The operating system handles the “plumbing” that keeps your website running: low-level tasks such as handling network connections, files, and file permissions. Your web server enables that computer to be accessible over the Internet, and serves up the correct stuff when you go to http://www.example.com. A database stores, well, data—all of the website’s content, user accounts, and configuration settings—in a central place for later retrieval. And PHP is a programming language that generates pages dynamically and shuffles information from the database to the web server.

Drupal itself is composed of many layers as well. At its lowest layer, it provides additional functionality on top of PHP by adding several subsystems, such as user session handling and authentication, security filtering, and template rendering. This section is built upon by a layer of customizable add-on functionality called modules, which will be discussed in the next section. Modules add features to Drupal and generate the contents of any given page. But before the page is displayed to the user, it’s run through the theme system, which allows modification and precise tweaking for even the pickiest designers’ needs.

The theme system outputs page content, usually as XHTML or HTML5, although other types of rendering are supported. CSS is used to control the layout, colors, and fonts of a given page, and JavaScript is thrown in for dynamic elements, such as collapsible fieldsets on forms and drag-and-drop table rows in Drupal’s administrative interface.

We’ve talked about the “old” way of building websites using static HTML files, the transition to collections of scripts, and the “new” way: full-featured web applications that manage the entire website. This third way—Drupal’s way—requires a new set of conceptual building blocks. Every website you build with Drupal will use them!

Modules

Just about everything in Drupal revolves around the concept of modules, which are files that contain PHP code and a set of functionalities that Drupal knows how to use. All of the administrative- and end-user-facing functionality in Drupal, from fundamental features such as the ability to log in or create content to dynamic photo galleries and complex voting systems, comes from modules. Some examples of modules are the Contact module, which enables a site-wide contact form, and the User module, which handles user authentication and permission checking. In other CMS applications, modules are also referred to as plug-ins or extensions.

There are two types of modules: “core” modules, which are included with Drupal itself, and “contributed” modules, which are provided by the Drupal community and can be separately downloaded and enabled. Apart from a few required core modules, all modules can be turned on or off depending on your website’s precise needs.

Though there are contributed modules that offer “drop in and go” functionality, over the years the Drupal community has generally focused on modules that do one thing well, in a way that can be combined with other modules. This approach means that you have almost limitless control over what your website looks like and how it behaves. Your image gallery isn’t limited by what the original developer thought an image gallery ought to look and act like. You can drop in ratings or comments and sort the pictures by camera type rather than date if you’d like. In order to have this flexibility, however, you have to “build” the functionality in Drupal by snapping together various modules and tweaking their options, rather than just checking off a checkbox for “image gallery” and leaving it at that. Drupal’s power brings with it a learning curve not encountered in many other CMS packages, and with the plethora of available modules, it can be daunting trying to determine which to use. The rest of this book—as well as Appendix B, which is dedicated to tips and tricks on how to determine module quality and suitability for your projects—is here to help you solve this problem.

Users

The next building block of a Drupal website is the concept of users. On a simple brochure-ware website that will be updated by a single administrator and visited only by potential customers, you might create just a single user account for the administrator. On a community discussion site, you would set up Drupal to allow all of the individuals who use the site to sign up for it and create their own user accounts as well.

Note

The first user you create when you build a new Drupal site—User 1—is special. Similar to the root user on a UNIX server, User 1 has permission to perform any action on the Drupal site. Because User 1 bypasses these normal safety checks, it’s easy to accidentally delete content or otherwise break the site if you use this account for day-to-day editing. It’s a good idea to reserve this account for special administrative tasks and configuration, and create an additional account for posting content.

Every additional user can be assigned to configurable roles, like “editor,” “paying customer,” or “VIP.” Each role can be given permissions to do different things on the website: visiting specific URLs, viewing particular kinds of content, posting comments on existing content, filling out a user profile, even creating more users and controlling their permissions. By default, Drupal comes with two predefined locked roles: authenticated user and anonymous user. Anyone who creates a user account on the site is automatically assigned the “authenticated user” role, and any visitors who haven’t yet created user accounts (or haven’t yet logged in with their username and password) have the “anonymous user” role. In addition, Drupal provides a third predefined, but optional, role: administrator. Any user given the administrator role will automatically have access to all permissions available on the site.

Content (Nodes)

Nodes are Drupal’s next building block, and one of the most important. A critical part of planning any Drupal site is looking at your plans and deciding what specific kinds of content (referred to by Drupal as content types) you’ll be working with. In almost every case, each content type will be a different kind of node.

All nodes, regardless of the type of content they store, share a handful of basic properties:

• An author (the user on your site who created the content)

• A creation date

• A title

• Body content

Do you want to create a page containing your company’s privacy policy? That’s a node. Do you want users to be able to post blog entries on the site? Each entry is a node. Will users be posting links to interesting stories elsewhere on the Web? Each of those links is stored as—you guessed it—a node.

In addition to nodes’ basic, common properties, all nodes can take advantage of certain built-in Drupal features, like flags that indicate whether they’re published or unpublished and settings to control how each type of node is displayed. Permissions to create and edit each type of node can also be assigned to different user roles; for example, users with the “blogger” role could create “Blog entry” nodes, but only “administrator” or “editor” users could create “News” nodes.

Note

Nodes can also store revision information detailing each change that’s been made since they were created. If you make a mistake (deleting an important paragraph of the About Us page, for example), this makes it easy to restore a previous version.

Drupal comes preconfigured with two types of nodes: “Basic page” and “Article.” The only differences between those two types of nodes are their default configuration settings. “Basic page” nodes don’t display any information about the author or the date on which they were posted. It’s well suited to content like “About Us” and “Terms of Service,” where the original author is irrelevant. Article nodes do display that information, are set to appear on the front page of the site whenever they’re posted, and allow the content creator to add tags and images to the content. The result is a blog-like list of the latest news on the site.

You can use Drupal’s content administration tools to create other node types yourself. Many administrators create a “press release” or “announcement” node type to post official announcements, while other contributors can post regular “article” nodes. Plug-in modules can also add new kinds of nodes to Drupal’s content system that offer more features. One example (which comes with Drupal) is the Poll module. When users create new Poll nodes, they create a list of poll questions rather than the usual “body” content. Poll nodes, when they’re displayed to visitors, appear as voting forms and automatically tally the number of votes for each question.

Additionally, other modules can add to nodes’ properties such as comments, ratings, file upload fields, and more. From the control panel, you can specify which types of nodes receive these features. Figure 1-6 illustrates this concept.

Figure 1-6. All nodes in the system share a basic set of properties; nodes may define additional, specific fields, and modules can add extra features to nodes as well

The idea that new modules add properties and build on top of the node system means that all content in Drupal is built on the same underlying framework, and therein lies one of Drupal’s greatest strengths. Features like searching, rating, and comments all become plug-and-play components for any new type of node you may define, because under the hood, Drupal knows how to interface with their base elements—nodes.

Using plug-in modules to add new types of nodes—or to add extra fields to existing node types—is a common task in Drupal. Throughout the book, we’ll be covering a handful of the thousands of plug-in modules, and you’ll learn how to build complex content types using these basic tools.

Entities and Fields

New in Drupal 7 is the concept of entities, an additional layer of abstraction above nodes that spans multiple system components, including comments, users, and files. This abstraction provides the same functionality-reuse capability that nodes provide, but expand them even further because functionality can work across multiple entities, not just on nodes. Examples of entities provided by Drupal core are nodes, comments, users, files, and taxonomy. Contributed modules, such as Drupal Commerce covered in Chapter 9, can also provide their own entity types.

The most common cross-entity feature in Drupal is the field system. Entities provide some default data-entry fields—for example, nodes expose a Title and optional Body field; users provide a username and password field—but often sites need to capture additional data beyond the basics. Drupal provides a number of additional field types—text, number, list, image, etc.—that can be added to any entity, or even shared across entities. We’ll cover fields in depth in Chapter 3, and work with them in all later chapters as well.

Figure 1-7 illustrates how entities, entity types (also known as bundles in programmer-speak), and fields work together to allow Drupal to be highly customized to specific data storage requirements.

Figure 1-7. Entities are a layer of abstraction above other entity types, and allow features such as fields to be reused across multiple entity types

Ways of Organizing Content

Another important building block is really an entire toolbox of techniques for organizing the content that makes up your site. First-generation websites grouped pages using folders and directories. Second-generation sites used separate scripts to manage and display different kinds of content. Drupal, though, maintains almost everything as a node. How can you break your site up into separate topical sections, user-specific blogs, or some other organizational scheme?

First, each individual node on your site gets its own URL. By default, this URL is something like http://www.example.com/node/1. You can turn these URLs into user-friendly paths like http://www.example.com/about using Drupal’s built-in Path module. For organizational purposes, all of these nodes are treated as a single “pool” of content. Drupal creates every other content page on your site—topical overviews, recent news, and so on—by pulling up lists of nodes that match certain criteria and displaying them in different ways. Here are a few examples:

The front page

By default, the front page of a Drupal site is a bloglike overview of the 10 most recently posted articles. To build this, Drupal searches the pool of content for nodes with the “Published” flag set to true, and the “Promote to front page” flag set to true. In addition, it sorts the list so that nodes with the “Sticky” flag are always at the top; this feature is useful for hot news or announcements that every user should see.

The Taxonomy module

We mentioned earlier that plug-in modules can add new pieces of information to nodes, and that’s exactly what Taxonomy does. It allows the administrator of a site to set up categories of topics that nodes can be associated with when they’re created, as well as blog-style free-tagging keywords. You might use this module to create a predefined set of “Regions” for news stories to be filed under, as well as “Tags” for bloggers to enter manually when they post. The Taxonomy module calls all of these things terms, and provides a page for each descriptive term that’s used on the site. When a visitor views one of these pages, Drupal pulls up a list of all the nodes that were tagged with the term.

The Blog module

Drupal’s built-in Blog module implements a multiuser blogging system by doing just three things. First, it adds a new node type called “Blog post.” Second, it provides a listing page at http://www.example.com/blog that displays any nodes of type Blog that also have their “Published” flag set to true. (If a blog post has its “Published to front page” flag set to true, it will show up on the front page as well; Drupal never hides content on one page just because it appears on another.) Third, it provides a custom page for each user on the site that displays only blog posts written by that user. http://www.example.com/blog/1, for example, would display all blog post nodes that are published and were written by User 1—the administrator.

Views

For anything fancier than the aforementioned cases, Drupal has an add-on module called Views, which we’ll be using in nearly all of the chapters in this book. The Views module is essentially a graphical interface for creating highly customized listings, from sortable product comparison tables to sidebar blocks listing recent content to calendars of events. You’ll learn more about the Views module in Chapter 3.

Drupal comes with several other modules that provide different ways of organizing nodes, and you can download hundreds of plug-in modules to organize your site in a variety of ways. The important thing to remember is that almost all “pages” in Drupal are one of two things: a specific piece of content (node), or a list of nodes that share a particular set of properties.

Types of Supporting Content

In addition to content and listings of content, there are also various ways to supplement the content on the page. Two such types of supporting content included with Drupal core are comments and blocks.

Comments are merely responses by a user to a piece of content, and exist only in relation to that content. Users may post comments to add their thoughts to the subject matter within a node, as they often do when a particularly controversial subject comes up on a blog entry or forum topic. Like nodes, comments are entities that can be expanded with fields or other contributed modules to add features such as ratings.

Blocks are content “chunks” that fit into regions on the page such as the sidebars, footers, and headers of a Drupal site. They’re generally used to display helpful links or dynamic lists such as “Most popular content” or “Latest comments” and similar items. While nodes take center stage displaying content, blocks help give a single piece of content some context in the structure of your site.

Many times, blocks will display different content depending on which user is currently logged in: a “Comments by your buddies” block, for example, might display a list of posts by users that the current visitor has added to her Buddies list. Each user who logs in will see a different list. Additionally, blocks may be configured to show up only on certain pages, or to be hidden only on certain pages.

Getting Help

It’s easy to focus only on the functionality you get for free with an open source application. But it would be a mistake to forget that the Drupal community itself is another vital building block for your website!

As you go through the hands-on examples in this book, you might run into some issues particular to your installation. Or, you might encounter issues as new versions of modules are released. Fortunately, the Drupal community has a wealth of resources available to help you troubleshoot even the nastiest error you might encounter:

• The Drupal Community Documentation contains information on everything from community philosophies to nitty-gritty Drupal development information.

• The Getting Started Guide contains some particularly useful information to help get you through your first couple of hours with Drupal.

• The Troubleshooting FAQ has useful tips and tricks for deciphering error messages that you might encounter.

• For more one-on-one help, try the Support forums or the Drupal Answers website for everything from preinstallation questions to upgrade issues.

• If your question is about a specific module, you can post a “support request” issue (or a “bug report” if it’s a blatant problem) to the module’s issue queue, which reaches the module’s maintainer(s). A helpful video on how to maneuver around the Drupal.org issue queues is available from http://drupal.org/node/273658, and issue queues are also discussed in Appendix B.

• There’s also a #drupal-support IRC channel on irc.freenode.net if you’re more of the chatty type.

  Note

  Other IRC channels you might want to join include #drupal, for general Drupal chit-chat, and #drupal-contribute, if you’re interested in participating in the community or you want to keep an eye on what’s coming down the pipe (note that #drupal-contribute is not a support channel!). There are also numerous topical channels for everything from specific modules to general areas of Drupal like usability or design. For a list of all Drupal IRC channels, see http://drupal.org/irc.

  IRC is not only an invaluable tool for getting your problems solved, but it’s also one of the best ways to get to know the people behind the project. While issue queues are normally “strictly business,” IRC is not only where important stuff happens, but also where you learn about key contributors’ pet cats, and their cats’ video game collections.

• Finally, there are local Drupal user groups all over the world, which often hold monthly meetups and larger regional events called “camps” where you can meet real humans who understand that “Drupal” is not some kind of medical condition or a nondairy topping. It’s a great way to get to know members of the community firsthand, and learn all sorts of new things about Drupal! Check groups.drupal.org to find a group near you.

Note that when asking for help, it’s always best to do as much research as you can first, and then politely ask direct, to-the-point questions. “Foo module is giving me the error ‘Invalid input’ when I attempt to submit ‘Steve’ in the name field. I tried searching for existing solutions, and found an issue at http://drupal.org/node/1234 filed about it, but the solution there didn’t fix it for me. Could anyone give me some pointers?” will get far better, faster, and more meaningful responses than, “Why doesn’t Foo module work? You developers are useless!” or “How can I build a website with Drupal?” And oftentimes, you’ll find that during the process of typing out your question in enough detail for someone else to answer it, you come up with the solution yourself! For other tips on getting useful help in an open source community, see http://catb.org/esr/faqs/smart-questions.html.

Conclusion

In this chapter, you’ve learned what Drupal is. You have traced the history of websites and content management to better understand the challenges inherent in keeping a growing site healthy. We’ve examined the conceptual building blocks that Drupal uses when building next-generation sites, as well as how they fit together. We’ve also covered numerous ways to get help if you’re stuck. In the following chapter, you’ll put these pieces together by creating your very first Drupal website!

---

^[1] For more on the open source software movement, please see http://opensource.org—which, incidentally, is also a Drupal site.