Chapter 3. Fleshing Things Out: Getting ready to prototype

This chapter deals with some practical issues of planning a Drupal implementation. In the first section, Working with Content, we’ll discuss why it’s vital to start working with real content right away in your Drupal site. In the second, Choosing Modules, we talk about the process of selecting the right modules for your site. There’s also an entirely non-comprehensive list of contributed modules that you might find Very Useful.

Working with content

In the Old Days™, building a promotional website was a fairly straightforward affair. You’d go through a discovery process, create a couple of wireframes—generally for the home page and 1-2 interior pages, then mock up and iterate designs. When those designs were approved by the client, you’d whip up a fancy template in HTML and start laying in the content and images.

Content, almost always, came later. You’d have a sense of the site map, and how it might evolve—you needed that for navigation—but the actual content was rarely something you saw in the early phases of developing wireframes. Generally, this wasn’t a problem; as you were coding the content by hand within the template, you could adjust the template relatively easily once you had content to work with.

With Drupal, as with many other content management systems, things aren’t that easy. Some elements will be familiar, especially if you’ve gotten used to systems like Wordpress. At the most basic level, you’re dealing with a series of page templates, and those templates put your content into specific areas of the page. You style those templates in your theme layer, and that makes the page look good.

What makes Drupal complex, but also terrific, is the amount of control you have over almost every aspect of the site’s pages. The key to making sense of this complexity is to understand that each page of a Drupal website is a collection of different pieces of content that are located within your site’s database and files. Because of Drupal’s inherent flexibility, that content can be organized and formatted in any number of different ways—and it will need to be, in order to finish the project with a working site.

For this reason, I’ve found that two things are essential to getting started on any Drupal project:

  1. Shifting the way that you think about page layout for the web. You’re not looking at it in terms of generic page grids anymore (although that’s certainly a component of it). To actually succeed in creating a Drupal site, you need the ability to think of a page layout in terms of the organization of information on the page. What will the content be? What are the different sections you’ll need, and how will they be organized on the page? How will the content be found or searched for—in top level navigation, by browsing categories, or some other way? Visual design is an important component of that, but it should always come after this first issue has been dealt with.

  2. As a way of reinforcing #1, every Drupal project should start with 1–3 samples of actual content that will appear on the actual site.

Over the years, I’ve seen some resistance to this concept—developers, for example, like to think in terms of building things quickly, and clients can have a hard time grasping the idea that they need to be able to provide content before they see page layouts. But there’s a very specific reason for this need. As mentioned above, every page of your Drupal site is constructed from different bits of content that are stored in different locations in the system, and then collected onto the page. This means, in order to construct the actual pages, you need to start loading actual content into the system as soon as you can.

Drupal works by organizing content into different content types (see Chapter 1 if you need a definition of what a content type is). It also allows you to add and display as many custom fields on those content types as you can (which is very useful for making content look the way you want it to on the page). This flexibility is one of the key reasons it is imperative to work with actual content instead of placeholder text. Seeing the content allows you to visualize its fundamental components, and allows you to set some formatting parameters that will protect the client’s content strategy after they take over management of the site.

The layout of a Drupal page can be constructed from any number of things:

  1. Actual node content (remember, Drupal calls content nodes);

  2. Views displays that organize several nodes together.

  3. Blocks that can be created either with custom text/HTML or as Views displays.

  4. Menus that can be created in any number of ways.

  5. Custom code built into the page template.

For example, a standard events page on a corporate website would likely consist of the following (see Figure 3-1):

  1. An “event” content type, with a Title, Description, Date, and Link to an external website or registration page.

  2. A View called “events” which would list all events in chronological order.

  3. Displays based on the “events” View that would show as a block of titles and dates for the home page, an Events archive (showing events that have passed) and an “Upcoming Events” page (showing events that haven’t happened yet).

The events page of alberieco.com. Design by the zen kitchen.
Figure 3-1. The events page of alberieco.com. Design by the zen kitchen.

In addition to these, you might have categories for different types of events, links to external resources (such as a book to read or a packing list), and any other permutation of the Event content type your clients can come up with. Starting the process with dummy content only gets you so far; if the live content will be different than what you’re assuming, you’ll find yourself with a load of headaches before you know it.

Trial by fire

My first major Drupal site was for a small business owner in the Boston area. In our initial discussions, we’d talked about doing a simple refresh of her existing site, and I sold her on the idea of doing it in Drupal. We discussed the site map, and the way that content was going to be organized, but she hadn’t developed any of the new content yet. As was my process at the time, I worked up a proposed layout for the homepage and an interior page, and she approved it with no problems. Look and feel established, I started up an installation of Drupal and started creating the content types that would organize the site’s content, working with generic placeholder text.

The site map we’d originally agreed on was fairly simple:

  1. A Services page that listed all the services her company offered;

  2. An Events page that listed upcoming events (this would require an event content type)

  3. A News page that listed current news (this would require a news content type)

  4. An About page that listed all the staff and what they brought to the company;

  5. A Resources page that listed resources for her clients;

  6. A contact form that would allow users to get in touch with her for consultations.

All of this seemed pretty straightforward. When the content started coming in, it turned out that the Services page was actually several different services, each with fourteen pages of descriptive content. The staff bios were two pages long. Events could be categorized, and had to be navigated, in three separate ways. And the landing pages for each of these content sections should only show teaser content (i.e. a picture, title that links to the full content, and an intro paragraph). Most of her requests made perfect sense, but none of them had been discussed in our discovery sessions, nor were they reflected in the designs that had been comped and approved. Eventually, I had to re-do all the work that had already been done, which threw the project into massive delays.

From that point on, I made it part of my discovery process to get actual content from the client before I start working with Drupal on any project. While this policy isn’t without its challenges, it has resulted in a much more efficient workflow over the years. This is especially true for large, complex sites—but as with the previous example, it can even be true of smaller sites.

Working with Content Types: a High-Level Overview

As mentioned previously, Drupal works by separating content into distinct content types. The best way to determine which content types your site will need is through the site map and wireframes that were done in the UX/discovery phase. Site maps and high-level navigation items will guide you in creating content types, while wireframes and site designs offer insight into the types of content you need to accommodate (text, images, video, etc.), what special fields you might have to create, and how those fields should be formatted (see Figure 3-3).

If you (or someone on your team) developed a site map during the Discovery or UX phase, you can work directly with the site map to determine content types. Working with a printout, or in a program like OmniGraffle, start marking up the site map with notes (see Figure 3-2). These notes should include possible fields you might need, categories users might expect for the content, and other questions that arise from the site map. For example: do we want to have testimonials from clients? Should those appear as a block on several pages, or just as a page? How are we organizing news items? How many authors will be on the blog? Etc. This will help you get oriented, and you can better communicate to the client and the team what the content needs will be.

A site map can give you a head start on which content types you’ll need. This site map notes with double boxes which content pages will be coming from Views; each of those types of content lists could be its own content type, e.g., Blog Entries, Videos, Events, etc.
Figure 3-2. A site map can give you a head start on which content types you’ll need. This site map notes with double boxes which content pages will be coming from Views; each of those types of content lists could be its own content type, e.g., Blog Entries, Videos, Events, etc.

When you have sample content from the client, print out the content file (double-sided) and start writing on it. Note extra fields, taxonomy categories you’ll have to create, and how to break up the content on the landing pages for that section. If wireframes or site designs have already been created, be sure to check them against the content you’ve received; you’d be surprised how often they differ.

Annotating a wireframe can help you figure out where content is coming from in your Drupal site. In this mockup for a project in process, most of the page information is coming in (ideally) from an Eventbrite feed.
Figure 3-3. Annotating a wireframe can help you figure out where content is coming from in your Drupal site. In this mockup for a project in process, most of the page information is coming in (ideally) from an Eventbrite feed.

The number of extra fields you include in a content type will vary; I’ve had projects where every content type was basically a title, description and image, and I’ve had projects where every content type required anywhere from 5–30 extra fields, each of which had to be formatted and displayed in a certain way based on what situation the user was in at the time they were viewing it. This, if you haven’t guessed yet, is why you need the content FIRST—if you think you’re doing the former, and find out you’re doing the latter, your life will be very, very bad while you switch gears.

Once you’ve sketched out an overview of what you’re really looking at, and confirmed these assumptions with the client, it’s time to start creating the content types themselves. Building out content types can be one of the most time intensive pieces of creating a Drupal site if the content types you’re working with are very complex.

First you start creating fields, then re-order them if you need to, change the way they’re displayed (do they need the field label? Should it be above the content or in line with it? Do you even need to show the field? Do we want to group them a certain way?), and create a single piece of content to test that it looks right on the page. For a very simple content type (most News content types, or Basic Page content types, for example), this can take a few minutes. For more complex content types (such as a Product description, or a content type that maps to several pieces of related content), this back and forth can take days.

Because this chapter is focused on planning and managing a project, we won’t get into the process of how to create content types; if you have never done it before, check out the following resources on creating content types in Drupal 7:

http://www.youtube.com/watch?v=iibPX5KBFu4: A video demonstration of creating content types.
http://yadadrop.com/drupal-video/drupal-7-creating-content-types: Another video tutorial.

Also, check out the next chapter, Choosing Modules, for some modules that can help with content types and custom fields.

Setting up content types is one piece of the content puzzle. Once you’ve gotten the content types somewhat organized, and sample content into the site, you want to start putting them into Views displays. I, like many of my Drupal brethren, have a love/hate relationship with Views. On one hand, Views is an incredibly powerful tool for getting content to display in any possible combination you can think of. This makes it easier to build massively complex sites while keeping them relatively easy to maintain. On the other hand, Views is so complex that even the most seasoned developers occasionally can’t make heads or tails of it.

For the designer, or even the solo site builder, it’s useful to have the basics down when it comes to Views. While the first few Views you create will always leave you grinding your teeth, it’s actually relatively easy to put them together once you get the system down. Additionally, Views allows you to clone views and individual displays, which makes it much easier to create additional views once you have the first one finished. For the purposes of this chapter, we’re only going to discuss how to figure out which Views you’ll need, and how they should be displayed.

To figure out which Views you need, start with your site map and any wireframes that have been created in the design process. Anything that looks like a list of content, titles, or links to content, is most likely going to require a View. Sample views might include:

All of these things can be created with Views.

By default, Views allows you to create the following displays:

Each of these displays can be output in a variety of formats, including an HTML list (good for building sidebar menus or lists of related content), an unformatted list (the default display, good for displaying content on a page), tables and multi-column grids. Adding a few handy contributed modules can open up more possibilities for formatting your Views displays:

Again, since we’re focusing on content strategy here and less on Drupal implementation, we won’t get into how to create Views in this book. However, there are quite a few excellent video tutorials that you can check out if you haven’t played with Views yet:

http://lin-clark.com/blog/intro-drupal-7-intro-views-pt-1: Intro to Views, by Lin Clark (just ignore the Drush stuff).
http://www.metaltoad.com/Drupal-7-Tutorial-Creating-Edit-Content-Links-Views: a Very Comprehensive tutorial from Dan Linn at Metal Toad Media on creating “edit content” links using Views. It also gives a quick overview of the new Views interface, which is a massive improvement over the last version.
http://nodeone.se/blogg/learn-views-screencast-series-summed-up: an entire set of Drupal videos that walk through the Views process in a variety of contexts, by NodeOne in Stockholm, Sweden. I cannot recommend these videos highly enough.

Putting this all together

In theory, each member of the team will be dealing with its own piece of this giant puzzle called building a website. In practice, especially on small teams, you’ll often find yourself switching back and forth among different phases of the content development cycle. A typical Drupal project, for example, might look like this:

  1. Site map and wireframes are created and approved;

  2. The designer (you) starts adding in visual elements;

  3. The front-end developer (or you) starts creating content types and fields;

  4. Site content comes in, and looks different from the wireframes and designs that have been approved;

  5. The front-end developer (or you) goes back and starts changing content types, fields, views, etc. to mesh with the content files;

  6. The client decides that the content should be changed to match the designs;

  7. The front-end developer (or you) goes back and starts changing content types, fields, views, etc. BACK to where they were before;

  8. And so on, and so on...

Somewhere in this whole mess, theming also has to happen. In larger teams, the designer will often work directly with a front-end developer to iterate designs and incorporate them into the site’s theme. For smaller jobs, or solo gigs, you’re the one doing the lion’s share of the design, theming and content management. With time, you become used to it. A typical theming session for me usually involves tweaking the display of a field in my content type, then tweaking a display setting in one of the Views I created, then going back into CSS and making adjustments to that field’s properties—in infinite combinations.

This is the single most important reason why it’s important to get actual content as soon as you possibly can. The more you can allow the content to inform your designs, the fewer headaches you’ll have in the design and development process. Your team will thank you, your client will love you, and your head will definitely thank you.

Choosing modules

Modules are one of the things that make Drupal terrific; however, they’re also one of the things that makes Drupal frustrating to many people who are just discovering it. Knowing which module to choose, or which one is needed for a specific project, can be a challenge. And sometimes, a module that seems to be exactly what you need will end up causing more trouble than it fixes—either through refusing to play nice with other modules that you’ve installed, or through messy code that causes major cross-browser issues (hello, Facebook Social Plugins).

That said, there are many modules that are incredibly useful when working with Drupal. Some, such as Block Class (drupal.org/project/block_class) and Pathauto/Token (drupal.org/project/pathauto; drupal.org/project/token) are so useful that I install them by default on any new installation. Others, such as View Reference (drupal.org/project/view_reference), I install whenever I need that specific functionality.

So many modules. How do I choose?

There’s no specific science to choosing the right Drupal module for a given project. However, the more sites you build, the more you’ll begin to notice that specific modules become common for a given project. As you experiment, you’ll also get better at weeding out the modules that aren’t terribly good from the ones that are rock solid. Some things to keep in mind when choosing modules for your project:

  • When possible, fewer modules is generally better. Bear in mind that every module you enable on a Drupal site adds code and other things that the site needs to deal with in order to load the site. More things to deal with, the longer it takes for pages to load.

  • Look for modules that are actively maintained. Each module’s project page lists whether it’s actively maintained, how long ago the code was updated, and the date of the last release. In general, it’s best to choose modules that are listed as “Actively Maintained” and have a recommended release date within the last six months. Figure 3-4 shows an example of an actively maintained Drupal module.

  • If all else fails, reach out. Can’t figure out what you’re looking for? Can’t find the right module for your specific functional needs? A good developer can often help you create custom functionality (and is worth every penny you spend). Often, you can find advice and support from the Drupal community just by asking at a community event or online. Searching on Drupal.org for “[list functionality here]” can also help find things you may not have thought to look for. Either way, don’t worry; we’ve all been there.

The next section presents an entirely incomplete and unscientific list of some of my favorite Drupal 7 modules.

The Drupal project page for the References module. Notice that “6 days ago” in the upper right corner? That’s a good thing.
Figure 3-4. The Drupal project page for the References module. Notice that “6 days ago” in the upper right corner? That’s a good thing.

The following modules have a home in almost every Drupal project that I’ve done for the last three or four years. Some of them provide basic, common-sense functionality that’s not available in Drupal core; others make theming or working with content easier.

Pathauto helps you automatically create custom URLs for your site’s pages. By default, Drupal will name every new piece of content node/45 or something similar (the number represents the unique ID of the node). This is not only bad for SEO, but it’s particularly bad for findability as your site grows in size. With Pathauto, Drupal will use the Title of the node as a default URL, making things much cleaner. You can also configure the settings to give specific content types their own prefix; for example, blog pages can have the custom URL blog/[title] as their URL. Pathauto requires the Token module (drupal.org/project/token) to work properly.

Views, in its simplest form, is a database query. It’s one of the most powerful contributed Drupal modules, and presents some of the biggest learning curves, even to people who use it for years. Once you get used to it, however, you can use it to create almost anything on a Drupal site—from a simple list of blog entries to dynamic menus to (with some help from different modules) clickable calendars and funky JQuery widgets. Recent updates to Views with Drupal 7 have made it much easier to get started working with Views; while there’s still a significant learning curve, it’s much easier to cross. As mentioned earlier, Swedish Drupal shop NodeOne did a terrific series of videos on learning Views in Drupal 7. Check out http://nodeone.se/blogg/learn-views-screencast-series-summed-up for a whole lot of Views love.

Once you get into theming Drupal sites, you notice a particular issue that happens. As you may recall from the introduction to DrupalSpeak™, Drupal constructs pages from a combination of Node content, Block content and occasionally Views displays. So let’s say you have a menu in the sidebar of your page, as shown in Figure 3-5.

A simple menu of event categories.
Figure 3-5. A simple menu of event categories.

If you were coding this in HTML, you’d create a <div> that would hold the menu, which is built as a <ul>, give it a class of menu or something similar, and then use CSS to style the menu.

Core Drupal behavior, however, doesn’t make it so easy. Each block has a unique ID, but that ID usually has no relevance to what the block actually is. So, rather than having a block called “menu,” you’re searching for a block with an ID of block-block-14 or something similar (Figure 3-6). So much fun, right?

Inspecting the element to find out how to style our block. What now?
Figure 3-6. Inspecting the element to find out how to style our block. What now?

Block class gives you the simple ability to assign classes to any block on the page, through the Block Configuration page (Figure 3-7).

Adding a class to our block. Now we know what to call it in our CSS.
Figure 3-7. Adding a class to our block. Now we know what to call it in our CSS.

Not only is this useful for, say, establishing a common style for all sidebar menus on a given page, but if you’re using a grid system such as 960.gs, you can assign grid values directly to blocks. This means that, rather than having to do a bunch of fancy tricks in your theme in order to accommodate a layout with blocks of multiple sizes, you can just give one block a class of “grid-4,” another a class of “grid-6,” and let the two float together in one region. We’ll talk more about Grid Systems in the Design and Prototyping guide; in the meantime, check out 960.gs for an overview of the 960 Grid System, and you can also check out drupal.org/project/ninesixty for the NineSixty base theme—or, if you’re into responsive design, check out the Omega theme (drupal.org/project/omega), which has 960.gs built into a lovely responsive grid.

Webform is a module that allows you to create custom forms (say, a contact form or a questionnaire) for your website. While Drupal comes with a contact form module directly in core, its functionality is limited to sending fairly simple e-mails to individual users on the site. Webform gives you not only the opportunity to customize your contact form’s content, but also to customize who receives the various e-mails it generates. You can also use it to create custom surveys, which can be very useful for doing user research.

Many Drupal developers (and even some designers) insist that they never use WYSIWYG editors. I’m not one of them. For one thing, clients expect them. We’re accustomed to using them whenever we have to write something that’s more than a sentence long—and the first time you leave one out of a site, you can guarantee that your client will ask you where it is.

WYSIWYG depends on the Libraries module (drupal.org/project/libraries) in order to work; you’ll also need to download an editor library from the web. The configuration page for the module will give links to different library; the one that I find works best (or, at least, sucks least) is the TinyMCE library.

Mollom is a service created by Dries Buytaert, Drupal’s creator, that helps block and trap spam on your site. To use the module, you have to set up a free account on Mollom.com, register the URL of your website for tracking, and copy your public and private API keys (given to you by the Mollom site when you register the URL) into the Mollom settings page (yoursite.com/admin/config/content/mollom/settings). The Mollom service is free for smaller personal and small business/non-profit sites; larger sites may require signing up for a paid subscription.

Oh-So-Nice to Have Modules

While the modules listed above will prove useful on almost any site you build, the following modules are one that should at least make it onto your “I might need this for something” list.

Field Group gives you the ability to create groups of fields within Drupal. For example, let’s say that you’re creating an address book, and you want to separate the mailing address from e-mail/phone contact information. Using Field Group, you could display both sets of information in different groups, and theme them differently within your site. Field Groups can also be displayed as Vertical Tabs or Horizontal Tabs by configuring the Manage Display settings in your content type; this is very useful for dealing with complex content types that have a lot of fields.

Link helps you create a Drupal field formatted as a link.

Media helps you organize and store media (like audio and video) on a Drupal site. As of this writing, implementation is still a bit buggy, but it’s still a useful module to have, especially if you want to host video or documents on your site.

References gives you the ability to format Drupal fields as references to other content - such as nodes, user profiles, or taxonomy terms. This is useful if you want to show the author of a post, or related content for an article.

The References module, as you saw above, made it possible to reference a specific node or user within a field in your Drupal page—which is useful if you have related information to share after a blog post. But what if you want to show a bunch of related content, with some teaser information and an image? You could use Node reference, and format the display of the field to show the content’s Teaser display rather than just titles; however, doing this causes Drupal to create a bunch of extra code that will slow down your site. Using Views reference, you can create a view that contains only the fields you want to display, formatted the way that you want to show them, and reference that View directly in a custom field.

Normally, to place a block on a page, you’d use the Block configuration screen to place it inside a region, and customize which pages or content types it belonged on. Block Reference, while it doesn’t replace this process, gives you the ability to reference a Drupal Block directly in a field. This is useful:

  • When you want to place a block on only one page;

  • When you want to place a block within the Content region in a particular location (say, within a field group, or underneath a description)

Block Reference doesn’t replace the Block configuration screen for all blocks; menus, for example, still work best when you use the Block configuration screen to place them. But for highly specific blocks that need to show up within a node’s content, this is an incredibly useful module.

Submitagain is a deceptively simple, but incredibly useful, module. What it does is allows you to create a setting when you’re creating a content type—through a simple checkbox on the content type edit form—that will give you an option to “Save & Add Another” when you create a piece of that type of content.

Why is this wonderful? Let’s say you’re doing an online directory of association members for your local trade group. You likely have a list of folks with name, address, and other contact information to enter into the site. Normally, you’d have to choose Add Content > Member (assuming that you’re working with a content type called “Member”) for each time you create a new Member. With this module, you’d be able to add a member, click “Save and Add Another,” enter another member, and so on. This is a major time-saver for clients who are using Drupal to manage a lot of online content.

No, I don’t need this, but ooh, it’s perty! Modules

The following modules are particularly useful for adding a bit of whiz-bang to your sites.

Views Slideshow allows you to create customized JQuery slideshows using Views data. This is useful when you want to create a banner of featured content on a site landing page, for example; or if you want to show a list of featured projects on your home page.

Colorbox is a module that allows you to display images using JQuery overlays.

User Points is a helper module that allows you to set up your site to give users “points” for doing things on your site. This is useful for community sites, where you want to encourage users to engage with the site in some way. The User Points project page lists a number of additional modules that the community has created with the help of the User Points module. If you’re interested in building a community-oriented site, it’s well worth a look.

A completely incomplete listing

As mentioned before, the modules listed above are hardly a complete listing of everything you might need in a Drupal installation. But remember the point: once you know what you need the site to do, it’s that much easier to find a module that can help you do it. Have fun creating!