Last updated 13 November 2015. Created on 1 June 2011.
Edited by mikedotexe, ashish_nirmohi, bjlewis2, robeano. Log in to edit this page.


Workbench Moderation adds arbitrary moderation states to Drupal core's "unpublished" and "published" node states, and affects the behavior of node revisions when nodes are published. Moderation states are tracked per-revision; rather than moderating nodes, Workbench Moderation moderates revisions.

Arbitrary publishing states

In Drupal, nodes may be either unpublished or published. In typical configurations, unpublished nodes are accessible only to the user who created the node and to users with administrative privileges; published nodes are visible to any visitor. For simple workflows, this allows authors and editors to maintain drafts of content. However, when content needs to be seen by multiple people before it is published—for example, when a site has an editorial or moderation workflow—there are limited ways to keep track of nodes' status. Workbench Moderation provides moderation states, so that unpublished content may be reviewed and approved before it gets published.

Node revision behavior

Workbench Moderation affects the behavior of Drupal's node revisions. When revisions are enabled for a particular node type, editing a node creates a new revision. This lets users see how a node has changed over time and revert unwanted or accidental edits. Workbench Moderation maintains this revision behavior: any time a node is edited, a new revision is created.

When there are multiple versions of a node—it has been edited multiple times, and each round of editing has been saved in a revision--there is one "current" revision. The current revision will always be the revision displayed in the node editing form when a user goes to edit a piece of content.

In Drupal core, publishing a node makes the current revision visible to site visitors (in a typical configuration). Once a node is published, its current revision is always the published version. Workbench Moderation changes this; it allows you to use an older revision of a node as the published version, while continuing to edit a newer draft.

Example of Core Revisions

Example of Workbench Moderation Revisions

Internally, Workbench Moderation does this by managing the version of the node stored in the {node} table. Drupal core looks in this table for the "current revision" of a node. Drupal core equates the "current revision" of a node with both the editable revision and, if the node is published, the published revision. Workbench Moderation separates these two concepts; it stores the published revision of a node in the {node} table, but uses the latest revision in the {node_revision} table when the node is edited. Workbench Moderation's treatment of revisions is identical to that of Drupal core until a node is published.

Moderation states and revisions

Workbench Moderation maintains moderation states for revisions, rather than for nodes. Since each revision may reflect a unique version of a node, the state may need to be revisited when a new revision is created. This also allows users to track the moderation history of a particular revision, right up through the point where it is published.

Revisions are linear; revision history may not fork. This means that only the latest revision—Workbench Moderation calls this the "current draft"—may be edited or moderated.


If you prefer to learn by watching screencasts, there is a series on the Workbench Suite at

Looking for support? Visit the forums, or join #drupal-support in IRC.