Harnessing the Power of MediaWiki Extensions for Effective Knowledge Management

Out of the box, MediaWiki is a document wiki. For knowledge management — structured records, controlled workflows, searchable metadata — the product decisions live in the extension stack. This article is a playbook for building a knowledge hub on MediaWiki: which extensions solve which problems, in what order, and which habits keep the stack from rotting. It is deliberately opinionated: every recommendation here is battle-tested on real deployments.

Layer 1 — structure: Cargo or Semantic MediaWiki

The decision that shapes everything else: where structured data lives.

• Cargo — data in dedicated tables, queried with #cargo_query. Better performance, simpler mental model, ideal for inventories, tickets, product catalogs and other table-shaped knowledge
• Semantic MediaWiki — data as page annotations ([[Property::Value]]), richer modelling (inference, special properties), #ask queries, factboxes. Better for interconnected knowledge where relationships matter

Pick one per domain and stay disciplined; both work with Page Forms for data entry. For most product teams, Cargo is the smaller commitment.

Layer 2 — entry: Page Forms

Nobody fills in [[Property::Value]] by hand. Page Forms turns templates into forms: Special:CreateClass generates the template/form/category pair from a field list, and the 'Edit with form' tab gives editors a structured entry surface. Form-based entry is what makes the structure layer usable by non-technical staff — without it, structured data stays an admin-only exercise.

Layer 3 — templates: the contract

Structured knowledge on MediaWiki is only as consistent as its templates. Three rules that prevent template rot:

• One template per record type, with parameters documented via TemplateData (which also powers VisualEditor forms)
• No logic inside record templates — computation goes in derived templates or Scribunto modules so record pages stay readable
• A named-parameters-only policy — positional parameters are the single biggest source of template breakage over time

Layer 4 — work: review and notifications

Knowledge management implies controlled change:

• FlaggedRevs for publish-approval where records are customer-facing
• Notifications (Echo) so reviewers hear about changes — mentions and watchlist digests instead of manual polling
• AbuseFilter as a safety net on structured pages (e.g. prevent edits that would break record templates)

Layer 5 — find it: search

The default search is a fair-weather friend. When the wiki accumulates records:

• CirrusSearch (Elasticsearch/OpenSearch backend) for real full-text quality, near-real-time updates and template-expanded content — the biggest single quality jump available
• Cargo's #cargo_query/SMW's #ask with result formats for faceted lists ('all assets by owner'), which often answer more KM questions than free search

Hygiene — or how KM stacks die

• Version-pin everything — extensions must match the MediaWiki release; run php maintenance/checkExtensionDependency.php after every upgrade
• Stage before production — clone the wiki, enable new extensions, run the updater and smoke tests there; schema changes are the usual casualty
• Audit the stack annually — unload extensions nobody uses; every extension is surface area for both bugs and upgrade friction
• Keep a sandbox — give power users a scratch environment; the production wiki's data structures stay owned by the maintainers

The sequence that works

In practice, mature knowledge hubs are built in this order: templates + TemplateData → Cargo/SMW model → Page Forms entry → review workflow (FlaggedRevs + Echo) → CirrusSearch. Each layer is usable alone, so the stack can grow with the wiki's maturity — and each layer added later forces painful re-entry of existing data. Structure it early, but adopt the layers in the order above and the wiki stays alive at every stage.