Should 7.4 be added to 1.42 and master in the grid/table in Compatibility#PHP? We're still testing CI on 7.4 and we're still running production on 7.4 in both 1.42 and master, correct?
Talk:Compatibility
PHP-7.4 is EOL software. As far as outside users are concerned, it seems reasonable that they should be dissuaded from using it. Note that 8.0 isn't in the support table either.
You can no longer install 1.42 without "hacking" the software since the installer will error out due to a compatibility warning. Let's get new users to start with PHP 8.1 or later. Mentioning PHP 7.4 here will confuse them.
I'm reopening this topic. Currently the table states the MW 1.42 does not work with PHP 7.4 or 8.0 - I tried changing this, but it was reverted as "lying". Which is strange, because (a) MW 1.42 does obviously work with these two PHP versions (including on this wiki), and (b) it was announced a few days ago that a "drop of support to PHP versions < 8.1" was one of the main changes in the upcoming MW 1.43. Which is a nonsensical statement if the official line is that PHP < 8.1 already was not supported.
I understand the desire to discourage people from using old PHP versions, but surely there's some way to do that without misinforming users?
Agreed we need some clarity especially if the WMF is still using PHP 7.4 for what is supposedly the alpha version of MW 1.43. If PHP 7.4 support needs to be “removed” from each successive major version, then by that logic the release notes also need to include the removal of Herobrine from MediaWiki 1.43.
@Tystnaden: , @Kghbln: , @Jdforrester: any thoughts?
I could only repeat what I already mentioned. Because of this, I would set 7.4 as not supported.
I didn't understand what you wrote before... you wrote, "You can no longer install 1.42 without "hacking" the software since the installer will error out due to a compatibility warning." Did you mean, install 1.42 on PHP < 8.1? Or on PHP < 8.0? For what it's worth, I am currently running MW 1.43.0-alpha with PHP 7.4 on my own wiki (downloaded not via the installer, just via a Git pull), and the upgrade went fine. What's the warning message users see? And what's the hack? Perhaps there should be some note above the graph to indicate this, but simply saying "not supported" is incorrect.
I am currently running MW 1.43.0-alpha with PHP 7.4 on my own wiki (downloaded not via the installer, just via a Git pull), and the upgrade went fine.
Yes, this is nothing to do with unreleased, unsupported software like the alphas, which temporarily still work with PHP 7.4 but aren't supported.
Fine, but the fact that MW 1.43-alpha works with PHP 7.4 surely means that MW 1.42 does as well; which was my main point.
No, it doesn’t mean that. Alpha versions and released versions are different; a commit included in released 1.42 but not in alpha versions explicitly makes MW refuse to work on PHP 7.4 and 8.0 (despite it being otherwise technically compatible with them). Reverting that commit is what Kghbln above called “‘hacking’ the software”.
Okay, thanks, that's very helpful. Now I think I understand the situation much better. It's strange that this change was made to MW 1.42 but not 1.43-alpha, so that, in a sense, PHP 7 compatibility went away and then came back again. It's also strange that this and the other Wikimedia sites are still running PHP 7.4; but maybe these two things are related. The fact that a drop of support for PHP < 8.1 was announced for MW 1.43 is actually a third strange thing, although it makes a little more sense in light of the previous information. (Presumably, a dropping of PHP < 8.1 support could keep getting announced for more MediaWiki versions in the future, especially if the Wikimedia sites keep resisting a PHP upgrade.)
Anyway, I think this resolves my questions. Tacsipacsi - thanks again!
It's strange that this change was made to MW 1.42 but not 1.43-alpha, so that, in a sense, PHP 7 compatibility went away and then came back again.
FYI, we did the same in dropping PHP 7.2, and later 7.3, support from release versions of MW ahead of Wikimedia production's migration.
Okay, that's also good to know.
It seems to me that this issue all boils down to confusion over the use of the terms "supported" versus "is compatible". I appreciate @Tacsipacsi for clarifying the true delineation between the use of these two terms. I also encourage that individuals refrain from using charged language such as "lying" without taking the time to assume good faith and understand why someone like @Yaron Koren is trying to clear this confusion up.
I'm surprised that there is an immediate cut-off in the more recent database transitions. It seems very onerous that there is not one version of MediaWiki which supports both old and new versions of a database. Cutting over will require at least more complex migration, and probably more downtime, especially for entities not resourced at the level of teh WMF.
@Rich Farmbrough Are you referring to MariaDB? Note that "MariaDB 10.1.0 " specifies a minimum version with the plus sign to mean "and later". This thus includes overlap to MariaDB 10.3.
Unlike PHP itself, MySQL and MariaDB follow semver, which means minor versions introduce new behaviours without changing or break existing contracts. As such, even MediaWIki versions that were released before MariaDB 10.3 existed, should be able to work on it, given we tested it with MariaDB 10.1. That's why we promise "and later", because we tested it with MariaDB 10.1, and upstream MariaDB follows semver.
Later MediaWiki versions may start to assume and depend on those newer behaviours, at which point we raise the minimum requirement.
If MariaDB did not follow semver, and if our past versions could only promise support for MariaDB 10.1.x exactly, then we'd indeed need to "introduce" support for MariaDB 10.3.x at some point and leave overlap. I hope this explains why that is not the case / not needed.
Thanks, the full implications (and indeed meaning) of the sign were lost on me. It's not clear that it applies to the last two components, rather than just one or the whole thing. Rich Farmbrough 14:43, 15 October 2024 (UTC).
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.
See also {{Compatibility core tables}}.
{{Version history}} already has a parameter called "order." Would "order=descending" be helpful for resolving this?
Done by adding order=descending
We could also potentially change the overflow: auto into overflow: visible (or remove it entirely?) which lets the table break out of the limited width?
(I might be overlooking some drawbacks of doing that? But by default, wide tables can overflow on large screens, e.g. w:List of 32X games, which I advocated for and really appreciate about Vector2022 supporting! Especially on pages like this, as multiple horizontal scrollbars on a single page are an accessibility anti-pattern.) Hope that helps.
By changing overflow: auto to overflow: visible in {{Compatibility core tables}}, the right sidebar becomes invisible. Is that okay?
Personally, I think it's probably fine, because the Tools menu can easily be toggled to 'collapsed', briefly, if it ever presents a problem to anyone. (And because accessible access to the page-content is the priority)
I don't like the backwards chart, but I guess RRDTool has a strong influence.
The message says PHP 8.0 are supported but the table currently does not list 8.2. I assume the table should be updated?
You don't mention what version of MediaWiki you are running, but the release announcement for MediaWiki 1.35.10, 1.38.6 and 1.39.3 goes into some detail about this. In summary, PHP 8.0 and 8.1 should work without major issues, though support for 8.2 is less mature.
See https://lists.wikimedia.org/hyperkitty/list/[email protected]/thread/6UQBHI5FWLATD7QO7DI4YS54U7XSSLAN/ for the release announcement.
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.
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?
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.