What do the red and blue colours mean?
For example, PHP 7.4 is in blue, but is EOL upstream - https://www.php.net/supported-versions.php
Does that make it red?
Talk:Compatibility
I believe blue means that it is supported in master, i.e. the right-most column.
The (very deeply nested) template also hardcodes this in so far that it renders all cells as red, except the last one in a given row, which is always blue.
Having said that, I wouldn't remind us removing the colours and making the page a bit calmer over all. Most every cell and paragraph is competing for attention at the moment. "When everything is marked as important, nothing is."
Is 8.0 support planned for the last minute?
Yes. See the great big notice:
MediaWiki is not compatible with PHP 8 yet. See task T248925 for more information.
MW 1.38.2 works with PHP 8.1.9, so the fact that MW is not compatible with it yet is not true, Haven't tested with 1.38.1 or older versions, but you can check on your own.
AFAIK it has no problems, I run it on PHP 8.1.9 and I don't seem to find any errors or warnings.
I disagree. My testwiki had a lot of problems when run using PHP 8.1.7. I doubt that those problems were fixed in PHP 8.1.9, it will require changes to the MediaWiki software, which is being worked on.
Several wikis are known to be using various versions of PHP 8; if you're willing to experience (and potentially have to work around) some issues you can use it. It's just not yet officially supported (see Phab workboards for PHP 8.0, PHP 8.1, and PHP 8.2 support).
Yes, I had to go in and hack a bunch of the MediaWiki code to get it to run reasonably, and it still had more problems. I went back to running it under PHP 7.4.
I use unmodified MediaWiki code under PHP 8.1.9 and I seem to be having no problems.
I do not know how you are avoiding these code paths, but there are numerous PHP library functions in PHP 8+ for which passing a null value is deprecated, and which emit a diagnostic in that case.
@Tystnaden: About deprecation warnings, I would consider those as agreeing with "having no problems". I believe most site operators never consult server logs, or only do so after a user-facing failure is found. These logs are often configured to hide deprecation warnings and other non-fatal errors. A deprecation warning generally means that an incompatibility will happen in the future instead of now, e.g. MW would be incompatible with PHP 9 if we don't address the warnings before then.
PHP 8.0-8.1 is advertised as a minor release, thus not (generally) breaking compatibility with web applications. Apart from documented edge cases, MW is likely compatible with PHP 8.1 if it is compatible with 8.0, unless MediaWiki relies on unofficial behaviours.
(I don't rule out that there could be unofficial behaviours, and I am not claiming here that we compatible with PHP 8.0 yet.)
@Krinkle: Yes, I understand what deprecation warnings mean. However, I did learn something here. The php setting 'display_errors' was defaulting to on. So, I turned it off in the php-fpm pool settings, and no more deprecation warnings. I also turned on 'log_errors', and I'll see what pops up in the log.
One other thing: apparently, PHP 8 changed the default value of 'error_reporting' from 'E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED' to 'E_ALL'.
Note that although there have been several changes landed towards 1.38.3 since 1.38.2 was released, I don't think we've declared it guaranteed to be fully working with PHP 8.0 yet, let alone 8.1, sorry.
@Jdforrester (WMF): Yes, I understand that it is not certified yet, but ArchLinux is running MW 1.38.2 using PHP 8.1 in production. Bleeding edge :) https://wiki.archlinux.org/title/Special:Version
Thanks.
This is an attempt to clarify the support definition of “Modern”, “Basic” and “Unknown” in front-end technology terms outside of the technical infrastructure access:
On JavaScript
Modern: Everything works as fleshed out in product design (and features take advantage of browser's full capabilities)
Basic: Some features might or might not work, but basic functionality is given, and enhanced functionality degrades gracefully. Examples are basic editing or search.
Unknown: Some browsers might get full features, some not, some even break badly.
On CSS
Modern: Full layout & design features
Basic: Full layout features, we use same CSS, as it might otherwise negatively affect degraded JS functionality. We go through hoops and use Basic as CSS level for our designs incl Modern.
Unknown: Not cared about. Given we're only using semantic HTML basic readability is ensured (only exceptions are browser bugs)
This is wrong, isn't it?
"Basic" for JS means "We intentionally don't ship you any JS because we don't want to break your browser".
"Unknown" for JS means "We ship you JS, who knows, it might work, good luck".
Actually “Unknown” for JS means “We may or may not ship JS; if we do, it’s mostly okay, but we don’t guarantee it doesn’t break terribly, good luck.” Ancient browsers that are not even “basic” usually don’t get JS due to the feature test. “Unknown” browsers that do get JS are probably mainly relatively recent forks of “modern” browsers or chromes over their engines (SeaMonkey, Vivaldi, Samsung Internet, Tor Browser etc.), which should mainly work.
Indeed.
As a note, incorporating Vue 3 also removes grade A compatibility for Safari < 10 (Safari 9.1) and Android 4.X lines, for the same reasons that IE 11 is not supported (lack of support for Proxy, if I am reading MDN correctly). Compatibility#Special treatment for IE11 could perhaps be adjusted, or perhaps both should be a note for Template:Compatibility browser instead of a section-proper. (Or perhaps its own row, "Browsers without Vue 3".)
The only reason I bumped into this is that some of us on Discord were throwing around sending VisualEditor to clients as WebAssembly, which has very similar Modern requirements according to CanIUse: it would require WMF to drop Modern support for Safari 9, Safari 10, and Android 4.X, which are almost the same requirements for Vue 3.
The eventual dropping of IE11 is essentially a more explainable version of the technical requirement for ES6, likely a year from now. See T178356#6632565 and startup.js isES6Supported for details on what that exactly would entail. There hasn't been a decision yet and the exact definition of "ES6 in practice" is still relativaly vague since some parts of the ES6 specification are still not implemented today even in the latest versions of Firefox and Chrome, despite ES6 (aka ES-2015) now being five years old and ES-2020 spec features having already been released in most browsers.
Having said that, it looks like Safari 9-10 and Android 4 indeed might end up on the side of Grade C, depending on what subset of ES6 we are going to check for and require.
Raising Safari Grade A support to 10.1/10.3 and dropping Android 4.x would also have the nice side effect of making CSS Grid Layout permissible to use without too much fiddling with fallbacks. Given the numbers are so low (<0.1% and 0.22%) it might even be worthwhile upping the requirement independently of ES6 and Vue 3.
@Xover That's right, we tackle these separately in “Basic” browser support. CSS standards are mostly aimed at in basic support (I just stumbled upon this discussion). See for example https://phabricator.wikimedia.org/T290815
Could this page have a note about which skins are officially supported by WMF devs? Something like the ===Browser support matrix===, only more like ==List of WMF supported skins==.
AIUI the list is Vector 2010, Vector 2022, and Minerva Neue (most relevantly, not MonoBook and not Timeless).
This information is sometimes documented on the MediaWiki.org pages about the individual skins, but a central list might be helpful for people who are trying to find the whole list without having to go read every page separately to see what (if anything) each separate page says about each skin.
The list of software components that the foundation maintains is on the Maintainers page.
I'm hestitant about adding it here, as I think "support" in the context of the Compatibility page means something else than the sense of "software that is supported", and rather means what the supported software in turn supports externally (e.g. given that the Vector skin is maintained/supported, what browsers and PHP versions does it in turn support?). However a pointer from here to Maintainers may be helpful to have a path for when others may be looking for the same thing here.
As a general rule of thumb, I would say all software that is in production is and must be supported and maintained. However, it is not owned or stewarded by a specific team at WMF, and indeed not always in active development with new capabilities. MonoBook can be described as being in maintenance-only mode. However I would expect it to accomodate for changes that happen in browsers and other parts of MW to remain compatible, just as we do for any other skin.
For some software the lead maintainer can indeed be a group or individual outside the foundation, as is the case with Wikibase/Wikidata, and Timeless.
Dev/Maint in turn links to Wikimedia Product/Component responsibility#Skins which is IMO a little clearer, although it's somewhat incomplete. But that's probably enough, if someone needs a list. Thank you for pointing me in that direction.
Would it be possible to add a MariaDB version support table like the one for MySQL? It's quite difficult to figure out how to "map" the MySQL versioning info to something in MariaDB.
Thanks, I think this is a good idea. I've tracked it on Phabricator at T299447 for my team to write/review, but feel free to edit the page and get started on it if you want.
According to Wikitech, iOS9 is being taken out of commission by the Internet (Let's Encrypt root expiry). Should the compatibility table be updated? There may be other benefits according to Caniuse.
This page documents compatibility of the MediaWiki core software, not the Wikimedia Foundation deployment and infrastructure as used for Wikipedia. There are hunderds of software packages and services that make up the Foundation's infrastructure. The subset of all those make up what Wikipedia offers in total, and what it requires at minimum. That is not documented on this page. For the specific aspect of HTTPS requirements, that is documented on Wikitech indeed.
MediaWiki can be used with any web server and (if using HTTPS) any certificate authoritity. It does not have to be Let's Encrypt.
Having said that, there are plans to remove iOS 9 support for MediaWiki's additive "Modern" JS-based features over the near year, as part of T178356. The exact iOS version to require for our subset of ES2015 features is still to be determined, but there is consensus that it will include at least "Promise" and "Promise-finally" which would require iOS 11.
Supported by who? Us? Their relevant upstream?
We should clarify and put upstream/vendor supported into the text
If it is indeed that case (it looks to be by the PHP versions), the MySQL versions need updating.
MySQL 5.5 is no longer supported by Oracle. 5.6 is in Extended Support until Feb 2021.
Similarly, for PG, only 9.5+ is supported upstream - https://www.postgresql.org/support/versioning/
And at some point... Maybe we should be bumping the supported versions inside MW too...
I'm sure we have some version related hacks around...
It's also not accessible to communicate information only through color, which is also currently happening here.
I don't know what it originally meant, but the way it is used today on this page, I think the color is just as extra helper to guide eyes toward rows that continue through to the latest MW release.
E.g. any bars that only apply to previous MW releases are marked yellow, and the first ones that are still current are marked in blue.
I've removed the sentence since it does not communicate any new information and doesn't warrant a legend I think.
I'm curious. The Compatibility#Browser support matrix says "Current and previous version". Does it mean the last two versions (one current, other previous) of Chrome, Firefox, Opera, and Edge? If not, then what else does it mean?
It does, yes.
That means Chrome on Windows 7 (discussed at Topic:Vez28sl17aww4qzz) will run a "Grade C" matrix when Google will stop supporting the browser on Windows 7, right?
No. They'll get Grade X support.
(You're right, it was confusing; does my clarification help?)
So which versions of Chrome will receive the Grade C support?
The current and immediately former release versions. As of today, that's 79 and 78.
Once Chrome abandons Windows 7 (which went EOL years ago and EOS this week), it'll not get release versions, and so will fall into Grade X.
At that point, the only Grade A browser on Windows 7 will be Internet Explorer 11, which I imagine we'll be dropping quite soon, and then there'll be none.
the task (phab:T269504) that I filed about Windows 7 was closed as "invalid". I thought long hard about the compatibility of browsers in Windows 7, but I don't know where else to (re-)start. I don't want to migrate to another OS yet just to receive further support for browsers. But I'm still troubled by the page's not mentioning "operating system". The fact that Chrome and other browsers on Win 7 were downgraded from Grade A to Grade C (except IE11, still Grade A to this date) without any other kind of mention when Microsoft's support for Win7 ended still irks me. Must I create a task demanding extension of basic support for soon-to-be older final versions of browsers in unsupported OSes, or what else shall I do?
You can ask for it. I don't think the teams responsible will say yes. Windows 7 is really, really not OK to encourage people to use, and I think it would be a very poor use of donor funds to work to make it easier to do something so risky.
All right. Have you already scheduled end of support for browsers on Windows 7? If not, shall I create a such task on Phab, or is that unnecessary? That would attract remaining Win7 users wanting to stick with it, wouldn't it?
We don't support operating systems. We support browsers, based on features, encryption availability, and likelihood of security issues being fixed. I'm not sure what solution you're driving towards?
All right. I'll drop the OS matter for now. I'll stick to browsers and report issues with the browser in the future then.
Were you confusing Grade C with Grade A? If not, what about what the table says about browsers using different matrices?
Were you confusing Grade C with Grade A?
No, I was not.
If not, what about what the table says about browsers using different matrices?
I'm sorry, I don't understand?
I'll clarify: The table chart at Compatibility#Desktop lists "Modern" (Grade A), "Basic" (Grade C), and "Unknown" (Grade X) in rows. The way you answered makes the chart not as accurate as seen there unless I misinterpret what the chart actually says. Or for what does the chart intend?
If you don't spell out what you're interpreting it to mean, I can't tell you whether you're misinterpreting it.
"Grade A" is real, tested JS support.
"Grade X" is probable, untested JS functionality, which is unsupported.
"Grade C" is known-broken-with-JS-so-we-don't-try.
I'll put this another way.
"Modern" row lists "Current and previous version[s]" of Chrome, Edge, Firefox, and Opera. Then it lists IE11+, Safari 5.1+, iOS 6.1+, and Android 4.1+. Do those versions correctly belong to that row?
"Basic" row lists Chrome 1+, Firefox 3.0+, Opera 15.0+, Edge 12+, IE8+, Safari 3.0+, iOS 5.0+, and Android 2.0+. Is this listing correct?
"Modern" row lists "Current and previous version[s]" of Chrome, Edge, Firefox, and Opera. Then it lists IE11+, Safari 5.1+, iOS 6.1+, and Android 4.1+. Do those versions correctly belong to that row?
Yes. (Though in practice users of Android 4.3 and below can't access Wikimedia properties any more because of SSL issues.)
"Basic" row lists Chrome 1+, Firefox 3.0+, Opera 15.0+, Edge 12+, IE8+, Safari 3.0+, iOS 5.0+, and Android 2.0+. Is this listing correct?
Yes. (Though again, the SSL issue arises.)
Please see also https://phabricator.wikimedia.org/T258993