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.

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

Server software
These sections provide an overview of the software required on the server to run MediaWiki.

PHP
The latest stable branch of MediaWiki runs on PHP  and higher.

For upcoming versions, see.

HHVM support was dropped in MediaWiki 1.34. You are strongly advised against using it.

Wikimedia production servers and continuous integration currently run PHP 7.4, with plans to upgrade to PHP 8.1 soon. MediaWiki developers are encouraged to develop using PHP 8.1, and the MediaWiki Docker image uses PHP 8.1.

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 and skins
As long as an extension or skin is properly maintained, the master branch of the extension or skin should be compatible with the master branch of MediaWiki. For determining compatibility with older MediaWiki versions, there are the following common policies used by extensions and skins:


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


 * release branches (key: rel): For every MediaWiki release, there is a corresponding branch in the extension or skin. So e.g. if you use MediaWiki , you should use the  branch of the extension or skin.


 * long-term support release branches (key: ltsrel): For every MediaWiki release that is a Long Term Support release (see Version lifecycle release policy) there is a corresponding branch in the extension or skin. So e.g. if you use MediaWiki , you should use the  branch of the extension.  If you use a non-LTS version of MediaWiki, usually you will need to use the extension's or skin's branch for the previous LTS version.  For instance, MediaWiki 1.34 wikis using a ltsrel extension or skin would usually use the REL1_31 branch of that extension or skin.  However, there is no guarantee of compatibility.

The compatibility policy field of the 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
Every web page starts in Basic mode, where only the HTML is rendered. CSS can be assumed to succeed for visual readers and should be used for presentation. The Modern layer defines optional enhancements and interactions written in client-side JavaScript. This layer may fail to load, arrive later, or not at all; including in modern browsers. This depends on various circumstances. To learn more, refer to MediaWiki Engineering guidelines.

The JavaScript requirements for the "Modern" layer are implemented via [ https://github.com/wikimedia/mediawiki/blob/c3ba4ee4045ece1ccbd9f3b5b39317b63be7c36d/resources/src/startup/startup.js#L9 a feature test] in the startup module, inspired by the "[ https://responsivenews.tumblr.com/post/18948466399/cutting-the-mustard cutting the mustard]" approach.

There is an ever-growing number of different web browsers and browser-capable devices in the world. Too many to actively test and support each one. To guide our practices around browser support, we define three grades of support. Each grade represents a different category of browsers.

In practice the only difference between browser grades is our investment in testing and support. All browsers receive the same server responses, and will try to load the Modern layer if it passes the required JavaScript capabilities.

Grade A
Grade A browsers receive the highest level of support. MediaWiki takes advantage of capabilities in modern browsers, while allowing a graceful fallback for older browsers. New features developed must work in these browsers (whether or not in a degraded form).

Browsers in this category are known (listed below), actively tested against, and meet the requirements for the "Modern" layer. Problems users perceive in these browsers are addressed with high priority.

Grade C
Grade C browsers must receive 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 content and account actions can be performed, but JavaScript features may or may not work.

Browsers in this category are known (listed below), and are rarely tested against. Problems users perceive in these browsers are addressed with high priority. However, mitigation may focus on ensuring that available functionality is not broken; if acceptable from a product perspective, this may result in the affected enhancement being disabled (whether or not temporarily) rather than restored in these browsers.

Grade X
All other browsers are referred to as "Grade X".

MediaWiki handles these browsers the same as Grade A and Grade C browsers: there is no user agent filter, and these browsers receive JavaScript enhancements if they pass the feature test for the "Modern" layer.

Browsers not included in any other group belong to this category, including:


 * Less popular browsers that are based on, or derived from, known modern browsers (e.g. Samsung Internet, UC Browser, Vivaldi, and Iceweasel).
 * Beta versions of modern browsers. These are considered Grade X if they are not yet tested against by us. Treating these as capable ensures optimal user experience in these browsers, and facilitates upstream testing.
 * Browsers or browser versions that are no longer developed or maintained, and incompatible with modern Internet standards. These might receive the "Basic" mode, or might be unable to even connect to the web server.

This principle means users of new and evolving browsers are given a chance to have a modern experience.

These browsers are not common enough to justify the added maintenance cost for software development and are essentially never tested. Problems users perceive in these browsers only are given low priority.

Desktop
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 [ https://analytics.wikimedia.org/dashboards/browsers/ Browser usage breakdown dashboard].

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 [ https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-os/os-family-and-major-hierarchical-view 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% during the previous 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 prioritise bug fixes lower. Modern support browser list on MobileFrontend is defined in file.

Anything absent in the list or older is considered a basic supported browser.