Top 10 MUST HAVE MediaWiki Extensions for Every MediaWiki

Introduction

If you run a MediaWiki instance, there are some extensions that almost every installation ends up needing — to improve editing, formatting, usability, structure, and security. Here’s a curated list of ten extensions I believe are indispensable. I explain what problem each solves, when to use it, and any trade-offs to watch out for.

The Top 10 Must-Have Extensions

1. Semantic MediaWiki (SMW)

What it does:
Allows you to add structured data inside your wiki pages (properties, relations) and then use that for advanced querying, report generation, dynamic lists, maps, and so on.

Why it’s a must:
If your content has structured parts (infoboxes, categories, attributes), SMW transforms your wiki into something closer to a knowledge base or light linked data store.

Trade-offs:
Large extension; steeper learning curve; schema and performance considerations when data gets big.

2. VisualEditor

What it does:
Provides a WYSIWYG, what-you-see-is-what-you-get interface so editors can edit content without needing to know wiki markup.

Why it’s a must:
Reduces friction especially for less technical content editors; increases participation; fewer markup errors.

Trade-offs:
More dependencies; may require more server resources; sometimes harder to debug markup issues; may require Parsoid or its equivalent.

3. ParserFunctions

What it does:
Adds logical and string functions to wiki markup: conditional statements, expressions, string handling.

Why it’s a must:
Templates become much more powerful. Without it, many templates become cumbersome or repetitive.

Trade-offs:
Enabling string functions can be dangerous if misused; some functions may affect performance; must configure properly (limits, etc.).

4. Cite

What it does:
Provides <ref> and <references /> functionality so you can have inline citations and a footnote/reference list.

Why it’s a must:
If you value content credibility, referencing, scholarly style, or any content that needs sources, this is essential.

Trade-offs:
Minimal; mostly about having users use it properly and maintain style consistency.

5. ConfirmEdit

What it does:
Adds CAPTCHA or similar human-verification modules to protect pages/actions (edits, account creation, adding URLs, etc.) from bots and spam.

Why it’s a must:
If your wiki is public or allows many anonymous edits, spam or automated abuse is almost guaranteed. This helps reduce that.

Trade-offs:
User friction; accessibility issues; additional configuration required (choosing which CAPTCHA module to use, configuring keys, etc.).

6. Wikibase

What it does:
A repository/client pair that lets your wiki manage structured linked data in a repository and expose/consume that data. Used by Wikidata.

Why it’s a must:
If your wiki’s content is data-rich and you want data reuse, multilingual entities, or external API access.

Trade-offs:
Big install; more complex setup; more moving parts; not needed for simpler wiki use cases.

7. Gadgets

What it does:
Lets admins provide optional JavaScript/CSS tools (gadgets) that users can enable in their preferences to enhance UI/UX.

Why it’s a must:
Good way to let users improve their editing environment, provide inline tools without changing core or forcing behavior for all.

Trade-offs:
Scripts can conflict; performance/trust/security concerns; must maintain CSS/JS properly.

8. Page Forms (aka Semantic Forms)

What it does:
Allows creation of forms for creating/editing pages, structured data entry, queries, and presentation. Works well with SMW.

Why it’s a must:
Makes structured content editing easy for non-technical users; enforces consistency; reduces template errors.

Trade-offs:
Form design work; dependencies; templates + SMW knowledge needed; UI complexity.

9. Advanced Search

What it does:
Improves default search: better ranking, autocomplete, facets, relevance tuning. This might include extensions like Extension:CirrusSearch (if using Elasticsearch) or other search-enhancing tools.

Why it’s a must:
As your content volume grows, good search is critical to usability. Without it, users may get frustrated.

Trade-offs:
Requires more infrastructure (e.g. search backend), may need external services or more RAM/CPU.

10. Moderation

What it does:
Tools to monitor/edit control/etc: ConfirmAccount (or similar), SpamRegex, AbuseFilter, etc. Helps handle vandalism, spam, user account abuse.

Why it’s a must:
No matter how well you configure your wiki, some bad actors will test limits. Having tools to moderate helps maintain quality.

Trade-offs:
Administration burden; may slow down very relaxed editing workflows; false positives need fine tuning.

Best Practices When Choosing Extensions

• Check compatibility: MediaWiki version, PHP version, dependent libraries.
• Maintenance status: Is the extension actively maintained? Does it have an open issue backlog?
• Performance and scaling: Extensions that add parsing logic, DB tables, or search backend can affect performance. Test before using in production.
• User and editor impact: Every extension is a trade-off. Some increase usability but also introduce complexity. Try to minimize friction.
• Security and permissions: Especially for extensions that affect user actions or open editing. Use groups/permissions carefully.

Conclusion

Having the right set of extensions can turn a plain wiki into a powerful, structured, secure, and user-friendly knowledge platform. The ten above are often the ones I find myself installing on nearly every project (at least some subset of them). If you’re starting a new MediaWiki, use this list as your “starter pack”, pick the ones that match your use case, and you’ll save time, headaches, and maintenance later on.