Drupal Wiki: Build a Knowledge Base People Can Actually Use

By Greg Nowak. Updated 2 August 2026.

A useful Drupal wiki is not simply a collection of pages that everyone can edit. It is a working knowledge base: people can find the right answer, understand whether it is current, and see who is responsible for maintaining it.

Drupal is particularly useful when documentation must share users, permissions, workflows, languages, or structured data with an intranet, support portal, client area, or product website. If you only need an informal team notebook, a lighter tool may be easier. The business case for Drupal appears when documentation is part of a wider digital operation.

Design the knowledge model before choosing modules

Start with the questions people repeatedly ask: How do we onboard a client? Who approves this request? Where is the rollback procedure? What should support do after an escalation? These questions reveal the stable sections, filters, and ownership fields the system needs.

A sensible first version often uses one documentation content type with fields for owner, audience, service area, status, last reviewed date, next review date, and related system or client. Only add a field when it changes navigation, permissions, search, reporting, or the review process. Otherwise, it becomes another form control editors learn to ignore.

A practical Drupal knowledge-base decision matrix

Operational need	Drupal capability	Use it for
A stable reading path	Book	Manuals, runbooks, onboarding guides, handbooks, and other parent-child documentation.
Several ways to group pages	Taxonomy	Department, product, audience, client, region, risk, or service-area labels.
Actionable document lists	Views	Needs Review, Recently Updated, Owned by My Team, or Client-Facing Documentation.
Search and filtering	Search API	Index selected fields, tune relevance, add filters, and change search backends as requirements grow.
Controlled publishing	Content Moderation	Keep the approved version live while a replacement moves through draft and review.

Use hierarchy and taxonomy for different jobs

The Book module provides chapters, sections, parent-child ordering, and previous, next, and up navigation. Use it for the primary reading path. Taxonomy should handle relationships that cross that path. A support procedure might belong under Product Support while also carrying terms for Billing, Europe, SLA, and Account Management.

Do not mistake a Book tree for a security boundary. Drupal’s standard Book permissions apply through content types and general Book capabilities; the module does not provide separate rights for each book by default. If different clients or departments must see different material, design access at the content or entity level and test it before importing documents.

Install a currently supported baseline

Book was part of Drupal core through Drupal 10 and became a contributed module for Drupal 11. As of August 2026, Book 2.x supports Drupal 10.3 and 11, while the active Book 3.x branch supports Drupal 11.2 and 12.

For Drupal 10.3 or Drupal 11 using Book 2.x, a supported starting point is:

composer require 'drupal/book:^2.0' 'drupal/search_api:^1.41'
drush en book search_api search_api_db content_moderation -y

On Drupal 11.2 or later, you can choose the Book 3.x branch:

composer require 'drupal/book:^3.0' 'drupal/search_api:^1.41'
drush en book search_api search_api_db content_moderation -y

These commands assume Drush is already available. Search API 1.41 currently lists Drupal 10.3 and 11 support, not Drupal 12. For a Drupal 12 project, Book 3.x is supported, but verify Search API and the intended backend before committing to the search architecture.

Treat search access as a launch requirement

The database backend included with Search API is a convenient starting point for testing and smaller libraries. Larger collections or demanding relevance and traffic requirements may justify a dedicated backend. Make that decision from measured needs rather than adding infrastructure automatically.

More importantly, Search API does not provide generic access restrictions for every possible data source. It includes support for node-access checks and additional checks in search views, but the implementer remains responsible for ensuring restricted items are not exposed through indexing, results, excerpts, facets, or autocomplete.

Test search with at least three realistic accounts: a client or anonymous user, a standard internal user, and an editor. Search for the exact titles and distinctive phrases of restricted pages. Also inspect filters, result counts, and excerpts; hiding the final page is not enough if the result itself reveals confidential information.

Build trust with ownership and review

Every important document needs an owner and a review rhythm. A simple Views page showing overdue reviews is often more valuable than a decorative dashboard. It gives operations teams a queue they can act on and makes neglected documentation visible before somebody follows an obsolete procedure.

Use Content Moderation when unreviewed edits must not immediately replace approved guidance. Drupal can keep the published revision live while a working copy moves through configured states and transitions. The default Editorial workflow is created for sites installed with the standard profile; other installation profiles may require you to create or import it and assign the documentation content type.

A practical workflow is usually enough: Draft, Needs Review, Published, and Archived. Add more states only when they represent a real decision with a named owner. Complex approval diagrams do not improve documentation if nobody is responsible for moving content forward.

Launch around real work, not an empty structure

Begin with one valuable area—client handover, an operations manual, or a platform runbook—and migrate a small set of actively used documents. Watch what people search for, where they abandon navigation, and which pages generate follow-up questions. Improve the model before scaling the library.

For agencies, this creates a practical bridge between delivery and support. Decisions, integration notes, known limitations, recovery procedures, content rules, and maintenance responsibilities can remain connected instead of disappearing across tickets and handover files.

If your Drupal wiki has become a page dump, the usual recovery order is information architecture, access design, workflow, and then search tuning. Greg can help you plan that work, challenge unnecessary complexity, and turn the knowledge base into something people can rely on. Talk to Greg about your Drupal knowledge-base project.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about your Drupal knowledge base Get in touch with Greg.

Sources

Last modified

2026-08-12