Talk:Compatibility

About this board

Limited Width Obfuscates Charts

3
Z929669 (talkcontribs)

I was having a hard time interpreting the charts, because of the Vector 22 default skin with Preferences > Appearance > Skin preferences > Enable limited width mode toggled 'on' (also default). I'm on a desktop PC using Waterfox, but Chrome yields the same result as an anonymous user.

The version numbering is right aligned, and the blue bars look blank if this setting is not toggled 'off'.

Probably the simplest fix would be to modify Template:Compatibility PHP and Template:Compatibility DB (or possibly Template:Version history) to conform to the limited threshold.

Shirayuki (talkcontribs)

See also {{Compatibility core tables}}.

{{Version history}} already has a parameter called "order." Would "order=descending" be helpful for resolving this?

Shirayuki (talkcontribs)

Yes Done by adding order=descending

Reply to "Limited Width Obfuscates Charts"
Izno (talkcontribs)

The message says PHP 8.0+ are supported but the table currently does not list 8.2. I assume the table should be updated?

Tystnaden (talkcontribs)
Izno (talkcontribs)

I did not mention it because I am not running it. :)

The specific question was asked because the documentation is apparently inconsistent. Either MW supports 8.0+ and so the table should be amended, or it doesn't and the note should be just a bit more specific about the expected level of support for 8.2. Based on the documentation I've seen, including the 1.39 patch notes, 8.2 is actively supported, so that's why one might expect the table to include 8.2 rather than the note be adjusted.

Reply to "PHP 8.2"
Reedy (talkcontribs)
Krinkle (talkcontribs)

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."

Reply to "Colours"

PHP 7.4 is nearing end of life

2
2001:7D0:847D:8380:BD5F:EE63:6DBA:C3DD (talkcontribs)

Is 8.0 support planned for the last minute?

Jdforrester (WMF) (talkcontribs)

Yes. See the great big notice:

MediaWiki is not compatible with PHP 8 yet. See task T248925 for more information.

Reply to "PHP 7.4 is nearing end of life"

PHP 8.1 and MW 1.38.2

11
HolyNetworkAdapter (talkcontribs)

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.

HolyNetworkAdapter (talkcontribs)

AFAIK it has no problems, I run it on PHP 8.1.9 and I don't seem to find any errors or warnings.

Tystnaden (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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).

Tystnaden (talkcontribs)

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.

HolyNetworkAdapter (talkcontribs)

I use unmodified MediaWiki code under PHP 8.1.9 and I seem to be having no problems.

Tystnaden (talkcontribs)

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.

Krinkle (talkcontribs)

@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.)

Tystnaden (talkcontribs)

@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'.

Jdforrester (WMF) (talkcontribs)
Tystnaden (talkcontribs)
Reply to "PHP 8.1 and MW 1.38.2"

Definition of “Modern”, “Basic” and “Unknown” support in front-end

4
Volker E. (WMF) (talkcontribs)

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)

Jdforrester (WMF) (talkcontribs)

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".

Tacsipacsi (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

Indeed.

Reply to "Definition of “Modern”, “Basic” and “Unknown” support in front-end"

Regarding Vue 3 and not-IE11

5
Izno (talkcontribs)

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".)

Izno (talkcontribs)

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.

Krinkle (talkcontribs)

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.

Xover (talkcontribs)

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.

Volker E. (WMF) (talkcontribs)
Reply to "Regarding Vue 3 and not-IE11"

WMF support for skins

3
Whatamidoing (WMF) (talkcontribs)

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.

Krinkle (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)
Reply to "WMF support for skins"

MariaDB version support

2
152.2.172.26 (talkcontribs)

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.

Krinkle (talkcontribs)

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.

Reply to "MariaDB version support"
IznoPublic (talkcontribs)
Krinkle (talkcontribs)

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.

Reply to "iOS 9"