What Does Workbench Moderation Do?
Workbench Moderation is a key component in the Workbench suite of modules — Workbench, Workbench Access, and Workbench Moderation. As Ken Rickard puts it, "Workbench makes complex tasks simple and provides a common user experience that makes Drupal easier to use."
Larry describes a common situation: "At Palantir.net, we often got requests from academic clients for 'approval workflows.' Usually clients would describe highly complex ideal workflows, but after some discussion, they realized all they really needed was save-as-draft and someone-else-approves. Workbench Moderation was built to easily handle both of those use cases, which it turns out is the 85% use case."
Ken adds, "We tracked the common workflow issues we were being asked to solve, and collaborated on an approach that we could apply to all future projects."
So Workbench was developed for Drupal 7 to address a set of common editorial problems:
- An editorial workspace customized for each editor, which shows what work needs to be done next.
- A draft-revision-published workflow
- Review states that require permission to publish content
- The ability to create a new "forward revision" waiting for approval while retaining the published version
- An extensible, consistent workflow system
- Access controls that grant access to specific sections of a website using a hierarchy that maps to an organization chart
Workbench Moderation enables "forward revisions" on content; each revision gets marked in a particular state. These states are often simply "Draft," "Needs Review," and "Approved/Published," but WBM is completely configurable. You can add "Needs Legal Signoff" or any other state to the approval workflow. Via configuration and permissions you can also control who is able to move the forward revision from one state to another. This lets you reflect the roles of authors, editors, moderators, or your legal department. Revision states can also be set to cause an entity to become the new default revision, and to make it published or not, thereby allowing for an "archived" state.
"In Drupal 7, it only worked for nodes," Larry explained to me, "For Drupal 8, it works on (almost) any content entity that supports revisions and bundles. In core that's Nodes and Block Content, but it can work with others, too."
As of mid-2016, roughly 29,300 sites report using the base Workbench Module, 6,300 Workbench Access, and 24,000 Workbench Moderation (including 1,100 Drupal 8 sites).
Why Does It Matter?
Workbench Moderation is a site administrator’s friend. Larry Garfield walked me through some different "levels" of Workbench Moderation use cases from simple to advanced:
- Simple: "WBM covers the low-to-middle end of content moderation needs pretty much out-of-the-box. In its simplest configuration, it provides "save as draft" type functionality very easily. In my experience, the default configuration is usable for most sites without any further modification."
- Level up: "By giving different user roles access to move content to different states, the common ‘contributors can post articles, but only editors can approve them’ use case is set up and covered in about 10 minutes."
- Bonus round - Do it later: "When combined with the new Scheduled Updates Module, both publishing and unpublishing can be scheduled to happen automatically at some point in the future."
- Boss level: "WBM works on a single entity at a time. That means it does not cover publishing a large set of content all at once. However, it does integrate with the new Workspace Module to allow the Workspace itself to be moderated as a whole." (Joe Purcell also told me about his work on this feature.) "Marking a Workspace published in WBM triggers the Workspace to be published all at once. For very advanced use cases, I’d recommend this process."
Maintainers: Wolfgang Ziegler (fago on Drupal.org, founder and CEO/CTO of the Vienna-based Drupal company drunomics and the creator of Rules and Klaus Purer (klausi) and Josef Dabernig (dasjo), who are both major contributors and were part of the effort to upgrade Rules to Drupal 8.
What Does Rules Do?
The Rules Module provides site builders and administrators with a powerful user interface to create custom automated workflows on a website, without any coding, using "reactive" rules. Reactive rules are also known as ECA rules: an Event happens under a certain Condition, triggering an Action. Site builders can use the Rules module to react when something happens on a site and conditionally manipulate data or execute any logic necessary. Rules even lets you schedule tasks for the future on a one-off or recurring basis. A classic example would be when you create a rule for your site to email you when someone posts a comment, but Rules is in active use on roughly 300,000 Drupal websites and covers a huge number of other use cases.
Josef Dabernig told me, "We have a couple of interviews as part of the Rules Initiative where one quote I like was, 'Rules eliminates the middleman. It empowers those who know about their business use cases to actually implement them using site-building tools—the user interface—on Drupal websites,' that is, without having to know how to write any code." Putting power into the hands of the end-user is what I call 'Drupal's most important design decision,' and Rules is an impressive expression of that ideal. And Josef also suspects that since Rules includes loops and conditions, it may well be a Turing completeprogramming language at the user interface level, too.
However, at the code level. Rules is also tightly integrated with Drupal core APIs and all structured data exposed through the Entity and Field systems. Contributed modules can extend the module by providing additional events, conditions, and actions. In Drupal 7, hundreds of other contributed modules take advantages of Rules' flexibility and integrate with the Rules API.
Why Does it Matter?
Developers can save a lot of time by off-loading commonly needed tasks to Rules. Instead of writing one-off, potentially less-compatible code, taking advantage of Rules and its API gives you standardized, compatible, repeatable ways to do things like checking any kind of user-configurable conditions before taking some (also configurable) action, like for example, checking whether a commerce discount needs to be applied to a particular purchase.
Josef pointed out in this context, "It's really the part of the ecosystem where everything connects. So it's not just the Rules module itself that makes the difference, but the power of the Rules module comes from the integrations it makes possible. In Drupal 7, we have over 300 modules like the Flag module, like Views, Bulk Operations, they all integrate and create this powerful, rich tool where Rules can then hook into all the data structures of the website. Rules can trigger any events that maybe the Workbench Moderation module provides or Rules can perform actions defined by other integration modules."
Site owners and administrators are empowered to configure various custom workflows without having to code. That way it helps to save time and makes a lot of changes possible without having to involve a developer. So when they say "Rules eliminates the middleman," it means Rules helps because we don't always want to have to go to a developer just to customize a string as part of an email notification, or we want to be able to change the tax rates on our eCommerce site ourselves, as needed.
Check out the full Rules profile on the Acquia Developer Center blog
Inline Entity Form
Maintainer: Florian Weber (webflo) who created Inline Entity form, Ted Bowman (tedbow), Bojan Živanović (bojanz) and Janez Urevc (who continued Weber’s work), who spent more than 3 months of developer time bringing the port to its first Drupal 8 beta release.