We use cookies to offer you a better browsing experience, analyze site traffic, personalize content, and serve targeted advertisements. Read about how we use cookies and how you can control them by clicking "Cookie Settings." If you continue to use this site, you consent to our use of cookies.

Privacy Preference Center

Acquia’s websites may request cookies to be set on your device. We use cookies to enrich and personalize your user experience. Cookies help us know when you visit our websites, how you interact with us, and what content you view, so we can customize your experience with Acquia, including offering you more relevant content and advertising. You can also change your cookie preferences. Note, that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.

Essential Website Cookies:
These cookies are strictly necessary to provide you with services available through our websites and to use some of its features (such as access to secure areas). Since these cookies are strictly necessary to deliver the websites, you cannot refuse them without impacting your experience and how our websites function. You can block or delete them by changing your browser settings, as described under the heading "How can I control cookies?" in the Cookie Policy.

Non-Essential Website Cookies:
These cookies collect information that is used to help us understand how our websites are being used, how effective our marketing campaigns are, or to help us customize our websites and applications to enhance your experience. You can click below to remove these cookies from your website experience. However, without these cookies, certain functionality may become unavailable or unusable.

D8 Module Recap: Workbench Moderation, Rules and Inline Entity Form

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.

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."

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."

Rules

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.

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.

Get updates

Receive the best content about the future of marketing, industry shifts, and other thought leadership.

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.