When you get past a few people generating content for your site, you're going to want to set up a publishing workflow. This excerpt from Byron, Berry, et al.'s Using Drupal will introduce you to Drupal's Workflow module, which was designed to solve such situations.
When the built-in “published” flag that Drupal provides for every piece of content 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 writers and editors as much control as they need. For example, there’s no way for a writer to mark a story as an in-progress draft and come back to it later. In addition, there’s no easy way for an editor to tell a writer that an article needs more work—the editor must contact the author manually.
This problem is exactly what the Workflow module (http://drupal.org/project/workflow) 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 complex site with strict legal requirements might need “Editorial review,” “Legal review,” “Executive approval,” and “Ready to publish” states. When a node is in one of those states, only users in specific roles are allowed to move it to the next state, ensuring that the right people give the content their stamp of approval before it goes live.
The selection of workflow states can be done directly during node creation and editing through a new fieldset added to the node form, as seen in Figure 6.7. Along with changing the state, a user can also leave a comment in the workflow log. This way others can see reasons or notes about a change. Workflow also allows users to schedule a state-change for a specific time. Moving a page from “Executive approval” to “Ready to publish,” for example, can be scheduled for 8:00 a.m., even if the VP made the decision at 11:00 p.m. the previous night.
In addition to the node form controls, Workflow provides a tab to the node form next to the View and Edit tabs. This tab shows the same state and scheduling controls, along with the Workflow History log that tracks every state change and displays any comments that were left. An example of the log is shown in Figure 6.8.
Even more important, the Workflow module can leverage Drupal’s actions. Every time a node moves from one state to another, specific actions can be fired. For example, the legal department could be notified via email when an editor moves a node from “Editorial review” to “Legal review.” When the vice president signs off on a new piece of content, moving it from “Executive review” to “Ready to publish,” actions can automatically publish the node and promote it to the front page.
In addition to Workflow, the Workflow Access module is also included with the Workflow package. It can hide posts from users based on their roles and the current state of the content. In our complex example, only users with the “legal team” role might be given access to nodes in the “Legal review” state.
For the Twin City Arts site, we are going to need a few states for stories to pass through. We will need a “Draft” state for writers to save in-progress work that isn’t ready to be reviewed yet, and we will need a “Review” state once a piece is submitted. Finally, we will need an “Approved” state where the story is published for all to see on the site.
Go to Administer→Site building→Modules (admin/build/modules) and enable the following module:
Then go to Administer→Site building→Workflow (admin/build/workflow). You will see a message that says, “No workflows have been added. Would you like to add a workflow?” To create one, click the “Add workflow” tab (admin/build/workflow/add).
Enter a Workflow Name of “Article publication” and click the “Add workflow” button.
We are brought to the main workflow listing page shown in Figure 6.9, and we can see that our new “Article publication” workflow has been added to the list. At the bottom of the page is a list of content types. We want our workflow to apply to the Story content type, since that is what we use for articles. Click the select list in the Workflow column for the Story content type and select “Article publication.” Click “Save workflow mapping” to save the changes.
We now have a workflow assigned to Story content, but it doesn’t do anything yet. We need to add the various states we want for our articles. Click the “Add state” link. Enter “Draft” as the “State name” and click Save.
Follow the same process, clicking “Add state,” and adding each of the other two states: Review and Approved. Your Workflow list should look like Figure 6.10 when you are done.
Fill out the workflow transitions by checking off the roles, following Table 6.5, as shown in Figure 6.11. Note that we are intentionally not setting anything in the “Approved” row, because once it is approved and published it won’t go “backward” to either the “Draft” or “Review” states.
Table 6.5. Transition settings for the “Article publication” workflow
From / To
On this screen, the last thing we need to do is determine who will see the Workflow tab when looking at nodes. Everyone will already see the regular workflow fieldset on the node form itself. Those that have the tab as well will get the added benefit of reviewing the Workflow History log. We’ll set our editors up for that by checking the “editor” role under “Workflow tab” permissions. Click the Save button when you are done.
One final piece still remains: the action that sends email to the editors is still set up to fire whenever a node is saved. We want it to notify editors whenever a node is submitted for review, not necessarily when it is created. Again, make sure you are on Administer→Site building→Workflow (admin/build/workflow) and click the Actions link for the “Article publishing” workflow. This will take you to the Trigger module’s configuration page again, but this time you will notice you are on the Workflow tab.
We are presented with a list of the transitions that we have defined for our workflow. Set the actions for them according to Table 6.6, clicking Assign for each action you add to a trigger. When finished, your screen should look like Figure 6.11. It's also a good idea to remove the actions we assigned on the Node Triggers page (admin/build/trigger/node). Now that actions are triggered by workflow states, we don't need the old ones.
Table 6.6. Assigning actions to workflow triggers
When story moves from (creation) to Review
system: Notify editor
system: Placate author
When story moves from Draft to Review
system: Notify editor
system: Placate author
When story moves from Review to Draft
system: Agitate author
When story moves from Review to Approved
node: Publish post
When you add the “Publish post” action, Drupal will automatically add the “Save post” action, too, along with a message explaining why: “You have added an action that changes the property of a post. A Save post action has been added so that the property change will be saved.” Because we are making a change to the node’s status, that change needs to be saved as well.
Now, if we go to Create content→Story (node/add/story) and create a new Story, under the “Article publication” fieldset we can see that writers have the ability to set the status to either the Draft or Review states, but not the Approved state, as shown in Figure 6.12.
Go ahead and create a story or two. Set at least one story to the Review state and you should see a message that your story has been submitted for review.
Now if you are logged in as the administrator and visit the workflow tab on a story in the Review state, you can see that you have the additional option to move the story into the “Approved” state, which regular users can’t.
Learn more about this topic from Using Drupal.
With the recipes in this book, you can take full advantage of the vast collection of community-contributed modules that make the Drupal web framework useful and unique. You'll get the information you need about how to combine modules in interesting ways (with a minimum of code-wrangling) to develop a variety of community-driven websites -- including a wiki, publishing workflow site, photo gallery, product review site, online store, user group site, and more.