Compatibility/en

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.

If you wish to suggest a change to what MediaWiki supports, you can file a request for comment on Phabricator.

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 requires PHP 7.2.9+.

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 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.
 * release branches (key: rel): For every MediaWiki release, there is a corresponding branch in the extension. So e.g. if you use MediaWiki, you should use the branch of the extension.
 * long-term support release branches (key: ltsrel): For every MediaWiki release, there is a corresponding branch in the extension, following the Version lifecycle release policy.

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#Background

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 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, or not supported at all.

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 or unsupported 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, which means HTTP, HTML, CSS and JS feature may or may not be compatible with these browsers, and may or may not be affected by measures (e.g. fallback CSS for newer CSS features) intended for Grade C browsers. In particular, JavaScript will be disabled if no support for features MediaWiki uses is found.

Browser support matrix
The principles and different grades described above apply to MediaWiki core and extensions alike. The support matrix below applies these grades in the context of MediaWiki core, Wikimedia Foundation infrastructure, and any MediaWiki extensions that decide to follow it. Individual extensions may have their own support matrix distributing browsers among the different levels of support. See also Browser usage breakdown dashboard.

(Last updated: May 2020)

Mobile
The Web team at the Wikimedia Foundation applies a narrower support matrix for mobile-specific skins e.g. and/or extensions designed only to run on mobile devices e.g.. The support matrix is compiled from the data provided by the analytics user agent breakdown dashboard. Where browser usage is over 5% a modern experience (Grade A) is supported. Basic support (Grade C) 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.

Grade A browser list on MobileFrontend is defined in .browserlistsrc file.

Anything absent in the list or older is considered a Grade C browser.