Jump to content

What Is MediaWiki

From SolidWiki

If you've ever clicked "Edit" on a Wikipedia article, used a Fandom wiki to look up a game's lore, or browsed an internal company knowledge base built on namespaces and templates, you've used MediaWiki - whether you noticed the name or not. Despite running some of the most visited websites in the world, MediaWiki itself is often confused with "Wikipedia" or "Wikimedia," two related but distinct things.

This article explains what MediaWiki actually is, how it works under the hood, where it excels, where it has real limitations, and how organizations typically evaluate and deploy it.

Quick Facts: MediaWiki
Initial release January 2002
Written in PHP
License GNU General Public License v2 or later (GPLv2+)
Current stable version 1.45.x
Current LTS version 1.43.x
Database support MariaDB, MySQL, PostgreSQL, SQLite
Maintained by Wikimedia Foundation & volunteer community
Notable users Wikipedia, Wiktionary, Fandom, wikiHow

What Is MediaWiki?

MediaWiki is free, open-source wiki software written primarily in PHP. It stores page content, revision history, and user data in a relational database - typically MariaDB or MySQL, though PostgreSQL and SQLite are also supported - and renders pages using its own lightweight markup language, known as wikitext, converting it into HTML for display in a standard web browser.[1]

It was originally developed in 2001–2002 by Magnus Manske to replace UseModWiki, the Perl-based software that ran the English Wikipedia in its earliest days. The new PHP-based software was deployed to Wikipedia in January 2002. As Wikipedia's traffic grew, developer Lee Daniel Crocker rewrote the codebase later that year to address performance bottlenecks, a version internally referred to as "Phase III." The software didn't carry the "MediaWiki" name yet - that came in 2003, when Wikipedia contributor Daniel Mayer suggested it as a deliberate wordplay on "Wikimedia," the name chosen that same year for the newly created Wikimedia Foundation. The first release officially carrying the MediaWiki name shipped in August 2003, and the overall architecture established then has remained broadly stable ever since.[2]

MediaWiki is licensed under the GNU General Public License version 2 (or any later version), commonly referred to as GPLv2+. That means anyone can download, run, modify, and redistribute it without paying a license fee, subject to the terms of the GPL.[3] Development is coordinated by the Wikimedia Foundation, but the actual code is written and reviewed by a global community of volunteer and paid contributors.

It's worth being precise about terminology, since the three related names cause genuine confusion. MediaWiki is the software - the wiki engine itself. Wikimedia is the non-profit foundation that runs Wikipedia and its sister projects, all of which run on MediaWiki. Wikipedia is one specific website - the free encyclopedia - built using MediaWiki and hosted by the Wikimedia Foundation. In short: MediaWiki is the engine; Wikipedia is one car built on that engine; Wikimedia is the company that owns and maintains that particular car, along with several others.

Why MediaWiki Matters

MediaWiki matters because it's a rare example of software that has been proven at extreme scale while remaining freely available to anyone. The same core codebase that serves Wikipedia's enormous global readership is the codebase an organization installs to run its own internal documentation site or public knowledge base - there is no separate "enterprise edition" with different code.

This matters practically for a few reasons:

  • Cost - because MediaWiki carries no per-seat licensing fee, organizations with large numbers of editors aren't penalized for adding more accounts, unlike many commercial knowledge base platforms.
  • Longevity - MediaWiki has been in continuous development since 2002, with a published release schedule, a security mailing list, and a defined version-lifecycle policy.
  • Data ownership - content is stored in a standard, self-hosted database and can be exported via XML, so organizations aren't locked into a proprietary format or a vendor's hosting infrastructure.

That said, "free software" is not the same as "free to operate." MediaWiki requires real technical investment - server administration, database management, and ongoing maintenance - covered in more detail in the Challenges section below.

MediaWiki is used well beyond Wikimedia's own projects. Notable examples include Fandom (formerly Wikia), one of the largest networks of fan and entertainment wikis online; wikiHow, a how-to and instructional reference site; and internal, non-public deployments such as Intellipedia and Diplopedia, used within U.S. government and intelligence community agencies.[4] Corporate intranets, university departmental wikis, and open-source project documentation sites make up a large share of less publicized but equally real MediaWiki usage.

Key Features

MediaWiki Core Features at a Glance
Feature What It Does
Wikitext & VisualEditor Pages are written in wikitext markup (e.g. Page Name for links, Template:Template Name for transclusion). The official VisualEditor extension provides a WYSIWYG alternative, built on the Parsoid rendering pipeline.
Namespaces Every page belongs to a namespace - Main, Talk, User, File, Template, Help, etc. - each carrying different default behaviors and permissions.
Revision history Every saved edit is stored with a timestamp and author, never deleted. Supports diff comparisons and one-click rollback.
Templates & transclusion Reusable wikitext blocks embedded across many pages; editing the template updates every page that uses it.
Extensions & Hooks Core functionality is extended without touching core code. Over 1,000 extensions are listed on MediaWiki.org.
Skins Controls visual layout and styling independently of content. Default skins include Vector and Vector 2022; custom skins are common for branding.
APIs The long-established Action API and the newer, OpenAPI-documented REST API (since MediaWiki 1.35) both provide programmatic access.
Multilingual support Interface translated into 400+ languages via translatewiki.net, with native Unicode and right-to-left script support.
Search Basic full-text search is built in; CirrusSearch + Elasticsearch adds relevance-ranked, faceted search for larger deployments.

Benefits

Benefits of MediaWiki
Benefit Detail
No per-seat licensing cost As GPL-licensed software, any number of editors and readers can use it without license fees. Cost shifts to infrastructure and technical labor instead.
Demonstrated scalability The same codebase serves Wikipedia, confirming the architecture can scale substantially with appropriate caching and database infrastructure.
Strong revision & audit history Every edit is preserved with full attribution, supporting compliance documentation, transparency records, and regulated technical procedures.
Mature extension ecosystem Over 1,000 available extensions can meet many requirements - structured data, visual editing, SSO - without custom development.
Active long-term development A published release cadence, a defined version-lifecycle policy, and a dedicated security process support realistic long-term planning.
Data portability Content can be exported via XML using built-in import/export tools, reducing vendor lock-in risk.
Genuine multilingual capability Translation infrastructure and Unicode-native storage are a real advantage for multi-region organizations.

Challenges and Limitations

A trustworthy evaluation of MediaWiki has to be equally clear about where it struggles.

Real technical investment is required. Unlike fully managed SaaS knowledge base tools, MediaWiki is server-based software that has to be installed, configured, secured, and kept updated - including a PHP runtime, a database server, a web server, and a backup strategy.

Access control is intentionally basic by default. MediaWiki's original design priority was open, collaborative editing of public content, not fine-grained content segregation. Out of the box, restricting which users can read specific pages - rather than just who can edit them - is more limited than in platforms purpose-built for permissioned enterprise content. Robust private-wiki behavior is achievable - for example, by setting $wgGroupPermissions['*']['read'] = false; in LocalSettings.php - but granular, page-by-page read restriction is not where MediaWiki's architecture is strongest, and organizations with complex compliance-driven access requirements should evaluate this carefully before committing.[5]

Wikitext has a learning curve. Although VisualEditor lowers the barrier for everyday editing, advanced formatting - nested templates, conditional logic, multi-column tables - often still requires direct wikitext editing.

High-traffic performance requires real infrastructure planning. A small departmental wiki can run on modest hosting; a high-traffic public wiki generally needs object caching (Memcached/Redis), a reverse proxy or CDN, and a properly tuned database.

Upgrade management takes discipline. Core, extensions, skin, and PHP version all need to stay compatible. MediaWiki's policy supports upgrading from up to two long-term-support releases behind current - skipping further than that can turn a routine upgrade into a remediation project.[6]

The default appearance reads as generic. Without custom skin work, an out-of-the-box installation visually resembles every other unmodified MediaWiki site.

Step-by-Step Guide: How a MediaWiki Site Comes Together

  1. Confirm system requirements - the current stable release requires PHP 8.2.0 or later, plus MariaDB 10.3.0+, MySQL 5.7.0+, SQLite 3.24.0+, or PostgreSQL 10.0+.[7]
  2. Provision the server environment - on-premises, VPS, or cloud, with the web server, PHP, and database installed.
  3. Download the appropriate release - current stable branch or the long-term-support (LTS) branch, depending on how much ongoing maintenance attention is available.
  4. Run the web-based installer - collects basic configuration and generates LocalSettings.php.
  5. Configure clean, short URLs - set this up before the wiki accumulates content and external links.
  6. Enable HTTPS - baseline security for any server-based application exposed to the internet.
  7. Choose and configure a skin - from a default skin like Vector 2022 to a fully custom, brand-matched build.
  8. Install and configure extensions - e.g. VisualEditor, Cite, CirrusSearch, selected based on actual content needs.
  9. Plan namespaces and user permissions - far easier before significant content exists than after.
  10. Establish a backup and maintenance routine - scheduled database/file backups and a defined update process.

Best Practices

  • Use the long-term-support (LTS) release branch for production wikis where stability matters more than having the newest features immediately.
  • Keep core, extensions, skins, and PHP version moving together during upgrades.
  • Test version upgrades in staging before applying them to production.
  • Subscribe to MediaWiki's official security announcement channel.
  • Define namespace structure and access permissions deliberately at the planning stage.
  • Match infrastructure investment to actual traffic and editing volume.
  • Invest a small amount of time in editor onboarding for VisualEditor and basic wikitext conventions.

Common Mistakes

  • Installing MediaWiki once and never updating it - the most common source of avoidable security risk.
  • Assuming the default configuration is automatically private; MediaWiki allows anonymous reading unless explicitly restricted.
  • Upgrading the core without first checking extension compatibility.
  • Going without a tested backup routine until something breaks.
  • Treating MediaWiki as a general-purpose CMS, blog, or forum platform.
  • Skipping clean URL configuration before launch, then changing the structure afterward.
  • Underestimating infrastructure requirements for a high-traffic public wiki.

Comparison With Alternatives

MediaWiki vs. Competing Wiki and Knowledge Base Platforms
Platform Licensing Model Hosting Best Suited For Notable Limitation
MediaWiki Free, open-source (GPLv2+) Self-hosted Large-scale, structured, or public-facing wikis; full data ownership Requires real technical/server maintenance; basic default access control
Atlassian Confluence Commercial, per-user licensing Cloud or self-hosted (Data Center) Teams standardized on the Atlassian ecosystem Licensing costs scale with editor/user count
DokuWiki Free, open-source (GPLv2) Self-hosted Small teams wanting a simple, database-free wiki Smaller extension ecosystem; limited scalability
Notion Freemium / commercial SaaS Cloud-only Small teams prioritizing flexible, visual editing No self-hosting option; more limited revision history
BookStack Free, open-source (MIT) Self-hosted Structured documentation in a book/chapter/page hierarchy No wikitext-style markup; smaller community
SharePoint Wiki Commercial (Microsoft 365) Cloud or on-premises Organizations already invested in Microsoft 365 Wiki is a secondary feature, not the core product focus

The practical takeaway is that MediaWiki tends to be the strongest fit when an organization wants full ownership of its data and infrastructure, anticipates a large number of editors, or needs a transparent, fully auditable revision history - and is willing to invest in proper technical setup and maintenance to get there.

Frequently Asked Questions

Is MediaWiki the same as Wikipedia?

No. MediaWiki is the underlying software; Wikipedia is one website built using that software. Thousands of other websites - corporate wikis, fan communities, government knowledge bases - also run on MediaWiki, completely independent of Wikipedia and Wikimedia.

Is MediaWiki free to use?

Yes. MediaWiki is distributed under the GNU General Public License version 2 (or later), meaning there's no license fee to download, install, modify, or run it. Organizations still incur real costs for hosting, server administration, and ongoing maintenance.

Can MediaWiki be made private, so only certain people can read it?

Yes, but it requires deliberate configuration. By default, MediaWiki permits anonymous reading. Setting read permissions to require login (commonly done by setting $wgGroupPermissions['*']['read'] = false; in LocalSettings.php) restricts the wiki to authenticated users.

Does MediaWiki require coding knowledge to use day-to-day?

Not for basic editing. The VisualEditor extension provides a WYSIWYG editing experience similar to a word processor. Wikitext knowledge becomes more relevant for advanced formatting and customization.

What's the difference between a MediaWiki skin and an extension?

A skin controls visual appearance - layout, colors, typography, navigation placement. An extension adds or changes functional behavior, such as enabling structured data, visual editing, or external authentication.

How often is MediaWiki updated?

New major releases ship roughly every six months, with one out of every four releases designated a long-term-support (LTS) version. Standard releases receive security support for about a year; LTS releases for about three years.

Is MediaWiki suitable for a small business with only a handful of employees?

It can be, particularly for a structured, searchable internal knowledge base with full revision history and no per-user licensing cost. Small organizations without in-house technical resources should weigh that against fully managed alternatives, or plan to work with an outside technical partner.

Conclusion

MediaWiki is, at its core, exactly what its name suggests: wiki software, originally built for Wikipedia, released freely to anyone who wants to run it. That origin gives it real, demonstrated strengths - proven scalability, a mature extension ecosystem, a strong revision history model, and zero licensing cost - alongside honest limitations, particularly around access control defaults and the technical commitment required to run it properly.

For organizations evaluating it, the right question generally isn't "is MediaWiki good?" in the abstract, but whether the use case matches what MediaWiki was actually built to do, and whether the technical capacity exists to run it well.

If MediaWiki looks like the right foundation but your team doesn't have in-house capacity to handle server setup, custom branding, content migration, or ongoing maintenance, that's the specific gap covered in detail on MediaWiki Development Services.

See Also

References

  1. MediaWiki.org, "Manual: What is MediaWiki?", https://www.mediawiki.org/wiki/Manual:What_is_MediaWiki
  2. MediaWiki.org, "MediaWiki history", https://www.mediawiki.org/wiki/MediaWiki_history
  3. MediaWiki.org, "Download", https://www.mediawiki.org/wiki/Download
  4. Wikipedia, "MediaWiki", https://en.wikipedia.org/wiki/MediaWiki
  5. Wikipedia, "MediaWiki", https://en.wikipedia.org/wiki/MediaWiki
  6. MediaWiki.org, "Version lifecycle", https://www.mediawiki.org/wiki/Version_lifecycle
  7. MediaWiki.org, "Manual: Installation requirements", https://www.mediawiki.org/wiki/Manual:Installation_requirements