Compatibility

MediaWiki strives to maintain broad compatibility between versions, and with a range of current and legacy software. At the same time, the constantly-evolving codebase and features of the latest MediaWiki development mean that it is not possible to maintain compatibility with legacy software indefinitely.

Server software
This sections provides an overview of the software required on the server to run MediaWiki.

PHP
The latest stable branch of MediaWiki () runs on any version of PHP  to PHP 7.3.

MediaWiki 1.34 will require PHP 7.2+.

PHP 7.3 support is available in MediaWiki 1.31 and newer.

Database
MediaWiki is compatible with a variety of database servers. Using MySQL or MariaDB is recommended.

Using any other database software is not recommended for production use. Support differs from MediaWiki version to MediaWiki version and ranges from dubious to stable.

MediaWiki provides database abstraction layers for PostgreSQL and SQLite, which are generally well-maintained.

Web server
MediaWiki is broadly compatible with all major web servers that can invoke a compatible version of PHP.

Apache is the most used and tested.

Nginx is a good choice as well.

MediaWiki extensions
As long as an man>Special:MyLanguage/Manual:Extensions|extension is properly maintained (which you can see at the top of the infobox on its description page), the master branch of the extension should be compatible with the master branch of MediaWiki.

For determining compatibility with older MediaWiki versions, there are two common policies used by extensions:


 * master (key: master): the master branch of the extension is compatible with both current and older versions of MediaWiki. Back-compatibility hacks are added to the extension source code as needed.

So e.g. if you use MediaWiki, you should use the branch of the extension.
 * release branches (key: rel): For every 1>Special:MyLanguage/Release notes|MediaWiki release, there is a corresponding branch in the extension.

The  field of the Extension infobox tells which policy is used by a given extension. Use the respective keys indicated above to specify the information.

Some extensions may have more specific compatibility policies, for instance:
 * MediaWiki Language Extension Bundle

General information
There is an ever-growing number of different web browsers in the world.

Too many to actively test and support each one.

To guide our practices around browser support, we have three levels of support.

Each tier represents a different category of browsers.

Modern (Grade A)
This group (also known as Grade A) represents the highest level of support. Features take advantage of capabilities in modern browsers, while allowing a graceful fallback for older browsers. All features provided by the software (whether or not in a degraded form) must work in these browsers.

Browsers in this category are known (listed below) and actively tested against. Problems users perceive in these browsers are addressed with high priority.

Basic (Grade C)
The group (also known as Grade C) is provided the core functionality of the MediaWiki platform. Our HTTP responses are compatible with these browsers (e.g. HTTP features we rely on, character encoding, and image formats used by the content; must work in these browsers). In the front-end this means content is presented in a readable manner, and to some extent user actions can be performed, but these browsers do not get JavaScript features.

Browsers in this category are known (listed below) and identified via [https://github.com/wikimedia/mediawiki/blob/2aed14b686/resources/src/startup/startup.js#L10 a feature test suite and a blacklist] in the startup module.

Unknown (Grade X)
This group (also known as Grade X) represents all other browsers. This includes browsers that are no longer developed or browsers not popular enough to justify the added maintenance cost for software development.

Browsers not included in any other group belong to this category.

Problems users perceive in these browsers only are given low priority.

MediaWiki handles these browsers the same as Modern (Grade A) browsers and they are thus assumed to be capable. This principle provides various important benefits:
 * New versions of modern browsers may temporarily be considered Unknown if they are not yet tested against by us. Treating Unknown browsers as capable ensures optimal user experience in these browsers.
 * Users of new and evolving browsers are given a chance to have a modern experience.
 * Users of less popular browsers based on, or derived from, known modern browsers are not negatively impacted (e.g. Iceweasel).

In practice the only difference between Unknown and Modern browsers is that we don't actively test against Unknown browsers.

These browsers are given the full feature set.

However, no JavaScript support is provided if basic JavaScript functionality required for modern run-time is unavailable.

Desktop
(Last table>Template:Compatibility browser|updated: October 2019)

While the principles and different grades described above apply to MediaWiki core and extensions alike, the below browser support matrix applies to MediaWiki core only (and extensions that decide to follow it). Individual extensions may have their own support matrix distributing browsers among the different levels of support. See also analytics user agent breakdown dashboard for desktop.

Mobile
(Last table2>Template:Compatibility browser/mobile|updated: March 2017)

The Web team at the Wikimedia Foundation uses a different support matrix for mobile-specific skins e.g. Minerva skin and/or extensions designed to run on mobile devices e.g. MobileFrontend.

The support matrix is compiled from the data provided by the [https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-os/os-family-and-major-tabular-view analytics user agent breakdown dashboard].

Where browser usage is over 5% a modern experience is supported.

Basic support is provided for anything over 0.1% over the 12 months.

In mobile we strive to provide a Grade B. Users of grade B may or may not get JavaScript and we do not test to the same level as A, thus we prioritize bug fixes lower.