If you’re just starting off with Drupal, one of the hardest things to figure out is what people are saying when they discuss Drupal terms. What is a node? What do you mean by taxonomy? The following list is a quick and dirty guide to DrupalSpeak, which is my tongue-in-cheek way of describing Drupal’s unique jargon. It includes the most common terms you’ll find people using when they talk about Drupal.
- Drupal core (or core Drupal)
The actual Drupal files that you downloaded from http://drupal.org. “Drupal core” is also used to talk about any functionality that is native to Drupal, as opposed to contributed modules.
- Contrib
Modules or themes that you install after you install Drupal core.
- Module
A plug-in that adds functionality to your site. Out of the box, Drupal provides a strong framework, but the point of the framework is to add functionality to it using modules. The website at http://drupal.org/project/modules has a list of all the modules that have been contributed by the Drupal community, sorted by most popular.
- Theme
The templates that control the look and feel of a Drupal site. Drupal core comes with several themes that are very useful for site administration and prototyping; however, custom themes should always reside in your sites/all/themes folder and not in the core themes folder, located at themes among your core Drupal files.
- Custom
Modules or themes that you create from scratch for a particular site or use case and that reside outside of contrib modules. Modules can be created from scratch, or they can be created using Features (a module that you’ll learn about in Chapter 18).
- sites/all
A folder within your Drupal installation that contains all the files, including any contrib modules or themes, which are being used to customize your site.
Warning
Any module, theme, or other customization that you create for your site should always reside in sites/all, in a folder labeled modules or themes, depending on the nature of the customization. Always.
- Hacking core
Refers to the act of making customizations directly to Drupal core files, modules, and so on, instead of putting your customizations into sites/all. This is a bad idea for several key reasons, the most important of which is that every time you upgrade Drupal’s core files (which could be several times over the lifetime of a site), any customizations you’ve made to core Drupal files, along with any modules or themes you’ve stored in the core modules or themes folder, will be replaced with the new core files.
- Node
A single piece of content. This could be a news item, event listing, simple page, blog entry—you name it. Nodes can also have custom fields, which are useful for all sorts of things. Think of a node in the same way you would a page on a website or a record in an address book.
- Content type
The type of node you’re creating. One of Drupal’s best features is its support of multiple content types, each of which can be sorted out and displayed by any number of criteria. For example, in a basic corporate site you might have the following content types: blog post, basic page, event, news item, and testimonial. Each of these content types can be sorted out and organized, using the Views module, to create the Blog section, Events page, News Room, and so on. Best of all, your client can easily update the Events page simply by adding a new event. Drupal will do all the work of sorting out the Events page and archiving old events.
- View
An organized list of individual pieces of content that you create within the site, using the Views module. This allows you to display content related to taxonomy or content type, such as a “view” of blog posts versus a “view” of events.
- Field
Elements of data that can be attached to a node or other Drupal entities. Fields are one of the best things about creating content in Drupal. Using fields, you can attach images or files to content, create extra descriptors (such as a date for an event or a subheading for an article), or even reference other nodes. While in previous versions of Drupal you needed to download a contrib module (Content Construction Kit or CCK) to add extra fields to a content type, Drupal core (as of Drupal 7) allows for a number of field formats, but certain formats—such as images, file uploads, or video—require you to install contrib modules. Chapter 13 provides a brief list of contrib modules that can extend the power and usefulness of fields.
- Block
A small piece of reusable content such as a sidebar menu, advertising banner, or callout box. Blocks can be created by a view or other contributed modules, or they can be created by hand in Drupal’s Blocks administration menu. The beauty of blocks is the flexibility of display—you can set up blocks to display based on any criteria that you set. This is especially helpful on home pages, for example, or for displaying a menu that’s only relevant to a specific section of a website.
- Taxonomy
Content categories. At its most basic level, you can think of taxonomy as tags for content (such as blog entries). The true power of taxonomy, however, lies in organizing large quantities of content by terms an audience might search for. For example, a recipe site can use taxonomy to organize recipes by several criteria—type of recipe (dessert, dinner, etc.), ingredients (as tags), and custom indicators (vegetarian, vegan, gluten-free, low-carb, etc.). In building the site, you could then use Views to allow users to search by or filter recipes by any one (or several) of these criteria.
- Users, roles, and permissions
People or organizations that have visited, or registered, on your site. The key to working with users lies in roles; Drupal allows you to create unique roles for anything that might need to happen on your site, and set permissions for each role depending on what that role might need to do. For example, if you’re creating a magazine-type site with multiple authors, you might want to create a role called “author” that gives the user permission to access, create, and edit his or her own content, but nobody else’s. You might also create a role called “editor” that gives the user access to edit, modify, and publish or unpublish any author’s content.
- Base theme
A set of theme files, usually downloaded from Drupal.org and stored in sites/all/themes, which sets the structure for your Drupal theme. Generally, a base theme should only set up defaults, such as page structure, grids, and some very basic typography; customizations beyond those defaults should be set up in a child theme, stored in sites/all/themes/<client_name>. The purpose of the base theme is to have a consistent set of files and standards that you can use for every project; the child theme holds all the project-specific CSS, jQuery, and so on.
- Child theme
A set of theme files, stored separately in sites/all/<client_name> and built off of the base theme chosen for your project, which hold all project-specific customizations for your site. A discussion of base themes and child themes is available in Chapter 16.
- Themers
The lovely folks in the Drupal community (which may include you, dear reader) who apply design elements to Drupal theme templates. This could include simple CSS and HTML, but often also includes more complex things such as PHP, jQuery, AJAX, and other frontend development tools. It also involves choosing the right base theme for your project and building a child theme that will contain customizations, and may involve creating specific functions in template.php for your theme. Advanced themers may also create their own base themes or build a custom theme for every project.
- Template files (*.tpl.php)
Individual PHP files that Drupal uses for template generation. Most Drupal themes will have, at the very least, a tpl.php file for blocks, nodes, and pages. Once you get the hang of working with tpl.php files, you can create custom templates for anything from a specific piece of content or specific content types to the output of a specific view. You can also adjust the major .tpl files for your theme to create lovelier, more semantic code (e.g., getting rid of extraneous
<div class="container-inner">tags).- Template.php
The PHP file, located in every theme’s project folder, that contains all theme hooks, functions, and preprocessors used by your site’s theme. In some base themes, you may need to create override functions in your child theme’s template.php file to set up key variables, such as grid sizes or menu items.
- Theme hooks/preprocessors
Bits of PHP code that you can use to override specific settings in your template files, such as how code is rendered, how menus are laid out, and other customizations. Some Drupal themers find using theme hooks and preprocessors much more efficient for cleaning up Drupal code, particularly when they want to customize code for a number of different content types, or for specific taxonomy categories. Rather than creating a custom tpl.php file for each different category or content type, you can create a function in template.php that sets up the code parameters depending on which content type you’re rendering. For the most part, we won’t talk about theme hooks in this book; however, they’re quite useful to know as you move forward in Drupal. Konstantin Kafer and Emma Jane Hogbin’s Front End Drupal (Prentice Hall) is a great resource for anything you’d want to know about theme hooks, although the current edition (as of this writing) is still focused on Drupal 6. Check out http://www.frontenddrupal.com/ for more information on that book, and for a bunch of interesting tutorials on advanced Drupal theming. The chapter on theming written by Jacine Luisi for The Definitive Guide to Drupal 7 (Apress) also contains a lot of great information about theme functions. Full disclosure: I’m one of the authors of that book.
When discussing Drupal with clients, the biggest mistake you can make is starting to talk to them about blocks and nodes and views, and other DrupalSpeak. While some clients actually do understand these concepts, in my experience the majority of them don’t, and frankly, it’s not their job to know it. I’ve had this argument with many a well-meaning Drupaller who insists that “educating” the client about Drupal terminology is actually useful, but I see the same result every time someone tries: start speaking to a client about taxonomy and views, and watch his or her eyes glaze over.
My favorite way to talk to clients about Drupal is to start with the concept of a news page or blog home page (see Figure 1-1). Each individual post is its own piece of content, with its own fields, categories, and tags, and Drupal’s job is to organize that content on the page for you. The client’s job (or that of the client’s copywriter) is to give you those individual pieces of content, with all their various fields, categories, and tags, so that you can put them into the system and set up rules for how they’re organized.
Figure 1-1. A sample blog page (like this one, from a site I created for New Leaf Legal) is a great way to start explaining the concept of nodes, taxonomy, views, and blocks to your clients. Just don’t call them that.
As noted earlier, any customizations to your site (modules, themes, etc.) should reside in your sites/all or sites/default folder. There are many reasons for this, but the most important one is for ease of upgrading your site. When upgrading Drupal core, you’re essentially replacing all the files in your Drupal installation with the newest version of the files, and updating the site’s database to reflect the new files. By keeping all your customizations in the sites folder, you lessen the risk that all your files will be replaced once you update. Another handy facet of using the sites folder to hold all your customizations is ease of editing; by keeping everything in one place, there’s less to hunt through when you’re looking to change a file.
By default, you should keep all your customizations in sites/all. If you’re dealing with a single site, it’s just as easy to keep things in sites/default, but if you ever get into creating multisite installations (which is way beyond the scope of this book), being in the habit of keeping everything in sites/all will serve you well. You also want to organize your code according to what it does; for example, themes should go into sites/all/themes, modules in sites/all/modules, and so forth. This is because Drupal actually looks for themes in a folder called “themes,” modules in a folder called “modules,” and so on. If you don’t have things stored in the appropriate folder, everything goes to heck.
A good project plan for Drupal starts with the client. How much do they know about Drupal? Did they specifically request it, or was it something you suggested to them as you heard their list of requirements? This is surprisingly important information. For clients who are new to Drupal or just learning about it, you need to do a bit more handholding in order to get them on board with the process. Designing for content management systems is very different from designing for Flash or with straight HTML; it’s remarkably common that designers new to Drupal realize too late that the brilliant layout they designed won’t go into Drupal without a serious fight.
I typically divide Drupal projects into six distinct phases:
- Phase 1: Discovery
During discovery, we learn as much as we can about the client, the project, and the project’s objectives. This is also where we start to create a map of the functionality we need to implement, any resources we’ll need to bring in, and so on.
- Phase 2: User experience (UX) and architecture
This is where we take a deep dive into the lives, personalities, and other factors that define the humans who will need to deal with this project on a daily basis—both the end users who visit the site, and the clients who will end up managing the content once the project is finished. Deliverables for this phase may include wireframes, user flows, personas, and site maps. I may hold workshops with the client to brainstorm issues of information architecture and content strategy, or conduct rounds of user interviews with individuals who fit the client’s target user base.
- Phase 3: Prototyping
During prototyping, which is usually done just prior to starting the functional implementation phase, we start testing some of the hypotheses and user flows that came out of the user experience phase. For simple sites, the prototyping and functional implementation phases go together; for more complex user flows, or for projects in which you’re wrangling a ton of content, the prototyping phase is essential to making sure something you want to create will work the way you want it to in Drupal. The key distinction between the prototyping phase and the functional implementation phase is which components of the site plan you’re working on; while the functional implementation phase focuses on how the entire site will be built, the prototyping phase often focuses on one or two key pieces of the user’s journey through the site—for example, a shopping cart, or an area that requires a treatment unique from the rest of the site.
- Phase 4: Functional implementation
During this phase, the focus is on creating the functionality we described in the user experience phase, and ironing out any areas where the scope of the site may need to be adjusted due to budget constraints or the results of user testing. For smaller sites, there’s a good chance that you’ll be doing this work on your own, and many solo site builders can create great things with little outside help. However, if you’re not currently on a Drupal team, be advised: get to know some developers, and pay them to do things for you when you’re in a rut with something. A good developer is a Drupal designer’s best friend.
- Phase 5: Visual design and theming
Notice, please, that visual design—here defined as the colors, fonts, images, and other branding elements that define the look and feel of a given site—comes fifth in this list. There are many reasons for this, most of which you’ll find in this book. The most important reason, however, is that bringing visual design into the picture too early in a Drupal project—or in any significant project, for that matter—is a recipe for disaster. Part of your job as a Drupal designer is to keep clients focused on what’s important—and what’s important is how this site will serve their business objectives and their brand. While visual design is an important component of the site’s value, it’s just one piece of a much larger whole. Worse yet, it’s also the piece that clients will most often fixate on, to the detriment of more important issues, such as whether a user actually needs 50 pages of content in order to make a purchasing decision. The best way to explain this to clients is that the discovery and user experience phases—which are still part of the design process, by the way—set up the experience you’re creating for the user, and establish content priorities. The visual design and theming phase makes sure the experience you design in those early phases meshes with the client’s brand and messaging.
- Phase 6: Testing and launch
Always test before launch. And after launch. And again after the client has had a chance to muck around with the site. There are a few steps to the launch phase. First, you’re moving your code from a development server to a staging server (the server that holds your site before the world gets to see it), and making sure parts of it didn’t break in transit. Once everything is good, you’ll move things from staging to production (where the site will ultimately live), and test again to make sure things didn’t get lost in transit. For this process, it’s incredibly useful to have developers on your team.
For most projects, I also like to include a seventh phase that helps consolidate everything we’ve learned from working on the project:
- Phase 7: Wrap-up meeting/documentation
In the wrap-up meeting, you sit down with the client and discuss what worked well in the project, and what could have gone better. It’s also a useful time to document the knowledge you gained through the project, either in an internal wiki for your team, or on Drupal.org, where it can benefit the Drupal community.
Figure 1-2 provides a quick visual breakdown of how a typical Drupal project works.
Another important issue to consider when talking to project stakeholders, and creating project plans, is how you categorize and prioritize your workflow. Since much of what you’re doing in Drupal is managing content and/or creating specific functionality, it’s vital to think, and speak, in terms of specific chunks of content or functionality that you have to create.
For example, Figure 1-3 shows the start of a functional matrix for Urban Homesteaders Unite (UHU), a project currently in process.
Figure 1-3. Functional matrix for Urban Homesteaders Unite. Note the specificity of tasks: create a single taxonomy vocabulary or content type, rather than “all” content types.
By setting up your work in chunks of content instead of discrete task types, you eliminate the confusion that comes with making a statement such as “On the week of the 14th, we’re going to be setting up content types.” While this can be perfectly fine if you only have a couple of content types to put together, any site that’s larger than a few pages is likely to have enough complexity that each section of content or functionality will require its own content types, views, wireframes, and even custom page templates or modules—all of which will evolve during the course of the project.
By setting up the project plan with a list of very specific activities that will be done according to the tasks that must be accomplished on the site, you set a reasonable expectation with your client on what they’ll be able to see at the end of a given period of time. Breaking down the tasks in order of importance also helps the development team get an idea of what the key user priorities are.
Most importantly, setting up project plans by user tasks gives you the freedom to do whatever needs to be done to finish that specific task without having to waste time loading a bunch of milestones into Basecamp (or the project management tool of your choice) that the client doesn’t really need to see.
Now that we have an idea of how a Drupal project will play out, it’s time to go a bit deeper into what each phase looks like. In Part I we focus on the discovery and UX phases, which help get everyone in the team (both you and the client) on the same page.
Get Drupal for Designers now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
