Empower the Content Author in Drupal
A web page in Drupal is made up of several parts. For instance, you have the header and navigation that appears on each page. You have the main content region that holds your articles or the details associated with your events. On either side of the content, you might have sidebars with blocks suggesting related content or a call to action.
Typically, each part of the page is created or managed by different members of your website team. The developers that originally created your site will have set up your header and menu, for example. You might have a trained IT member of your team tasked to create and place blocks in the sidebars as needed. Then, when a content author publishes an article, those blocks appear as planned on the article.
A setup like this taxes your IT team and limits your content authors. Let’s explore how content types, fields, and views can empower your authors to influence the block that appear in the sidebars from article to article.
Planning Your Blocks
A simple exercise in the planning process is to ask the question, when X-type of content is published, what blocks should also appear? Traditionally, this would mean a fixed set of blocks configured to be visible on that content type or based on the URL alias.
But, what if you need a more granular approach to creating and enabling blocks? What if you wanted your content author to create and enable blocks without having to train them to be a Drupal builder?
Let’s explore an example scenario where you list all the blocks you might need from one article post to another:
- More like this
- Related training
- Call to action
- Guest speakers
A few of these blocks can be set up during development to activate automatically. For example, if the article is tagged as container garden, then other articles tagged as such will appear in a "More Like This" block. But what about Calls to Action? Let’s take a closer look at those blocks that can’t be predicted with ease.
You could design a Related Training block much like the More Like This block where training events would be listed in the block just because they have been tagged with the same term.
What if the content is a how-to piece giving a sneak preview to one of the more simpler tasks that will be taught in a series of training events? In this scenario, the author wants to control which event to advertise, but she doesn’t want to include that advertisement in her narrative.
So, in the narrative content type you add a field that allows the author to reference the training event nodes that are directly associated with the content of the how-to lesson. Following the same concept as in the previous example, you hide the event reference field and print it via a Views block. The block appears in a predestined spot on the page.
With this approach, with some planning, the block can be configured to include a thumbnail image taken from the events in question along with date and time information, making it more than a list of the titles that appears in the reference field.
Call to Action
Your content author has created an article about a new technology that will be presented at the conference. You are not presenting a session, but you will be hosting a networking event for attendees who want to extend their conference experience and meeting others in the field. The article is not the event. There’s an event node in another section of the site.
You want a Call to Action block to appear with this article, giving site visitors a link to sign up for the networking session. The common practice would be to create an advertising block and then place that block to be visible for this specific article.
Another strategy would be to add a field set to the content type you use for your narratives such as blogs, news, and how-to lessons. You would add an image field, a text field, a link field, and on/off field. They would not be set to show. Instead, a contextual view block would be created, one on the lookout for someone to fill in the call-to-action fields and turn it on.
The Call to Action block will show up at the author’s discretion in a place on the page decided by the User Experience designer during the planning phase of your website development project.
Drupal 8 ships with a predefined View called Archive. It provides a block that lists months and includes a number representing how many nodes were published in that month. By default, all nodes are included but that doesn’t mean you can’t add filters to limit what gets included in the count.
Not all narrative content will be enhanced by including an Archive block, therefore having it enabled by default, could take up screen space needed for other more useful blocks. So, how does a content author turn this block on and off as needed?
First, identify the scenarios where your users would benefit from being able to find previous narratives in common with the one they are viewing. Then, using the same strategy applied for the Call to Action block, add an on/off field for the Archive block. Edit the Archive View to look for this field to be set to on.
This scenario, and the previous one, depend on your trust in the author to know when to turn on Call to Action and/or Archive. That’s where business rules come into play and ensuring all know how to follow them.
This time, your content author is creating an event with multiple guest speakers. You have decided that creating a speaker page for every guest could amount to many nodes that aren’t worth maintaining. Instead, you want to link to the speaker’s own website.
Of course, you could make this information available is a list of links as part of the event, but given all the data you are already including, it’s been decided that highlighting the speakers in their own blocks is a better option.
Using the same strategy enabled in the Call to Action scenario, you create a set of fields: image, text, link, on/off. This time however, you need the ability to have multiple speakers so you need this set of fields to repeat. There is a module called Paragraphs that will be your friend in this example.
Paragraphs allows you to create a set of fields that can be repeated on the page. Instead of including them in the display, you use a View to show the information in a block.
You might be starting to wonder about the performance of your site with all these queries on the database. And, you would be right to be concerned if you had no caching plan in place. Outside of Drupal, you have caching tools such as Varnish that can help deliver your pages quickly.
Have a Plan
When it comes to Drupal, using your imagination is key to empowering your content authors. Start by mapping your processes. Ask yourself what has to be available in order to execute the process differently.
Remember, you don’t have to teach your content authors how to create and place blocks. You can plan ahead and give them simple options within the environment they will already be working. Assuming default processes are your only option can frustrate your users.
Promet offers best practice Training to help give your team the know-how to be prepared for these scenarios. Want to run scenarios like this by our experts to get advice on pages, or even plan a new website from the ground up? Promet is happy to create small and large planning exercises for you and your team to get the most out of your Drupal site.