MediaWiki: the PHP wiki engine that runs Wikipedia itself

A mirror, and why that changes how you contribute

The repository description carries a sunflower emoji, calls the project the collaborative editing software that runs Wikipedia, and then says the important part: mirror from `https://gerrit.wikimedia.org/g/mediawiki/core`, with a pointer to the developer access page for contributing.

That single line reframes the whole repository. This is not where MediaWiki development happens; it is a read-oriented copy of a Gerrit repository, and the description says as much with a link to mediawiki.org's developer access documentation. Pull requests opened here are not the contribution path the project expects.

What GitHub does show is a working mirror: the last push was 2026-09-22, the repository is not archived, and the tree is a complete PHP application rather than a stub. `index.php`, `api.php`, `rest.php`, `load.php`, `thumb.php`, `opensearch_desc.php` and `img_auth.php` sit at the top level next to directories including `includes/`, `languages/`, `resources/`, `skins/`, `extensions/`, `maintenance/`, `sql/`, `tests/`, `cache/` and `docs/`. That is the shape of the software: entry points at the root, the implementation under `includes/`.

GitHub also reports an open issue count of zero, which is another way of saying the issue tracker here is not the one to use. Bugs go to bugs.mediawiki.org, as the README says.

The README is a directory, not a manual

The README describes MediaWiki as free and open-source wiki software written in PHP, the platform for Wikipedia and the other Wikimedia projects, used by hundreds of millions of people each month, and localised in over 350 languages. Then it lists four properties: feature-rich and extensible both on-wiki and with hundreds of extensions, scalable and suitable for both small and large sites, simple to install and working on most hardware and software combinations, and available in your language.

What follows is a set of links, and the links are the point. For system requirements, installation and upgrade details, the README points at three files in the repository root: RELEASE-NOTES, INSTALL and UPGRADE. Then there is a download link, a local development quickstart link, a link to the technical manual, a link for human help, a link to the bug tracker, and a link for contributors.

None of that is an evasion. A project whose documentation is localised into over 350 languages cannot keep a manual in one README file, and the files it points at are the real documentation. But it does mean you should treat the README as proof of what the project values rather than as instructions. If you are evaluating MediaWiki for a first-time install, the INSTALL file is where your questions get answered, and it will take longer than a getting-started guide would.

Extensions, skins and the thing that makes MediaWiki heavy

The tree contains `extensions/` and `skins/` as first-class directories, and the README refers to hundreds of extensions. That number is the honest headline about MediaWiki: the core is not extensible through configuration so much as it is extensible by installing PHP that hooks into documented extension points.

The trade is real. What you gain is the exact mechanism that has let Wikipedia run the same software through 350 languages, multiple text directions, a dozen visual skins and years of accumulated special pages without a rewrite. What you pay is a codebase where the interesting behaviour frequently lives outside the core, in an extension, and where understanding a site means understanding which extensions are installed.

For a reader choosing software, that distinction separates MediaWiki from most wiki packages. A smaller wiki engine ships its features in the box and you configure them. MediaWiki ships the engine, a namespace and skin system, and an extension registry, and the ecosystem fills the rest. If you need a specific feature and it exists as an extension, the cost of adopting is low. If you need a feature nobody has written, you are writing PHP against MediaWiki's APIs, which is a much larger commitment than writing a plugin for a small engine.

Running it locally with the bundled compose file

There is a `docker-compose.yml` at the root, and its header comment is unusually candid about intent. It says contributions are welcome but that the file is minimal by design, with the idea that it can be extended through `docker-compose.override.yml`.

The file defines three services: `mediawiki` on a Wikimedia PHP-FPM image, `mediawiki-web` on a Wikimedia Apache image publishing port 8080, and `mediawiki-jobrunner`. Each mounts the working tree at `/var/www/html/w` and reads a `.env` file. The first service's environment block is where the interesting defaults live:

MW_SCRIPT_PATH: '/w'
MW_DBPATH: '/var/www/html/w/cache/sqlite'
MW_DBTYPE: 'sqlite'
MW_LANG: 'en'
MW_SITENAME: 'MediaWiki'

So the default development setup runs against SQLite with a cache directory for the database, not a production MySQL server. The port is overridable through `MW_DOCKER_PORT` and the default user credentials are set through `MEDIAWIKI_USER` and `MEDIAWIKI_PASSWORD`, both with defaults in the file.

This is a development environment, and the file says so. For anything resembling production, the INSTALL and UPGRADE files are the documents to read.

Two toolchains, because this is a PHP project with a JavaScript front end

There is a `composer.json` and a `package.json` in the same root, which tells you most of what you need to know about modern MediaWiki development. PHP dependencies come through Composer, and the JavaScript toolchain is Node based with Grunt, ESLint, Stylelint, Jest and Karma configured.

The `package.json` scripts are a decent map of how the project tests itself:

"test": "grunt lint && npm run doc && npm run jest",
"qunit": "grunt qunit",
"api-testing": "mocha --timeout 0 --recursive --parallel tests/api-testing",
"jest": "jest --config tests/jest/jest.config.js"

QUnit through Karma is the browser-side suite, Jest handles newer JavaScript tests, Mocha drives API tests with no timeout, and ESLint plus Stylelint run under Grunt as the lint step. There is also a Selenium script for browser-driven tests in the same scripts block.

None of this is documented in the README beyond a link to the local development quickstart. If you plan to contribute rather than deploy, that quickstart and DEVELOPERS.md are the two files that will save you the most time, and both are in the repository.

Licensing, where the answer is GPL version 2 or later

The README states that the COPYING file explains MediaWiki's copyright and license, naming the GNU General Public License version 2 or later. That is the fact to plan around. GPL v2 or later lets you choose GPL v3 for your own work, but it is still a copyleft license: modifications to MediaWiki itself, when you distribute them, carry obligations.

For most deployments this is a non-issue. Running the software as a service, or using an unmodified install internally, does not require you to publish anything. It becomes a question when you modify core, when you distribute a modified MediaWiki, and when you decide how to license an extension, which is a separate work under a licence you choose.

There is a small metadata inconsistency to note. GitHub reports no license value for the repository, while the README names the license and a COPYING file sits at the root. The README and the file are the reliable sources; the empty metadata field tells you nothing either way.

For a second opinion on your specific situation, a copyright lawyer beats a wiki article, including this one.

Editorial conclusion

MediaWiki is the sensible default when a wiki has to keep working for years, be translated into dozens of languages, and tolerate a decade of extensions without a rewrite, which is the situation Wikipedia found itself in and most internal wikis eventually do too. It is the wrong choice when you want a small, understandable codebase, since the extension system and job queue assume an operations team. Start with the download link in the README and the bundled docker-compose file for a local instance, check the license terms in COPYING before you rely on it commercially, and read UPGRADE before touching a production one.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. wikimedia/mediawiki on GitHub