Read an Excerpt
DrupalThe Guide to Planning and Building Websites
By Cynthia McCourt
John Wiley & SonsCopyright © 2011 John Wiley & Sons, Ltd
All right reserved.
Chapter OneIntroduction to Drupal Planning
The task of planning websites has fallen on the shoulders of project managers, graphic designers, software developers, requirements analysts, web strategists, user experience experts, and information architects, to name a few. All these roles have their own perspectives of how a site should look and come together. Their individual experiences and skills associated with planning sites influence what is included in the site, how it is built, and how it is maintained. Their planning processes will emphasize their strengths, and typically, there isn't anything wrong with that.
Unless the individuals filling these roles have some insight into what Drupal has to offer and how it gets the job done, the site plan could miss some features that could make the site even better than originally thought. It could also set expectations that Drupal does not support at the moment. With some insight into Drupal and how it works, any of the people in these roles can plan a Drupal site.
By the end of this book, you will have methods, tools, and techniques that can help you plan Drupal sites. By the end of this chapter, you should be able to recognize:
* The basics of how Drupal works * Some basic Drupal-related terms * How Drupal sites are different from HTML sites * Phases of a Drupal site's lifecycle
You likely know what Drupal is, but in case you do not, it is an open source content management system (CMS). It is used to build:
* Dynamically generated websites * Web applications * Document repositories * E-commerce sites * Learning sites * And more
To plan a Drupal site, knowing a little about how Drupal works can help. Don't worry; you don't have to be a developer to understand some of the basics. The following is offered as insight and to help the team communicate. If you are going to be a builder, developer, or themer, this short introduction is a must-read.
You do not need to know how to build the site in order to plan what you want, but the more you know about what Drupal can do and how it does it, the better off you will be. Let's start by taking a high-level view of what makes up Drupal.
Drupal's insides can be broken into the following three categories:
* Data storage * Modules (and all the other important code that makes Drupal run) * Theme code
The content of your site and its configuration settings are stored in a database. By default, each website has its own database. You can configure multiple sites to share a database as well. So, if you are planning multiple sites that need to share the same data, this is possible.
On the topic of multiple sites sharing, you should also know that you can have multiple sites, each with its own database, sharing the same Drupal installation. For example, assume you provide Drupal training and host the training sites. You can run all the training sites from one installation of Drupal. Each training site would have its own database, but they would share the code that is Drupal.
Data in the database is only part of your storage needs. If you have any media files or documents that you want to upload to the site, Drupal stores those files, by default, in a directory on the server associated with the site. If you have sites sharing the Drupal installation, the files will be kept separate from each other unless the sites have been configured to do otherwise. The setting that tells Drupal where to save files is stored in the database for that site. This means a series of sites using the same installation of Drupal won't get their media and documents mixed up.
If you have talked to anyone about Drupal, you probably heard him or her say something like, "There is a module that will do that."
Drupal is made up of a series of scripts that work together to produce the features you see in your site via a browser. The most common scripts are referred to as modules. Modules are bundles of code that enable Drupal, you, and/or your site visitors to see or do something in your Drupal site.
Drupal modules can be categorized. Here are four categories often referred to in the Drupal community:
* Core — Core modules are required for Drupal to work. You can see these modules in the administrative module list, but you cannot disable them. * Core optional — Optional modules provide functionality that you can add to your site. Some of the most commonly used modules will already be enabled for you by default, although you can disable them if you do not need them. Each new version of Drupal refines the number of core modules, making the enabling of commonly used features easier. * Contributed — Contributed modules are pieces of code that you can add to enhance the functionality of your site. Contributed modules are developed and maintained by members of the community. Some contributed modules are now part of the core. * Custom — Custom modules are pieces of code that you create to provide specific functionality for your site. Custom modules are maintained by you. You can contribute custom modules to the community, but unless someone wants to maintain the contribution for you, you will be responsible for its maintenance and support.
If you have a particular feature you want to include in your plan, searching Drupal.org for existing modules that might support that feature is sometimes helpful. Planning a feature whose module does not yet exist could impact how the site is developed, when it will be finished, and the skills you need on board to actually implement the site.
A Drupal theme refers to the bundle of code used to create what you see in the browser. In Drupal, that code is not restricted to the theme you install; you can also find theme code in:
* Drupal's core modules
* Contributed modules
* Custom modules
* The theme (or base theme)
* A subtheme (if a base theme is used)
When Drupal loads a page, it looks for instructions on how to display the content in a specific order. It starts with the subtheme (if used) and works its way back from there: subtheme, base theme, and then to various modules you have enabled, including Drupal's core modules. If you don't like what the theme code in a module does, you can override it in the theme itself.
If you are planning a site, why do you need to know about theming? There are costs associated with theme development that are not always easy to predict. The more features your site has, the higher the probability that your theme will need more than the basics you find in many free themes. Your Drupal themer will need your comps, your style guide, and wireframes to get started. To finish, your themer needs to know how the builder or developer will create the objects in the wireframes, and will need some access to the objects as they are added to the interface.
So, when you are planning your site development, keep in mind that unless you are going with the default theme settings in an off-the-shelf theme, your themer should be part of your development team to ensure collaboration is possible.
From Data to Site Structure
One of Drupal's components is data. It is important to understand how the data is used to create the site structure. Figure 1-1 illustrates the role data plays in the site.
Imagine that you have a web form on the screen in front of you. You're going to use this form to create an article that will be on your site. You type the title in a field on the form; you go to the next field and type the article; maybe you assign the article to a menu and tag it with some predefined terms or add a few of your own terms.
The title, body, menu, and terms are data that get stored in the database. Other data get stored as well, such as the date when you created the article and your username. All these bits of data are associated with the article or node you just created.
Nodes are displayed in the main content area of a page and are the primary source for creating URLs. A series of pages linked together via some type of navigation forms the structure of the site.
While planning any site, you see the word page come up frequently. But what is a page in Drupal? You may see it referred to as:
* A content type (the online form used to collect your text and create a specific type of node) * The web page you see in the browser * The dynamic results of a database query (also known as a view page) * The name of the theme template file that produces the web page you see in the browser
As you learn more about Drupal, the terminology will get easier to remember. To ensure positive and productive communication among the members of the site development team, remember that terms carry multiple meanings to people. This book helps you learn Drupal terminology that can help you communicate.
In addition to the concepts and terms introduced so far, Table 1-1 summarizes a few more terms that are helpful to know. Some of these terms may be foreign to you, and others may mean something completely different from what you are used to. If you are already familiar with the inner workings of Drupal and are simply reading this book to pick up some planning tips, feel free to skip this section.
GOING BEYOND HTML SITES
Now that you have some insight into how Drupal works, you have taken your first steps toward being able to think in Drupal. It might seem crazy, but it's true. When planning and building a Drupal site, you need to think differently than you may have done before, assuming you already have been exposed to web development. If you don't, you will likely limit what you can do on your site.
Traditional HTML website planning techniques fall short when used to plan a Drupal site. In an article comparing WordPress, Joomla!, Drupal, and Plone, Idealware said, "The flexibility of the [Drupal] system means it's important to think through the best way to accomplish what you want before diving in."
Before systems like Drupal existed, sites often were created using HTML; later, CSS (Cascading Style Sheets) was added. Traditional planning techniques focused on designing a site from three perspectives:
* Designing the overall look and page layout
* The content that would be on each page
* Where each page falls in the site index
Flowcharts were used to represent every page on the site and how it related to other pages. Unless you were a savvy HTML developer, you would build one page at a time, linking the pages via a menu or some other embedded link on one or more pages. Not everyone who was responsible for content on the Web was willing or able to be an HTML developer.
As the number of pages in sites grew, the need for database-driven, code-based sites increased. These types of sites provided ways to automate menu updates and page development. It took skills to create database-driven, code-based sites. With systems like Drupal, the days of building a code-based site from ground up are over.
So, what changes when you go from the traditional HTML site development practices to using a CMS like Drupal? Table 1-2 provides a few differences for your consideration.
If this comparison makes you nervous, don't be. You do not have to know how to code to make all this work. You just need to know that:
* The Drupal pages you see in a browser are not files on the web server. * Much of what Drupal has to offer is accessed using its GUI (graphical user interface), much like other software applications. * Drupal is a framework as much as it is a product, and therefore, you can shape it into what you want.
A WEBSITE'S LIFECYCLE
All websites have a lifecycle. Someone gets an idea and builds a site, the site is used, and the site goes away or becomes something different. This is probably obvious to you, so why bring it up?
The lifecycle of a site is a convenient way to illustrate the work that needs to be planned and performed. It addresses not only the site production but also what happens after the site is launched. If you know the path ahead, it is easier to anticipate and plan.
Figure 1-2 shows a simplified step-by-step process that represents what a site's lifecycle might be. The chapters in this book reflect this one-step-at-a-time approach because books are linear and, if this is your first exposure to the work performed to plan, build, and sustain a site, it is easier to experience it one step at a time.
However, the work performed during production is seldom performed in this exact order. Figure 1-2 illustrates one extreme, whereas Figure 1-3 illustrates another. Figure 1-3 shows that production can be an iterative process — moving from requirements to design to development and back to requirements until all decisions have been made and all development has been completed. At the heart of the production process is the need for the site. Without that focus, your project scope can expand beyond its original intent.
In reality, the production steps of a site during its lifecycle are something in between these two extremes. You can shape your production phase any way you want once you know the work that needs to be done. Chapter 2, "Managing Open Source Projects," explores different methods used to produce a site.
WHERE DOES PLANNING FIT IN?
The goal of those planning a Drupal website is the same as the goal that all roles have on a Drupal project: to help ensure the site is developed and delivered in such a way that it fulfills its purpose and meets the need. Table 1-3 describes planning tasks performed during the site's lifecycle.
This chapter provided your first steps in being able to think in Drupal and start planning. Here are a few things to remember going forward:
* Drupal is more than a content management system; it is a data management system. * Three components of Drupal are data, modules, and themes. * In order to plan the work performed during a site's lifecycle, you need to know what work gets performed and in what order. * Planning occurs at each step of the lifecycle.
The steps of the lifecycle don't just happen. They require someone to coordinate, facilitate, and, of course, manage them. Chapter 2 introduces different development methodologies that can be used for site production. It also provides some tips on how managing an open source project might differ from managing projects that use proprietary systems or create the system from scratch.
Excerpted from Drupal by Cynthia McCourt Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.