Vocabulary Types

When a site needs editorial content that belongs to a whole category rather than to any single item inside it — a hero image for Destinations, an introduction above the list of Recipes, a legal note under Brands — Drupal offers no built-in place to put it. A taxonomy vocabulary is a configuration entity: it holds a name and a description, and nothing else. Every workaround leaks. An artificial parent term invents a term that means nothing to the site and shows up in term lists, autocompletes and the hierarchy. A node used as a landing page is tied to the vocabulary by nothing at all, so renaming or deleting the vocabulary silently orphans it. Third-party settings on the vocabulary push editorial content into configuration, where there are no revisions, no translations and no Field UI, and where it travels in config exports.

This module solves that by giving a vocabulary a page of its own: a content entity that represents the vocabulary itself, with its own fields, revisions, translations, publication state and URL. One page per vocabulary, no more, and nothing is created until an editor ticks a checkbox on the vocabulary form. The vocabulary stays configuration and is exported as configuration, and no taxonomy term is created or treated as special.

New to Drupal? Think of it this way: a vocabulary is a list of categories — "Destinations", "Brands", "Recipes". Normally you can write content on each individual category in that list, but never on the list itself. This module gives the list its own editable page, so you can put a photo, an introduction or a call to action on Destinations as a whole, and then manage it exactly like any other content: fields, revisions, translations, a URL and a template.

Use it when a category has to say something for itself: a landing page above a term listing, an SEO introduction for a taxonomy-driven section, a banner or call to action per category, or metadata a view needs that no single term owns.

Features

The basic functionality is one checkbox. Editing a vocabulary shows a Vocabulary type section; ticking Give this vocabulary a page of its own creates the page and its type. A Vocabulary type tab then appears in that vocabulary's own tab row, holding Manage fields, Manage form display and Manage display — the same screens a content type has, in the place where that vocabulary is already administered.

Key features include:

• One editorial page per taxonomy vocabulary, created on demand and never before it is asked for.
• Its own fields through Field UI, with Manage form display, Manage display, view modes and field groups.
• Revisions, with revert and delete, and an optional "create a new revision on every save" default per vocabulary.
• Translations field by field through Content Translation, and published/unpublished states with Content Moderation support.
• A public address of its own at /vocabulary/{id}, with a URL alias field so Pathauto can give it a readable path.
• A visibility switch that guards the address only: with it off, the page still renders through Views, JSON:API and entity references, so it can feed a block or a listing without having a public URL.
• Its own Twig template and the same set of theme suggestions a node gets, plus per-vocabulary body classes.
• One vocabulary owns at most one page, enforced twice — by a validation constraint and by a unique key in the database — so a duplicate cannot be created through the interface, the API or a direct write.
• The type takes the vocabulary's name and follows it when the vocabulary is renamed, so the two can never drift apart.
• A configurable policy for what happens to a page when its vocabulary is deleted: block the deletion, keep the page without a vocabulary, or delete it too.

When and why would someone use this module? Use cases include:

• Category landing pages: a hero image, an introduction and a call to action above the terms of a vocabulary, edited by the content team rather than built by a developer.
• SEO for taxonomy-driven sections: real editorial text and meta tags on a category page, instead of a bare list of terms.
• Multilingual catalogues: a translated description per category that lives with the category and not in a node someone may delete.
• Data a view needs: a banner, a colour or an icon that belongs to the whole vocabulary, exposed to Views like any other field.
• Works with: Views, Layout Builder, Content Moderation, Metatag, Pathauto, JSON:API and tokens, because the page is an ordinary content entity.

Post-Installation

After enabling the module no new content type appears and there is nothing to configure before you can use it. Everything happens on the vocabulary itself:

1. Go to Administration → Structure → Taxonomy, pick a vocabulary and click Edit.
2. At the bottom of the form open the Vocabulary type section and tick Give this vocabulary a page of its own. Save.
3. A Vocabulary type tab now appears in that vocabulary's tab row. Use it to add fields and to arrange the form and the display, exactly as you would for a content type.
4. The same section of the vocabulary form holds the remaining decisions: whether visitors may open the page at its own address, whether saving creates a revision, a link to see the page on the site and a link to Manage fields.
5. Fill the page in and visit it at /vocabulary/{id}, or give it a readable alias with Pathauto.

Unticking the checkbox unpublishes the page and keeps it. Deleting is always a separate, explicit step offered as its own link: a page holds editorial work, revisions and translations, and losing that should never be a side effect of clearing a checkbox.

The module has a single setting, reached from Configure on the modules page next to its Help and Permissions links: what happens to a page when its vocabulary is deleted. The default blocks the deletion until the page is dealt with. Deleting a vocabulary already removes all of its terms, so taking editorial content with it silently is not something anyone should discover afterwards.

Permissions live under People → Permissions, and include create, edit and delete permissions generated for each vocabulary that has a page. Clear caches (drush cr) if the tab or the section does not appear immediately after enabling the module.

Additional Requirements

This module requires no external libraries, third-party APIs or contributed modules. The only requirements are:

• Drupal core ^11
• Taxonomy, Field and User (core modules, enabled by default)
• Field UI, to add and arrange fields through the interface

Recommended modules/libraries

All optional. The module detects them automatically when present and adds nothing when they are absent:

• Pathauto — generates readable aliases, so visitors see /destinations instead of /vocabulary/1.
• Metatag — per-page meta tags, exactly as on any content entity.
• Content Translation (core) — translate a page field by field.
• Config Translation (core) — translate the type's own settings.
• Content Moderation (core) — editorial workflows for pages.
• Layout Builder (core) — lay a page out per type or per individual page.
• Views (core) — list pages, or pull a vocabulary's page into a listing of its terms.
• Comment (core) — if enabled, add a comment field like anywhere else.

Similar projects

• Fieldable Vocabularies — Exposes the vocabulary itself to the field system, so the field values belong to the vocabulary entity. This module takes the opposite approach: it leaves the vocabulary untouched as configuration and puts the content in a separate content entity that references it, which is what makes revisions, translations, moderation and a public URL possible at all. Worth noting that Fieldable Vocabularies currently has no supported stable release and is seeking co-maintainers.
• Config Pages — Creates fieldable singleton pages for site-wide settings: contact details, social links, footer content. It is an excellent fit when the content belongs to the whole site, and it is not tied to taxonomy in any way. This module is for content that belongs to one vocabulary and has to follow that vocabulary's life cycle, including what happens when it is renamed or deleted.
• Entity Construction Kit (ECK) — Lets a site builder define custom entity types of any shape. You could build this with ECK and then write the code that ties each entity to a vocabulary, keeps the pair unique, hangs the administration screens off the vocabulary and decides what happens on deletion. That plumbing is precisely what this module is.
• Using a node as a landing page (manual approach) — The most common workaround, and it needs no module at all: create a node, link it from the menu, done. It works until someone renames or deletes the vocabulary, because nothing connects the two. There is no report that tells you which category is missing its page, and nothing stops a second one being created.

If none of the above fits, this module may be worth evaluating as a small, core-only option that adds one checkbox to a screen site builders already use, and nothing anywhere else.

Recommended projects

I also maintain and recommend the following modules. None of them rewrite or override Drupal's core output — they integrate cleanly with the existing system, extend its native capabilities, and work perfectly alongside this module:

• CKEditor Advanced Container — Adds a flexbox-based container and column layout system directly inside CKEditor 5, so editors can build responsive multi-column layouts inside a text field without tables, a CSS framework or developer involvement.
• CKEditor Media Image Style — Adds a style selector button to the CKEditor 5 media toolbar so editors can choose an image style per embed, without creating new view modes.
• CKEditor Media Title — Lets editors set a custom title attribute on media images embedded through CKEditor 5, directly from the media toolbar. Extends Drupal's native media embed without replacing the rendering pipeline.
• Media Reference Override — Extends Drupal's standard media reference field to allow per-reference overrides of fields like alt text or title, storing the override on the referencing entity rather than the media entity itself. The original media remains untouched and reusable everywhere else.
• Advanced Image Media Attributes Formatter — Extends Drupal's native image field formatters to expose additional HTML attributes (alt, title, class, etc.) as configurable options, without replacing or patching the core rendering system.
• Logo Image Enhanced — Extends Drupal's built-in site logo handling with additional image field controls, giving sites more flexibility over how the logo is rendered and attributed without overriding theme templates.
• Htaccess — Provides a UI for managing .htaccess rules directly from the Drupal admin interface. Useful for hardening production environments without manual file editing.

Commercial Support

This module is developed and maintained by Nelo.
The maintainer is available for professional consulting and architectural guidance related to entity and taxonomy architecture, editorial workflows, multilingual content models, and production Drupal implementations.

• drupal.org/u/nelo_drup

Supporting this Module

- Check out our sponsor, Dom Host Seo, who made this module possible with their support!

Community Documentation

Currently no external videos or demo sites are available. The module ships with a README covering the concepts, the URLs, the permissions and the developer API, and with detailed help text accessible via Help > Vocabulary Types.

For questions, bug reports, or feature requests, please use the issue queue on Drupal.org.