Drupal can be confusing, but a fresh look at site building can make it easier and more powerful for content editors.
Drupal can be an intimidating for non-technical users who are charged with creating and maintaining content. Wordpress, its more successful open-source cousin, was designed with a singular focus: make blogging easy. Drupal, on the other hand, began life as a message board. While a blog typically has a simple content life-cycle, the legacy of Drupal’s beginnings as a multi-user system is still evident today in its often complicated content workflows.
There are a number of ways to construct pages in Drupal, with most sites built around some combination of Blocks, Views and Panels. Views aggregate content, while Blocks and Panels let you lay out content and decide which pages should display it. This often leads to a workflow in which content creation is divorced from page creation. A user creates content through one interface, while pages are constructed through an entirely different set of interfaces by administrators and architects. Display rules are often hidden deep inside the settings of individual panes or blocks. This leaves the site’s contributors unsure of where to go to edit content, and how content ends up on a page.
Other Drupal sites create pages that have baked-in features: a content type specifically for a page with an image gallery, another for when you want to have a special header treatment displayed. This leads to a very cookie-cutter approach, as content creators can’t deploy more than a handful of tools at one time.
A New Approach
At Fastspot, we’ve been working on new ways to construct web pages in Drupal. Inspired by our work on BigTree, we think of the different pieces of a page’s content as components to be edited and arranged individually. And because of that, we think that the right place to edit a page’s content is on that page itself.
For Stevens Institute of Technology, we created a flexible architecture based primarily around a single content type. We made use of a couple key modules: Inline Entity Form and Field Block.
Inline Entity Form uses the Entity API to link one node to another, and to allow creation of those linked nodes right in a page’s editing interface. Field Block adds the ability to display the content of a field in a block region, and when used with Inline Entity Form, you can render linked nodes in those regions.
There are a number of block regions defined: above-content features, below content, in the sidebar, and above the footer. The basic page type includes four inline entity fields that are set to display the nodes they link to in each of those regions. Each field is configured to allow one or more nodes of specific types to be created and edited within the page itself. To create a page, you add a new page and configure the title, body, etc. as normal. Then, on the same edit page, you can select types of nodes that you want to add to the page for link lists, accordion groups, image callouts, media galleries, etc. Once created, you can edit, delete, or rearrange them all within the same interface. This means that you are defining and managing all the content that will appear on the page in one place, but still have a lot of the flexibility you would have with panels or other systems.
In addition to simple content types that organize content, display images or link out to other pages, you can also make a content type that embeds a search interface or the results of a View. This means that users can drop components with those kinds of complicated functionality onto any page of the site with minimal configuration.
We worked to implement a similar system with the team at Amherst College. Amherst has spent years developing and using a Drupal module for handling page creation, navigation, theming, permissions, and much more: Monster Menus. The system already did a lot of what we were proposing to link nodes of different content types in page creation, but only in the main content area of the page. Amherst’s Web Services Group extended Monster Menus to add the ability to move content into other block regions, much like Field Block, but with the added ability to drag content from one region to another.
In both systems, this component-based approach required us to make use of a component-based design system. When pages have this much flexibility, it becomes paramount that design elements look good and work well regardless of their position on the page. Making use of consistent text treatments, spacing, positioning, and image sizing across components allows each page to provide a great user experience even when it is created and laid out by a content expert instead of a designer.
At the end of the day, Drupal is a powerful system that has much to offer institutions and organizations that choose to use it. But in order to be truly useful, it has to allow content creators control and ease of use, so they’re motivated and empowered to do the important work of maintaining the site. As developers, it’s our responsibility to work with Drupal in a way that makes this possible.