Our Media is a Vancouver-based independent news website. The content is mainly produced by volunteers, while a small staff of paid editors manages the website. They make sure the volunteers know where the next press conference is taking place, and actually review, edit, and publish the content that the volunteer reporters post.

In recent months, the site has grown more popular. More and more volunteers have signed up to write articles and make video reports—so many that the staff can hardly keep up with all the work. They’ve decided they need to delegate some of the editorial work in order to keep things feasible. This means that their site’s editorial process needs to be changed.

After some meetings with a group of volunteers, they have come up with a new editorial process, which would be based on the editorial groups that already work together for Our Media. The groups are mostly topic centered: there is a group that works on international news, a group that covers politics, another that reports on cultural events, and so on. The team figures that if they could distribute the editorial work among those groups, rather than managing all the content centrally themselves, their workload would decrease significantly. Every group would be responsible for the content within its own section.

For this organizational change to be possible, however, the website needs some work. It needs to be set up in such a way that certain volunteer editors are only able to access content within certain categories. The editors also need an easy way to find the content they are responsible for. They should not have to look around in Drupal’s administrative interface to find the content that they need: everything should be nicely grouped together in one place.

In the editorial interface, the volunteer editors should be able to easily find new content that reporters sent in for review. The editors should be able to review their content, send it back to the reporter if it needs work, and communicate with the reporters about changes they propose. If the editors make a change to the content themselves, a new version of the content should be saved, so the reporter’s original is preserved. When dealing with a hot news story, editors should be able to publish a temporary, quick version of the article on the site, while editing and refining a final version behind the scenes.

While this chapter focuses primarily on the Workbench module suite, we need to do some basic setup of our Drupal site in order to benefit from Workbench’s full potential. One of those things we need to do beforehand is set up categories to organize our content, using the Taxonomy module.

If you’re new to Drupal, you’ve probably wondered what taxonomy is—the word pops up all over the place, and it can sound a bit mysterious. Don’t worry, it’s just a technical term for a way of organizing and classifying things, like content on a website. If you’ve sorted your family photo album, filed your email in folders, or argued with a friend about whether a band is punk or ska, you’ve already worked with taxonomies!

If a site has a lot of content, editors need a way to group it into categories. By doing so, they make it possible for users to easily navigate the website and find the content they’re looking for. Additionally, assigning content to categories, whether by using a predefined set of sections or a free-for-all tagging system, opens up all sorts of interesting possibilities. For instance, site builders can expose content with similar tags on article pages. Or they can turn the category pages into rich landing pages, pulling in all kinds of different content that has the same categories assigned to it.

Vocabularies and Terms

Creating a taxonomy for your site starts when you identify what kinds of content you’ll have, and how it can be described. News articles, for example, might be classified by their subject matter or by the geographical area they cover. In Drupal, these groups of categories are called vocabularies (like Section). Each vocabulary contains specific terms (like “International affairs,” “National news,” or “Culture”) that can be used to describe content. Whenever you post an article, a photograph, or a blog entry, you can select the terms that match it.

Drupal supports three kinds of vocabularies: simple lists of terms, organized hierarchies of terms, and “free tagging” vocabularies that allow you to define new terms as you post new content. Drupal’s “Term reference” field type provides widgets that allow you to expose a vocabulary’s terms as checkboxes, radio buttons, select lists, or autocomplete fields. Each is useful in different situations. Figure 7-2 shows an example of how each type of vocabulary might be used on a hypothetical news article content type.

Figure 7-2. Examples of taxonomy types and widgets

Like other entities in Drupal (nodes, users, files), taxonomy terms can be extended with fields. The default fields for a term are Name and Description, but you can add whatever field you want. For example, it may be handy to provide a “Term image” field in order to add a picture for every term, which you can then show on the term overview page. And because term reference fields can be placed on taxonomy term entities, you can even tag your tags. Whoa.

The taxonomy system is incredibly powerful, and is one of Drupal’s greatest assets as a content management system. In addition to the features provided out of the box, several contributed modules also make use of taxonomy in interesting ways, the Taxonomy Menu module, which turns a vocabulary into a Drupal menu that can be placed in Primary or Secondary links.

Taxonomy Term Links

After you submit a piece of content, any terms it has attached will appear as links on the node page, as displayed in Figure 7-3. Each of these links displays a page listing all content to which that term has been applied, along with an RSS feed that visitors can subscribe to in order to receive notifications whenever new content with that term attached is posted.

Figure 7-3. Taxonomy terms are listed as links on the node page

List or Term Reference?

The Taxonomy module’s “Term reference” field and the “List (text)” field both allow you to create select lists on the form for creating content. Here are a few guidelines to help you choose one or the other:

• The primary purpose of Taxonomy is to create categories, so if you’re putting things into categories, you should generally use the Taxonomy module. If you ever make a list field called Category, think twice. The Taxonomy module was made for that exact purpose, and many existing modules provide integration directly with the Taxonomy module.

• Taxonomy provides hierarchies of categorization that are very easy to order and organize. If your selections need to be put into a tree, Taxonomy is a good choice.

• A general rule of thumb is that if you can remove the field and the content type still makes sense, use Taxonomy. An article filed under a Technology section is still an article if you remove the section association, so Taxonomy is a good fit. If the field is part of a piece of content, such as an album’s copyright year, then a List field is generally a better choice.

The Taxonomy module is included in core and is enabled by default when you install Drupal, along with a Tags vocabulary, which you can use to allow users to freely tag their content. Let’s use Drupal core’s Taxonomy module to set up a “News section” vocabulary with predefined terms, in order to organize the articles that are posted on our news site:

On the term creation page, there are some other options available as well, which we won’t configure right now:

To use the terms we’ve just created with nodes, we need to add a term reference field to the content type we want to categorize. In the administrative toolbar, click Structure→“Content types” (admin/structure/types). We’ll add a term field to the Article content type.

Figure 7-6. Adding a term reference field to the Article content type

Nice! You’ve learned how to organize the content on your Drupal site, using core’s Taxonomy module. We’re almost ready to build our distributed workflow with Workbench, but first we’ll do a little bit more preparation work.

In Creating a Basic Page, you learned about Drupal paths and how to use clean URLs. One reason to use clean URLs is so that they don’t look so ugly. (To review, clean URLs remove the ?q= from the URL.) That helps, but still leaves the URLs lacking a bit. Having a URL with node/123 in it doesn’t really tell either humans or search engines much about the page itself. Isn’t it much better to have a URL with something like article/the-article-title in it? That will be much more memorable, and the addition of pertinent keywords in the URL makes for better search engine optimization. So, even without clean URLs, you can still benefit from good pathnames.

Path Aliases

We’ll quickly review the core Path module that we mentioned in Chapter 2. When enabled, it will add a new vertical tab to the node creation/editing form called “URL path settings,” as shown in Figure 7-7. When you click that vertical tab, you will have a field in which to enter an alternative name for that node’s path (called a URL/path alias). The name that you enter here will be used in place of the Drupal path, the part of the URL that comes after http:// example.com/ (or http://example.com/?q= if you don’t have clean URLs enabled).

Figure 7-7. Configuring a URL alias for a node

This field is a huge help, but it can be somewhat tedious to enter all of those names by hand if you are creating a lot of content. Also, if you have many users creating content, you need to make sure that they all understand this and use consistent naming throughout the site, which can be an administrative headache.

As often occurs in Drupal, contributed projects provide us with a module that deals with this issue. Enter the Pathauto module. As its name implies, it creates automatic path aliases for nodes, taxonomy, and user paths. Pathauto is dependent upon the core Path module and another module called Token, discussed in the sidebar below.

What Is a Token?

Tokens are placeholders that get swapped out dynamically for real values later on. For example, [yyyy] represents a four-digit year, and [author-name] represents the username of a node author. These are very similar to what we saw in Views when switching the Amazon link destination in Rewriting Views Field Output.

Drupal core exposes a number of default tokens, but by default there is no user interface to browse or input them. So unless you’re extremely PHP-savvy, tokens can be difficult to use out of the box. Additionally, there are some tokens that Drupal core does not provide, such as field-related tokens. Enter the Token module, which provides a UI to any token-enabled text field in Drupal to get at the central repository of token placeholders, as well as a bundle of extra tokens that haven’t yet made their way into Drupal core.

Modules that have data (like the core Node module, which knows the date a node was created), can let the token system know they have something to share. You can think of these as “suppliers.” Modules that want to use that data, like Pathauto, can tap into the list of what is available. These are more like “consumers.” Drupal’s token system acts like a storefront that can sell various things that the suppliers bring in to the customers who want to consume them.

Contributed modules can become “suppliers” as well by providing new placeholders that represent data that they know about. They just need to speak Token’s language and say “Hey, I have this xyz bit of data in the database, and you can tell others about it by telling them to use the [xyz] placeholder.”

Tokens in Drupal 7 are also chainable; for example, the “node” token exposes an “author” element, which gets you the user properties for the author of the node. This allows you to use tokens such as [node:author:email]. Handy!

Pathauto Patterns

Pathauto uses a combination of plain text and tokens to set up URL naming patterns to follow. For instance, you can set up a pattern for naming the path of all new article pages to be [node:content-type]/[node:title] so that you automatically get something like article/my-first-article, as shown in Figure 7-8.

Figure 7-8. Pathauto’s version of the path settings on a node edit form with a path automatically prefilled

The bits of text in square brackets are placeholders for the Token module mentioned earlier. You can use different patterns for each unique content type or vocabulary if you choose. For example, basic pages could use a pattern of [node:title], since they’re generally things like About Us and there’s no need to specify “page/” in front of it. Pathauto also has configurable default patterns that will be applied if you don’t make specific choices. You can decide things like how long your alias is allowed to be, what kind of separator you would like to use in the place of spaces or punctuation, and which common, short words you want to remove (e.g., a, and, in, etc.) from the path. In addition to making these automatic aliases upon creation of new content, Pathauto can also update all of your existing content so that your entire site uses the same pattern, even if that content was created prior to your turning on the Pathauto module.

One important thing to consider when using Pathauto is how you want to manage changing your aliases in case of a typo or similar problem. Because the alias is created based on information that Pathauto is getting about that content, if you update the content you can change your alias. You can decide what you want to do when you make updates. You can:

• Do nothing. Leave the old alias intact.

• Create a new alias. Leave the existing alias functioning.

• Create a new alias. Delete the old alias. (This is the default.)

Different sites may have different reasons for choosing which option they want to use. The default is to make a new one and delete the old so that your aliases always match your content. This option can be problematic in that it can cause a condition called link rot. If you have a certain URL on your site, such as http://example.com/about, other sites on the Web may create links pointing to that URL. If you change that URL to http:// example.com/about-us and delete the old one, all of those outside links will stop working. That’s link rot, and it’s generally frowned upon since it’s bad for the Internet when URLs break.

The second option, making a new alias and keeping the old one, may sound ideal, because you can then access the content from either path and the problem of link rot is eliminated. But, while this option addresses the issue of link rot, its disadvantage is that some search engines will penalize you for having many paths that point to the same page, because they think you may be trying to game the search results. One way to get around this issue is to use the Redirect module with Pathauto, which can be configured to automatically create redirects for changed URLs so that content coming in via duplicate paths is sent instead to the one canonical path in the system.

Look over the Pathauto settings and play around with them while your site is under development to determine the best fit for your site’s needs. Once the site has been launched and people are using it, avoid making any major changes to your Pathauto settings, as users may come to depend on the URLs behaving in a particular way.

To get those handy human-readable URLs on our site, we are going to use the Pathauto module. As you saw in the previous section, this relies on the Token module as well as the core Path module. The Pathauto settings are divided over two pages: one page to set up the actual replacement patterns, and another one to configure Pathauto’s general settings. These configuration pages can seem a bit intimidating at first. Luckily, most of the defaults are what most sites will want to use anyway, so that makes our job with configuration a lot simpler than it may first appear.

Figure 7-9. Configuring Pathauto’s URL patterns

These settings will now take care of the paths of all future articles and taxonomy terms that we create. However, we already created a few articles in the previous section. How do you account for content that’s already created? To do this, we’ll have Pathauto bulk-update the existing URLs, as shown in Figure 7-10:

Figure 7-10. Updating URL aliases using Pathauto’s bulk-update function

Once Pathauto’s bulk update has run, you’ll see that all our existing taxonomy terms (and articles, if you created some already) have a pretty human-readable URL like news/culture, and our article URLs look something like article/occupy-wall-street-facts.

Now that we have created a way to categorize content on our site with the Taxonomy module, and added automatic aliases with Pathauto, we can move on to building the editorial system needed for the Our Media site. As noted in the use case, the Our Media staff members have two main needs:

This use case can seem complex at first. We need to provide some form of access control, so that editors who are responsible for the “culture” section on the site can only see draft articles in that particular section. On top of that, we need an editorial workflow that integrates with that access control feature. Lucky for us, Workbench, a contributed module (or rather, a suite of modules), provides exactly what we need.

Workbench was developed to solve a number of important needs of websites that deal with a lot of content:

For administrators, Workbench provides a one-stop solution to improve the content creation and reviewing process on a Drupal site. Its goal is to combine several often-requested content management features into one module suite, so that administrators can easily implement complex editorial workflows by simply installing Workbench.

For users, Workbench provides a consistent and unified way to deal with content. Users (like our editors) who primarily work with content only need to find their way to the Workbench page, and can take it from there. They don’t need to learn all the ins and outs of Drupal, but can focus on what they like doing: working with content.

The Workbench suite was developed in a modular way, making it possible for users to only install the modules that are needed for a certain site. If you don’t need the section-based access control, but only the content moderation states, simply leave Workbench Access disabled.

Apart from the aforementioned Workbench modules, there is also Workbench Files, which provides an interface to efficiently manage files that are uploaded, and Workbench Media, which integrates with the Media module. Both Workbench Files and Workbench Media extend the initial Workbench interface, meaning that editors can access everything from the same place in the Drupal administrative interface.

My Workbench

When Workbench is installed on a Drupal site, it provides an overview page, called My Workbench. Editors will use this page, which groups all of Workbench’s editorial functionality together, to find content that was published on the site, review it, and manage it. The My Workbench page is easily accessed through the administrative toolbar, as shown in Figure 7-11.

Figure 7-11. My Workbench is always accessible through the administrative toolbar

Without any of Workbench’s add-ons, the My Workbench page, pictured in Figure 7-12, contains the following:

My profile

The My Workbench page shows a picture of the user who is currently logged in, along with a link to the user’s profile, to provide easy access to the user’s profile page.

My edits

A convenient overview of the content that the currently logged-in user has worked on, ordered according to the time the content was last updated. By default, this list displays five items. To see all content items that he has edited, the user can click “View all.”

All recent content

A listing of all the content on the site, ordered according to the time the content was last updated. This list will contain up to 25 items. Just like with the “My edits” list, users can click “View all” to see more content.

The My Workbench page also displays a tab that links to the “Create content” page, so users can easily navigate to that page, right from the main Workbench page.

Figure 7-12. My Workbench serves as the central point for content management in Drupal

Note

The content listings you see on the My Workbench page are created with the Views module, which means you can change them as you see fit. For example, you might want to display more than five items under My Edits, or remove the username under the “My profile” picture. Using what we learned in Chapter 3, making simple and more complex changes to the default Workbench page is possible.

Since implementing Workbench can seem complex if you’re doing it for the first time, we’ll break it down into smaller steps. In this section, we’ll focus on configuring the basic Workbench environment. Once that’s done, we’ll look at setting up more advanced features like access control and editorial workflows.

After you’ve configured the Workbench permissions, click My Workbench (admin/workbench) in the administrative toolbar: this will be the main content management page from now on.

Since we haven’t been creating much content on our site, the My Workbench page is rather empty. This can make it hard to understand what’s going on and to grasp the module’s possibilities. This is a situation that you’ll encounter often when developing a site: at a certain point, you need content to test a certain feature, or to verify what a certain section on your site will look like.

The Devel Generate module, which comes with the Devel module (http://www.drupal.org/project/devel) allows us to quickly generate sample content, users, taxonomy vocabularies/terms, and menu items, so testing functionality on our new site becomes a lot easier, since it will more closely resemble its actual functioning.

Once the sample content has been generated, return to the My Workbench page. Despite the content being far from realistic, the Workbench will look much more like what you would expect to see on a working site. This makes it easier for us to further explore Workbench features, which we’ll do in the following sections.

In the previous sections of this chapter, we’ve created a taxonomy vocabulary and terms to organize the content on our site, and we’ve configured the main Workbench module to provide a workspace for our content editors. In this section, we’ll combine both modules to achieve another of this chapter’s goals: to allow content management to be delegated according to existing editorial groups.

As we’ve seen in the previous section, where we introduced Workbench, it is possible to extend Workbench using other modules that belong to the suite. One of those modules is Workbench Access.

Using Hierarchies to Define Access Control

Workbench Access allows an administrator to create access control mechanisms based on existing hierarchies on the site. Such hierarchies can be a menu or a taxonomy vocabulary. With Workbench Access, you can use those hierarchies to control which user has editorial access to certain content. For example, Workbench Access makes it possible to grant users of one role editorial access to content tagged with all terms of a certain vocabulary, while users of another role have access only to content tagged with one specific term within the same vocabulary.

In addition to per-role access, you can also grant individual users access to a term or a vocabulary. This makes it easy to allow different users to work on their own specific part of the site’s content, without getting in each other’s way. In Figure 7-15, which displays Workbench Access’s main configuration page, the “News section” vocabulary is used to control editorial access to articles.

Workbench Access also supports Drupal’s menu system as an access scheme, meaning you can grant editorial access to content based on a content item’s place in the site’s menu structure.

While Workbench Access supports the Taxonomy module and the menu system out of the box, module developers can expose their own access schemes to Workbench Access, so administrators can use them to build access control systems for their editors. The module is designed to be extensible.

Figure 7-15. Configuring Workbench Access settings

Note

It’s important to note here that Workbench Access only works on an editorial level: it does not interfere with permissions to view content on a site. Other modules, such as Taxonomy Access and Content Access are examples of node access modules, and can provide fine-grained control over who can see content on the site, and in what contexts. See a full list of all available Content Access control modules on Drupal.org at http://drupal.org/project/modules?filters=tid%3A13434.

Workbench Access sections

When you use a vocabulary with Workbench Access to control access to content, terms in that vocabulary become known as Workbench Access sections. Workbench Access allows you to configure several options related to Workbench Access sections:

Workbench Access message label

How to refer to Workbench Access sections on node forms. In this case, they are referred to as an “Editorial section,” since that makes sense for a news site.

Automated section assignment

Whether to automatically use all terms within the used vocabulary as Workbench Access sections (when using taxonomy as the access scheme). If you disable this, you’ll have to manually enable individual terms as Workbench Access sections.

Allow multiple section assignments

Whether to allow a piece of content to belong to multiple Workbench Access sections.

Assigning Editorial Access to Workbench Access Sections

Once you’ve set up access control with Workbench Access, you still need to determine which users have editorial access to which content. Workbench Access’s configuration is very fine grained: you can enable individual Workbench Access sections, and assign editorial access to complete user roles or only to certain users. In Figure 7-16, users with the role “national editor” have editorial access to content that has the term “National news” attached.

Figure 7-16. Configuring Workbench Access role settings

You assign content to a Workbench section on the node form. Once you’ve configured Workbench Access, users will be able to put content into sections using a select list, as shown in Figure 7-17. Once the content belongs to a certain section, users with editorial access to that section will be able to edit it.

Figure 7-17. Assigning a node to a Workbench section on the node’s edit page

Also note that Workbench Access extends the My Workbench page by adding a tab called My Sections, as shown in Figure 7-18. By clicking on the tab, an editor can verify which Workbench Access sections she can access.

Figure 7-18. The My Sections tab shows the sections a user can access

Let’s extend our Workbench implementation with one of the more advanced features our client has asked for. We’ll build upon the structure we’ve created with the Taxonomy module (the “News sections” vocabulary), and use that to grant users within specific roles access to content tagged with one of the “News sections” terms. We’ll start with a little preparation work: creating two new user roles and adding a user for each role.

As you’ve probably guessed by now, we’ll create an access control mechanism that grants users with the “national editor” role editorial access to content tagged with the term “national news.” Users that have the role “cultural editor” will eventually get editorial access to content that has the term “culture” attached. Before that can happen, we need to enable and configure Workbench Access. After this configuration, the taxonomy terms we created earlier will become Workbench Access sections, which will be used to enforce access control on our site’s content.

Setting Up Access Control with Workbench Access

In the administrative toolbar, click Modules (admin/modules) and enable the following modules:

• Workbench

  • Workbench Access

After enabling Workbench Access, we’ll go ahead and configure it.

Note

If you were to go to the My Workbench page (admin/workbench) as the “national editor” user, you’d notice that it doesn’t list any content yet. That’s because Workbench Access is enabled, but hasn’t been configured. The My Workbench page will remain empty until content has been assigned to Workbench Access sections. Administrative users or users with the “editor” role, however, can still edit all content on the site by going to Drupal’s content configuration page (admin/content).

1. Click the “configure Workbench Access settings” link in the message, or navigate to Configuration→Workbench→Workbench Access, then click the Settings tab (admin/config/workbench/access/settings).

2. When you land on the Workbench Access settings page, you’ll see that the default configuration for Workbench Access is to use Taxonomy as its access scheme. For the Our Media site, we’ll use our newly created “News sections” vocabulary to control editorial access to content. On the Workbench Access settings page, enter the settings in Table 7-9 and click “Save configuration.”

   Table 7-9. Workbench Access settings

   Setting	Value
   Active access scheme	Taxonomy (default)
   Taxonomy scheme settings	News sections
   Content types enabled	Article
   Workbench Access message label	Editorial section
   Automated section assignment	Checked (default)
   Allow multiple section assignments	Unchecked (default)

We have the most basic configuration for Workbench Access set up: taxonomy terms within our “News section” vocabulary will be used as Workbench Access sections to determine access control. Now it’s time to decide who gets access to which terms. Remember the new roles we just created? We’ll use those to grant users access to content that’s tagged with terms in the “News sections” vocabulary.

Note

If you want to prevent some of the vocabulary’s terms from becoming Workbench Access sections (so they’re not used for access control), you should leave “Automated section assignment” unchecked. If automated section assignment is disabled, you can click the Sections tab (admin/config/workbench/access/sections), and leave the terms you don’t want to use for content access disabled.

1. First, we need to allow users of our new roles to be assigned to Workbench Access sections. Go to the Permissions page by clicking People→Permissions (admin/people/permissions). Configure the permissions as indicated in Table 7-10:

   Administer Workbench Access settings

   Allows users to configure Workbench Access. This permission is intended for users who administer the site.

   Assign users to Workbench Access sections

   Users with this permission can assign users and roles to Workbench Access sections. Meant for “super editors,” like the Our Media staff members.

   Allow all members of this role to be assigned to Workbench Access sections

   Users of these roles will be able to edit content in certain Workbench Access sections (whichever sections they are assigned to).

   Batch update section assignments for content

   Allows users to assign content to Workbench Access, using the batch-update options on Drupal’s content management page (admin/content). We’ll explain how this works later in this section. A user needs to be assigned to a Workbench Access section to batch-assign content to a section.

   View Workbench Access information

   Allows users to see messages concerning content assignment to Workbench Access sections.

   View taxonomy term pages for Workbench Access vocabulary

   Workbench Access can create its own vocabularies for testing purposes. This permission has nothing to do with the normal vocabularies and terms on a site, and we won’t be using it for editors on our site.

   Table 7-10. Workbench Access permissions for the “national editor” and “culture editor” user roles

   Permission	anonymous user	authenticated user	culture editor	national editor	editor	administrator
   Workbench Access
   Administer Workbench Access settings						Checked
   Assign users to Workbench Access sections					Checked	Checked
   Allow all members of this role to be assigned to Workbench Access sections			Checked	Checked	Checked	Checked
   Batch update section assignments for content					Checked	Checked
   View Workbench Access information			Checked	Checked	Checked	Checked
   View taxonomy term pages for Workbench Access vocabulary						Checked

2. Next, go to the Workbench Access roles page by navigating to Configuration→Workbench→Workbench Access, then the Roles tab (admin/config/workbench/access/roles). This is the page where you can assign user roles to Workbench Access sections.

   You’ll see a listing of the taxonomy terms within the “News sections” vocabulary that are currently actively used as Workbench Access sections. Right now, all the terms within our vocabulary are being used as Workbench Access sections, because we checked the “Automated section assignment” checkbox on the Workbench Access settings page. Later in this section, we’ll see how you can control which terms are used as Workbench Access sections.

   One of the two new roles we created is called “national editor”: users within this role should have access to content tagged with the term “national news.” To set this up, click the “National news” link in the list of active Workbench Access sections. On that page, check the “national editor” role and click the “Update roles” button.

   Now do the same for users with the “culture editor” role in order to give those users access to content tagged with the “culture” term. Go back to the Workbench Roles overview page by clicking the Roles tab (admin/config/workbench/access/roles), and click Culture in the list of active Workbench Access sections. Check “culture editor” under Roles and click “Update roles.”

   Note that users with the “administrator” and “editor” roles also need to be assigned to Workbench Access sections in order to be able to assign content to sections. We’ll assign both user roles to all sections. Click the “News sections” link at the top of the hierarchy in the Workbench Access sections list and check the boxes for both the “administrator” and “editor” roles. They will automatically inherit permissions to all subterms.

   Congratulations! Our new user roles now have access to content that’s relevant to them, as shown in Figure 7-20.

   

   Figure 7-20. The assigned Workbench Access sections for each role

Note

If your use case requires you to assign certain Workbench Access sections to individual users rather than user roles, you’re in luck, since Workbench Access allows for that as well, via the Editors tab. This page works the same way as Workbench Access’s Roles page, but for individual users instead of roles: click “0 editors” next to the Workbench section you want to assign to an individual user, and simply add the user(s) on the next page.

Now that you’ve configured which roles or users have editorial access to content in certain Workbench Access sections, it’s time to assign some of our content to a section, so our editors can access it. Normally, content is assigned to a Workbench section when an author creates the content and attaches a taxonomy term to it; the node is assigned to the section that corresponds to the taxonomy term. The content will then appear on the My Workbench page. Since we didn’t assign any Workbench Access sections to any of our content items yet, however, the My Workbench page is still empty at this point.

1. Click the “Find content” shortcut in the administrative toolbar (admin/content). Since you’re an administrator and thus have the “Administer content” and “View content overview page” permissions, you can administer content through this page as well. Editors don’t have these permissions won’t be able to access this page and will use the My Workbench page for managing content, seeing only the content that is relevant for them.

2. You can assign a Workbench section in two different ways:

   1. Check the box in front of the content item you wish to assign to a Workbench section and then, under “Update options,” select the section you wish to assign the item to under “Set editorial section.” Note that in order to do this, you need the “Batch update section assignments for content” permission (admin/people/permissions) and access to the Workbench section(s) you want to assign content to.

   2. Go to the content items edit page, and scroll down until you see the “Editorial section” select list; this is the list of Workbench Access sections. Pick the section you want to assign the content to and save the page.

Go ahead and add a few of the generated nodes to each section. Once done, you’ll see the message shown in Figure 7-21 on any individual piece of content’s page, which indicates the section it’s in.

Figure 7-21. A message at the top of a content page confirms which Workbench section the node is assigned to; if logged in as the section editor, you will see an Edit tab

That is the final step we need for this part of the site’s functionality: editors with access to the “National news” Workbench section will be able to edit this node, either via the My Workbench page, or by clicking Edit on the node page. However, editors with only “culture” access will not. If you navigate to the My Workbench page as one of the specialty editors, you’ll notice the list of content there is now filtered to show only things in their section.

In the previous section, we completed an important feature of the Our Media site. Existing editorial groups can now edit content they are responsible for, and only that content. However, to enable editors to effectively manage the flow of articles coming in, we need something else: an editorial workflow system that allows them to easily determine when an article is ready for review, and to either send it back to the reporter when it needs more work, or to publish it on the site when it’s good to go.

Out of the box, Drupal allows a piece of content to be either published or unpublished. When the “published” checkbox is unchecked on the node editing form, only users with the “administer nodes” permission are allowed to view the content. That’s enough for some sites, but it doesn’t give our reporters and editors as much control as they need. For example, there’s no way for a reporter to mark an article as an in-progress draft and come back to it later. In addition, there’s no easy way for an editor to tell a reporter that an article needs more work—the editor must contact the author manually.

This problem is exactly what Workbench Moderation (http://drupal.org/project/workbench_moderation), another part of the Workbench suite, was designed to solve. It allows site administrators to set up predefined steps, called states, through which every piece of content must pass before publication. A news site might need “Draft,” “Needs review,” and “Published” states, where a software development company might need “New,” “Verified,” “Needs review,” “Needs work,” “Passes QA,” and “Fixed” states. You can set up access control around who is allowed to move things from one state to another (and back), ensuring that the right people give the content their stamp of approval before content goes live.

Editorial Workflow Management with Workbench Moderation

Using Workbench Moderation, administrators can define workflow states that suit their site’s needs. As shown in Figure 7-22, they can decide how the states are called, determining the order of the states a piece of content has to move through. As we will see when we configure Workbench Moderation later in this chapter, administrators can also configure the transitions between workflow states to allow only those state changes they need or want to allow.

Figure 7-22. Configuring Workbench Moderation states settings

Since Workbench Moderation is part of the Workbench series of modules, it tightly integrates with the central Workbench page that users get as their content management “home base.” When Workbench Moderation is enabled, the “My Workbench” page (admin/workbench) displays a tab for every moderation state, as shown in Figure 7-23. This makes it very easy for editors to find content that is currently being worked on by reporters (drafts), content that needs review, and content that is published on the site.

Figure 7-23. Workbench Moderation tabs

Remember that all of the pages displayed by these tabs are powered by the Views module, so they can be modified and extended to fit your own site’s needs.

My Drafts

This page lists content created by the currently logged-in user and that hasn’t been published yet.

Needs Review

This page lists content that has the state “Needs review” assigned to it.

These pages offer editors an overview of what’s going on with the content on the site, and editors can moderate content directly from them, by clicking the desired moderation state. More often than not, though, an editor will want to go into a piece of content, make changes, and update the content’s moderation state accordingly. Not to worry—Workbench Moderation provides several features on individual node pages.

1. When you go to one of the node pages, Workbench Moderation provides a block that displays the node’s moderation state, or rather, the revision’s current moderation state (since Workbench Moderation acts on revisions). An editor can also change the moderation state directly from this block, as shown in Figure 7-24.

   Workbench Moderation automatically creates a new revision each time a user changes a node’s moderation state. This means it is very easy to roll back changes and to revert to an earlier version of the node, if the changes are unwanted or not relevant. It also makes it possible to compare versions with each other, to see exactly what has changed.

   

   Figure 7-24. Workbench Moderation state transitions

2. One of Workbench Moderation’s great strengths is the ability to work on a new revision of a node (called a draft), while another revision is published. For example, when a reporter posts a story that has very high news value, an editor can decide to publish it, even though it could use some work. The editor can create a new draft by clicking on the “new draft” tab (shown when a node has the Published moderation state), and then give that new draft a moderation state and leave a note explaining the changes (as shown in Figure 7-25) to send it through the editorial process or publish it on the site.

   Note that Workbench Moderation’s states take over Drupal’s Published option: when a node has the moderation state Draft and no Published revision, the content will not be published on the site.

   

   Figure 7-25. Changing the moderation state on a newly created draft

3. Another very handy feature that Workbench Moderation provides for us on node pages is the moderation history. When on the node page, click the Moderate tab; you’ll see the list of recent moderation state changes, along with the changes’ details, as shown in Figure 7-26. Again, Workbench Moderation allows us to change the moderation state right from that page.

   

   Figure 7-26. Workbench Moderation history of a node

In the administrative toolbar, click Modules (admin/modules), and enable the following modules:

Remember that you can use Workbench’s modules independently of each other. If you only need an editorial workflow on your site without access control like we set up in the previous section, you can disable Workbench Access. For the purpose of this section, it doesn’t matter if you have Workbench Access or not.

After enabling the module, you need to activate content moderation for each content type you want to use it with:

Now that we’ve configured our Workbench Moderation states, transitions, and permissions, let’s see how all of this looks to our editors. When you go back to the My Workbench page (admin/workbench), you’ll see the tabs that Workbench Moderation exposes. Go ahead and edit a piece of content, and create a new draft to publish on the site.

Figure 7-30. Possible state transitions for the logged-in user are now visible on draft of node

Great! Having set up Workbench Moderation to manage the content workflow, we have completed the needed restructuring of the Our Media site, enabling editors to work with the content that is relevant to them, in an easy-to-navigate administrative interface.

We now have our new editorial system in place. We’ve met the needs of our client, but there are some other modules that are also worth checking out:

Congratulations! The Our Media website now includes all the major features that the staff wanted. We’ve used the Workflow Access module to create a distributed system for content management, preventing collisions when editors review content they are responsible for. We’ve also provided the team with an editorial workflow, which makes it easy for them to track changes to content as it moves through the editorial process. On top of that, all of this is done in a consistent, easy-to-use interface, so editors quickly find the content they need.

Here are the modules that we referenced in this chapter: