Bundle Publishing allows grouping of content, like reports or courses, to move through a workflow together. An ideal bundling workflow creates a container for the bundled content, allows individual nodes to make up the bundled product, and moves the nodes through approval states together without publishing until all nodes are approved. Drupal provides book modules for navigating bundled content hierarchically. Workbench Moderation and associated modules help set up state transitions and permissions for bundled content.
What's New in Teams Calling, Meetings and Devices March 2024
Bundle Publishing and Workflow
1.
2. Bundle Publishing and
Workflow
Jeannette Modic
Senior Drupal Developer at Balance Interactive
Jeannette.modic@balanceinteractive.com
@moondancerjen
July 27, 2012
3. What is Bundle Publishing?
Bundle Publishing is a way to move a group of
content through an approval workflow together.
Examples of content that could use this
functionality:
• Reports
• Guides
• Books
• Products
• Course Schedules
Balance Interactive Inc. www.BalanceInteractive.com
4. Ideal Bundling Workflow
• Create a container for the product
• Allow multiple nodes to make up of the final
product.
• Allow the nodes to move through different
workflow states.
• Don’t publish the nodes of the product until all
nodes have gone through approval and the
parent node is set to publish.
Balance Interactive Inc. www.BalanceInteractive.com
5. Benefits of the Book Module
Don’t reinvent the wheel! This comes with
Drupal!
• Navigate content with Previous and Next
buttons
• Built-in Menu with the contents of the book
• Way to relate content and control hierarchy of
nodes.
Balance Interactive Inc. www.BalanceInteractive.com
6. Workbench Moderation
• Set up the different states content can
transition through
• Set up permissions for roles to transition
content through the different states
Balance Interactive Inc. www.BalanceInteractive.com
8. Workbench Moderation Rules
• Child pages can never be set to Publish on
their own.
• If parent page is set to Published check that
all child pages are set to Ready to Publish
before looping through each node and
publishing them.
• If not all children are set to Ready to Publish
do not set any node to Published.
Balance Interactive Inc. www.BalanceInteractive.com
9. Workbench and Rules Integration
Balance Interactive Inc. www.BalanceInteractive.com
11. Workbench Access
• Based on menu or taxonomy vocabulary
• Give permissions to each section on a per-
user basis
• Confines transitioning workbench moderation
states to the sections you have access to.
Balance Interactive Inc. www.BalanceInteractive.com
Hi everyone! Thank you for coming to the Bundle Publishing and Workflow Session. My name is Jeannette Modic. I am a Senior Drupal Developer at Balance Interactive located in Springfield, Virginia. I have been working on Drupal for over 5 years. Before we get started, I want to just get an idea of who is in the audience today. How many people here know about the Workbench module? And how many people have used it before?
Bundle Publishing is a way to move a group of content through an approval workflow together. This concept recently came up for us for a client who had quarterly multipage reports. The client wanted to basically push a button on ”Release Day” and have all of the content in the report be pushed live at the same time. After we built this work we realized that there are many other “bundles” of content out there that could use this same functionality, like reports, guides, books, products, course schedules etc…
Here’s how Bundle Publishing should work: First create our parent/container node for the report. Then add multiple nodes and attach them in some way to the container. Transition the content through the different workflow states. Don’t publish the nodes of the product until all the nodes are “Ready to Publish” and the “Button has been pushed” AKA the parent/container has been published Before I get into how we solved the problem of Bundle Publishing, its important to note that as with most Drupal solutions, there are many ways to do it. I’ll try to cover some of those other options as we go through, but know that there are many ways to skin this cat.
When starting to tackle this issue we realized we needed a way to attach this bundle of nodes to a parent node. Now, this could always be done with node references, but we chose to use the much overlooked Book Module that comes with Drupal core. The book module ships with a way to relate nodes to each other, and it also comes with ways to navigate around the group of nodes using previous and next buttons and a built-in menu. Any content type can be used as a book node, so as you are building your bundle publishing workflow you can actually include multiple content types in your book including node blocks if you are using that module!
The next step after setting up your content type or types is to set up the workbench moderation states and transitions. I recommend adding a new state for your children nodes called “Ready to Publish” We will use this state to get the go ahead to publish our bundle when the time comes. Another part of this configuration is to set up the permissions for WHO can move content from one state to another.
One of the coolest things about Workbench Moderation, is that a new revision of a current live node can go through the moderation states without creating a new node, or the public seeing the node before it is ready to be published. So, in our example for our client, they can actually edit their existing quarterly report nodes and have the new revision go through moderation while the current edition shows to the public.
Now that we have the foundation set, we need to set up multiple Rules in order to cover all the possible conditions and accomplish a successful bundle publishing. It’s important to note that the Rules Integration with Workbench Moderation is only a couple months old, so if you are looking to use this functionality on an existing site, you should probably update the module to the most recent version to tap into this awesome integration! Each rule will be kicked off when a node has been transitioned to Published First rule we need is to make sure child pages are not set to Publish on their own. When the rule is triggered, we will check to see if the node id equals the book id. If it does not, then we will change the moderation state back to Ready to Be Published. The second rule will check to see if the node id equals the book id. If it does, then we check to see if the children have all been set to “Ready to Publish” if they have, then we loop through and set each node to be published. The third rule will not let the parent move to the Published state if not all children have been set to Ready to Publish.
Here is a screenshot of what the second and third rules will look like in the interface. You will see the Trigger Event is “After moderation transition” Under conditions we have a data comparison to confirm that the new state is Published, a data comparison to check that the node id = the book id, Then we have a php snippet that runs a database query to loop through the contents of the book and check that they are “Ready to Publish” returning true if all nodes are ready to publish and false if they aren’t. Under actions we have another PHP snippet that will actually publish the nodes, and a little message to print to the screen when the bundle publishing is complete. The PHP snippets are mostly just database queries. There may be functions available in the book or workbench modules that may help with these tasks, but I had trouble finding them when I was building and found a database query to be faster. And that’s all it takes to push that magic button! And the best part is, that once you have this down, you can use it to reverse the situation, and bulk archive content, or bulk update it when triggered.
All this content moderation is great, but what if you want certain content to go live a specific date and time? Well, scheduling Workbench Moderation State Transitions is as easy as adding the Scheduler and Scheduler Workbench Integration modules to your site and then turning on the settings for the necessary content types. The settings look something like this…You can turn on scheduled publishing for the content type, alter the published time of the node to match the date set, require the publishing date/time, create a new revision on publishing and set the moderation state for the content after it has been published. This same set of settings is available for Unpublishing content, which is great for archiving content or removing past events for example.
Another cool tool in the Workbench suite of modules is Workbench Access. Workbench Access works off of either a menu or taxonomy vocabulary to group content together for setting access control on a per user basis. When combined with Workbench moderation you can control who can transition content through the different states in each section rather than giving transition access across the site. This is a great tool for assigning editors per section, and making sure users can only publish content in their section not throughout the site. The only limit to the combination of Workbench Access and Workbench Moderation is that you can’t assign roles per section, so if a user has the publisher role and is assigned to three sections of the site, then they can publish in any of those sections. They can’t be an editor in one and a publisher in another.
Here is a screenshot of the Workbench Access summary interface. This screen will show you what sections are covered and which still need editors, and also who is the editor of each section. Sections are assigned when editing a user.
Now that we’ve covered bundle publishing, and workbench moderation and access, let’s get into notifying everyone of these transitions! Let’s start by emailing editors when content is ready for them to review. This can be set up with Rules using settings similar to this screenshot. The rule will be triggered by the Node: After Moderation Transition and after saving new content event. Then add a condition to check the new state, for example, check to see that we are in Needs Review, so you send the email to the right person or role to review the node.
Once you have mastered these notifications, you can get a little more technical by using the Send mail action and use a php snippet to run a database query to select all of the users of a certain role assigned to your workbench access taxonomy term/menu
All this talk about the different Workbench modules would be a waste if we didn’t talk about the awesome dashboard that comes with the base Workbench module. This dashboard is a useful tool for your content editors, writers, and administrators. It is a great alternative to the core Content List that comes with Drupal. You can moderate just by clicking a link, search content with ease, look at all content in the Needs Review state at one time, and all the content in the sections you have been assigned to.
Just wanted to give you a quick list of the modules discussed in this presentation. It’s important to note that the Workbench suite of modules are all independent of one another. You can pick and choose which ones you want to use without worrying about dependencies. There are also two workbench modules that I didn’t cover in this presentation called Workbench Files and Workbench Media. The Workbench Files module provides an easy way to see what files have been uploaded and where they are used on the site. The Media module has been integrated with Workbench too. The goal was to include a workflow for creating media just like you would any other content. All the workbench modules are linked on all the other workbench module pages.
Okay, so that concludes my presentation, we still have quite some time left, so feel free to ask me any questions you may have, and also feel free to share any cool things you’ve done with workbench/rules!