D8 Module Recap: Workbench Moderation, Rules and Inline Entity Form
by Reena Leone
Summer is in full swing but that doesn’t mean that Drupal 8 has slowed down. Currently there are more than 100,000 sites that have been deployed on Drupal 8! We’ve continued to document the process as modules continue to be migrated over from Drupal 7 on the Acquia Developer Center blog. This week we’re looking at Workbench Moderation, Rules, and Inline Entity Form.
Maintainers: Joe Purcell, Technical Analyst and Senior Web Developer with Digital Bridge Solutions; Ken Rickard, Director of Professional Services at Palantir.net; and Larry Garfield, Director of Runtimes, Integrations, Engines, and Services at Platform.sh.
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 complete programming 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.
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.
What Does Inline Entity Form Do?
Inline Entity Form (aka “IEF”) extends the functionality of entity reference fields in Drupal, to allow referenced entities to be created, edited, and deleted on the fly. Changes to the referenced entities are only saved when the main form is saved.
Though the problem space sounded a little dry and abstract to me at first, understanding it also helped me understand why IEF is installed on roughly 68,000 Drupal sites.
This is a solution to Drupal’s UX being “inside out” for some purposes. Doing things the “traditional Drupal way,” if a node needs to reference another entity or category, that needs to be created first. This can be frustrating, since it feels like one has to start from the end and work towards the beginning. IEF can reduce frustration by providing a more intuitive UX. eCommerce listings are a good example. In shopping catalogs, it’s common for a Product (“My T-Shirt”) to have a set of varying Attributes (size and color in this case). Each combination of Product Attribute values is called a Product Variation (red/small, blue/small, green/medium, etc.). Each Product Variation has a price and a SKU (“Stock Keeping Unit,” a unique ID code).
Why Does it Matter?
Drupal Commerce 1.x followed the unintuitive “Drupal way” pattern: To make a t-shirt product listing with all available options, you had to make an entity for each SKU (in our case: red/small, blue/small, green/medium, etc.) first before you could create the t-shirt catalog form. Once you had created all the necessary SKU’s, you could then reference those entities manually on the parent form. Bojan admits, “Naturally, people were not happy about using two different UIs to accomplish what was essentially a single operation.”
Now, using IEF, you can create, edit, and delete the relevant entities directly in the parent form (or even refer to existing ones if you already have them in your catalog). In our eCommerce example, I can create the main t-shirt form I need, add all of my SKU variations to it, and save it — all in the same UI.
Modeling this sort of data and relationships is one of Drupal’s strengths. Bojan gets to the heart of the matter, “Data models are full of 1:n relationships (“order has multiple line items”, “page has multiple paragraphs”). Implementing this in Drupal without IEF is a challenge. IEF is important because it allows proper data models to be implemented without sacrificing UX for the site’s administrative end users. The entities are also aware of the fact that they are embedded, via parents, the same way the field widgets are. This allows them to be nested as many times as needed.”
Here, the simple widget shows a row for each reference, with the entity form inside. This is the “field collection” UX.
Is there a Drupal 8 module you’d like to see profiled? Let us know in the comments!