Designing Drupal Landing Pages That Authors Can Edit but Not Break

Drupal gives us strong patterns for two ends of the content-modeling spectrum.

At one end is structured, repeatable content: articles, events, people, programs, and other content types where many items share the same fields and presentation.

At the other is the general-purpose Landing Page. With an authoring tool like Mercury Editor, authors can assemble components into pages whose structure needs to remain flexible.

Some important pages sit somewhere in between.

A blog landing page might need editable introductory content, featured stories, or promotional areas. But it also needs a list of blog posts. An events landing page may include flexible content alongside filters and an event listing. A homepage may allow significant editorial control while still containing elements that should always be present.

These pages need flexibility, but they also have a job to do.

The awkward middle

One solution is to create a dedicated content type for every unique page. A Homepage content type, a Blog Landing content type, an Events Landing content type, and so on.

That provides plenty of structural control, but it also creates content types that are technically collections even though the site only expects one item. Developers then have to prevent additional nodes from being created, manage fixed paths, and explain why certain content types should only ever contain one piece of content.

The opposite approach is to build everything with a general-purpose Landing Page.

That avoids creating more content types, but it can push page-specific functionality into the component library. A Blog Listing component may exist only for /blog. Event filters may only make sense on /events.

At that point, components that are supposed to be reusable start representing one-off pieces of application structure.

It also puts responsibility in the wrong place. If a blog listing is fundamental to the purpose of /blog, an author should not need to know that it must remain on the page.

Good authoring experiences are not defined by giving authors control over everything. They give authors control over the things they are responsible for and make the rest difficult to get wrong.

What Config Pages taught us

We have used Config Pages successfully to fill this gap.

Config Pages gave us single-purpose, fieldable entities that could use familiar Drupal display patterns. With Mercury Editor integration, authors could manage those pages using the same component-based experience they used elsewhere on the site.

We could expose the parts authors should control while keeping required functionality in the display. A blog listing could be a View. An events page could always contain its filters and listing. Entity Extra Field gave us a flexible way to place Views, blocks, Single Directory Components, and other fixed elements alongside editable content.

The pattern worked well: editorial flexibility did not have to mean structural flexibility.

But on larger projects, we found ourselves repeatedly adding the same supporting architecture. Every frontend page needed a route and controller. We also ran into translation limitations on a project using TMGMT.

Config Pages had demonstrated the right content model. What we wanted was a module more directly focused on it.

Content Singleton makes the constraint explicit

Content Singleton starts from a simple idea: some types of content should have exactly one instance.

A Blog Landing singleton represents /blog. There is no collection of Blog Landing pages and no second instance for an author to accidentally create. The bundle can have its own frontend path, fields, display configuration, revisions, translations, and editorial workflow.

That lets the content model reflect the actual requirement.

The same page can still contain flexible areas. Authors might control introductory copy, featured content, imagery, or a component-based promotional region. But the blog listing itself can remain part of the display, where it cannot be accidentally removed.

That is the distinction we were after.

Config Pages and Content Singleton

Both modules can support singleton-style content, but they start from different assumptions. Config Pages is designed as a flexible system for site-wide configuration, with singleton pages as one of its uses. Content Singleton is specifically designed around fieldable content that exists exactly once.

Neither approach replaces the other. Config Pages remains useful when the requirement really is site configuration. Content Singleton is more directly aligned with the kind of pages described here, where a single editorial entity needs to behave like content and have a permanent place on the frontend.

Repeatable content types work well for content we publish many times. General-purpose Landing Pages work well when the page structure itself needs to be flexible. Content Singletons fill the space between them: pages that exist once, need a tailored editing experience, and still have structural requirements.

The result is a content model that more closely describes how the site actually works, while giving authors control over the parts of the page they are responsible for.