How We Built a Drupal-Based Content Hub for Multi-site News Sharing

From Domain Access to Entity Share, the approach you take depends on exactly what you want to achieve. Key questions to ask include: 

• Where is the content created?
• What is the source of truth?
• Does it vary from site to site?
• Who can edit what content, and who can publish it?

Domain Access and Entity Share effectively result in the same content being available in the CMS for each site. Another approach is to host the content from the central “hub” site, and access it from the frontend of each of the downstream “satellite” sites. 

Decoupled Drupal 

We recently worked on a Decoupled Drupal implementation for a higher education institution. 

Our goal was to create a content hub site that serves as the institution's central repository for news articles. The site features curated listing pages and blocks that display news articles from various topics and organisational units. 

Satellite sites have their own informational content, but can embed listings of news articles from the central repository. The embedded listings can be a complete page listing, or a smaller curated block of recent news items for a particular topic, usually appearing at the bottom of a page. The news items don’t need to display in full on the satellite sites; they all link to the central site.

Architecture overview

The central Drupal site serves as the source of truth for news articles and is where all authoring takes place. The backbone of this is the news article content type, with various taxonomy vocabularies for categorising content by topic and target organisational units. It featured over 10,000 articles dating back to 1997, migrated from legacy Drupal 7 sites.

To display article listings on the central site, there are several configurable custom blocks that editors can place using Layout Builder. I discuss these in more detail later, but in brief, they allow fine-grained curation of which articles to display, with options to pull articles matching specific criteria. The individual articles are also authored with Layout Builder, providing a range of rich components from the design system, such as blockquotes, social media posts and image galleries.

While we could simply use Drupal’s built-in JSON:API to share the articles to the satellite sites, this makes it difficult to expose the same level of filtering required for curation. Instead, we built a custom controller that uses the same algorithms used in our custom blocks to fetch articles that match the given criteria. This controller returns a fine-grained response required for the downstream sites. Since we’re only showing listings, this is relatively minimal, including: title, publish date, image, URL and a summary.

The downstream sites consume this JSON endpoint via a small React app, attached to a Drupal block, once again placed by Layout Builder. The block has the same configuration options seen on the central site and shares the same appearance, but the data populates from the JSON endpoint. The design system assets help us to ensure the article cards rendered by React match exactly what we see on the central site, rendered with Pinto.

Authoring workflow

Given the breadth of this higher education institution, many teams across the organisation need to publish their own news articles. The central news team needs to publish news everywhere, but smaller “local” teams need to publish news only on the site(s) relevant to their department.

To achieve this, we used Workbench Access to assign authors to various editorial groups. Conveniently, these groups link to taxonomy terms that can be applied to news articles, which are then used as filters in our blocks to display news items. Two user roles at play here are the Author and the Publisher. Using Content Moderation, we have a basic editorial workflow. The author can create draft news items and, once they’re ready for publishing, update the status and wait for a publisher to approve them. At any point, a user with a Content Administrator role can override the publishing workflow and take control.

Publishers also need to know when there is content ready for review. We enlisted Workbench Email to configure email notifications that alert users when the content's moderation state changes. When an article is ready for publishing, all publishers in the same editorial group are notified. If the article is sent back for updates, the author or the last editor is notified. If a Content Administrator takes over the workflow, a separate set of email notifications is activated, as a different team is responsible for publishing.

Additionally, we need to be able to schedule the publishing of news articles for a future date and time. There are several ways to achieve this, but our favourite is Scheduled Transitions, which decouples scheduling from the entity itself and allows any transition to be scheduled.

You might notice a theme here. A lot of the modules mentioned so far are created or maintained by PreviousNext! It’s safe to say we have experience in editorial workflows.

Article curation and display

Now we have all our articles, how can we display them in a more editorial format that goes beyond a chronological listing? 

The central news team needs full control to curate the front page carefully. Typically, this includes a featured section above-the-fold, including a hero for the biggest story, and slots for other featured story cards. The rest of the page comprises topic-based blocks, similar to those found on modern news sites. Since these blocks are available in Layout Builder, the news team can also create unlimited landing pages for special events or topics and include their chosen articles.

The blocks offer various options, providing the news team with flexibility and total control over what’s displayed and how it appears. The first option is to choose how many articles to display in a block. Then they can determine whether they are shown as cards, in a list or grid, with or without images, according to what is available in the design system. 

There is an option to choose each article that appears. Otherwise, or if preferred, taxonomy terms can backfill the remaining items and articles tagged with those terms will fill out the remaining slots. Finally, if there are backfilled articles that shouldn’t appear in the block, the curator can choose to exclude those, and the next matching article will appear instead.

We anticipated challenges in replicating these same options on the downstream sites. 

Since the content is all hosted on the central site, we couldn’t lean on Drupal’s built-in autocomplete functionality for choosing or excluding specific articles, nor for taxonomy terms. 

Our initial prototype focused on getting the frontend React app working, so we simply used comma-separated values to represent the entity id of the news articles and taxonomy terms. Not exactly user-friendly! To improve upon this, we built another React app to enhance these text fields with custom autocomplete widgets querying the JSON:API endpoints on the central site. This approach was undoubtedly better than manually entering IDs, but it was also easier to use than Drupal’s native autocomplete widgets.

With the curated blocks now also available on the downstream sites, editors could show related news on their information pages, provide topic-based listing pages and even craft their own news landing pages.

In summary

The project started out with undeniably ambitious ideas. We planned, designed and developed a solution in collaboration with the client to achieve a seamless new experience that we are all proud of. 

What I’ve showcased here is only a small part of the overall project. We’ve barely scratched the surface regarding other requirements, such as data migration from multiple sources, modernising components in the design system, visual regression testing, WYSIWYG upgrades, Lighthouse optimisation and much more.