Jump to navigation Jump to search

About this board

PHP compatibility for 1.32 - shall I believe table or text?

Varnav (talkcontribs)

According to table 1.31 and 1.32 supports PHP 7.2.x only. According to text: "The latest stable branch of MediaWiki (1.32) runs on any version of PHP 7.0.13 to PHP 7.2."

Shall I believe table or text?

星耀晨曦 (talkcontribs)

The table is actually saying that 1.31, 1.32 and the master branch support PHP 7.0, 7.1 and 7.2 at the same time.

ChristianSirolli (talkcontribs)

Is PHP 7.2.0 compatible with MediaWiki? That is the current stable version of PHP (as of 1/1/2018).

星耀晨曦 (talkcontribs)

Currently, MW1.30(current stable version) is not yet fully compatible with PHP 7.2. PHP will be issued a warning level error. If you disabled display_error in php.ini, there should not be any big problems.

Summary by Krinkle

For core, yes. For extensions, it depends.

Amire80 (talkcontribs)

Are we really supposed to support all versions of Safari since 5.1? It's a bit old.

Krinkle (talkcontribs)

@Amire80 Is there a specific web platform or browser feature you're finding absent in Safari 5.1? Since 2015, our support matrix is mainly based on feature detection, not browser detection. (See startup.js)

Amire80 (talkcontribs)

Not really. I was just surprised that we have something pretty old here.

I came here because of a question at Topic:U4chyrpe83knqy0y.

Krinkle (talkcontribs)

@Amire80 Okay, that makes sense (the topic is about ContentTranslation).

This page is for MediaWiki core, and describes its basic and enhanced features. Other WMF projects, if not otherwise defined, are assumed to follow it, but you don't have to.

Individual features, such as those provided by extensions, may have a different compatibility policy. WikiEditor and VisualEditor both had this for a long time. (Right now they don't because core caught up with them.)

If you have a different policy, make sure that you use a feature test that will gracefully make the code do nothing in older browsers (e.g. an early return and/or some kind of fallback message indicating the issue of browser support).

Amire80 (talkcontribs)

What does "Android" mean exactly in the browser support table?

Is it the built-in a.k.a. stock browser?

I'm not a true expert, but isn't this actually a bit too wide? Among the many issues with these browsers is that each device may have a different build that supports different HTML features and that they are rarely auto-updated. Besides, many people—though I don't know how many exactly—use mobile versions of Chrome, Opera, Firefox, or other browsers.

It boils down to this question: when something is broken on a stock browser on, for example, a 2012 Android phone, but works in Chrome for Android, how much effort should be dedicated to fixing it? I can recommend one user who reports a bug to use a different browser, but there may be millions who don't know about it.

Pinging @Jdlrobson :)

Jdlrobson (talkcontribs)

stock browser! :) page probably needs updating as it was probably last updated in 2013/14 at a guess.

Alex Mashin (talkcontribs)

The Future of HHVM. It seems that HHVM is going to diverge from PHP to Hack; so perhaps it time to migrate to PHP 7.1 (as the only version that is going to be maintained long enough).

Legoktm (talkcontribs)

There's an ongoing discussion on wikitech-l about this.

GoodMagician (talkcontribs)
Summary by Krinkle

The page now says "Using MySQL or MariaDB is recommended."

Danny B. (talkcontribs)

Is there MariaDB support? If yes, can it be added to the compatibility table? Thanks.

GoodMagician (talkcontribs)

Now that the Wikimedia Foundation uses MariaDB on it's cluster, does the table need to be updated?

Is there a timeline for how far into the future MySQL support will continue? In other words, as the MariaDB and MySQL projects diverge is there a point in time that Mediawiki might be expected to drop official support for MySQL?

Krinkle (talkcontribs)

The page now says "Using MySQL or MariaDB is recommended.".

ThinkPadLover123 (talkcontribs)

Ever since Wikipedia, MediaWiki, etc., completely blocked Windows XP (and any other systems without encryption deemed good enough from reading or accessing the sites in any way), there is definitely no way MSIE 6 is in any way supported! IE 7 on Vista is sadly the earliest I imagine is still allowed any access at all.

Too bad for anyone on a system which can't be updated — nothing for you!

Dinoguy1000 (talkcontribs)

Windows Vista was released in 2007, Windows 7 was released in 2009, and extended support for Windows XP ended in 2014. People have had over a decade to migrate to a more modern operating system. At this point, the only defensible reason for being stuck on XP is because your work environment requires it (and personally, in that situation I'd be looking for a different job).

Krinkle (talkcontribs)

The MediaWiki software still supports IE6 for its HTML web pages. I test this about once a year for unrelated reasons with a local MediaWiki install on BrowserStack (with tunnel). It still works.

Wikipedia and sister projects by Wikimedia Foundation, are indeed no longer accessible in IE6. This is indeed related to encryption. IE6 is not capable of modern encryption. It is also true that we care about your privacy and security, and want you to be protected from third parties that may be eavesdropping your connection.

But, the fact that users of IE6 are insecure is not by itself a reason to block them. In fact, Wikipedia does not "block" any web browsers. The HTTPS technology involves encryption. The website has a list of encryption methods it supports, and your browser as well. If both support the same method, then you can browse the website.

If Wikipedia were to allow the old IE6 encryption method, then that means you (on a modern browser, not IE6) can be spied on as well, because anyone between you and Wikipedia on the Internet can "downgrade" your connection to IE6's encryption method; see what you are reading on Wikipedia, and re-encrypt in a modern way toward you.

The only way to keep everyone else safe, is to keep IE6 out. This was not an easy decision.

For more information, see HTTPS recommendations. Specifically, note that users on Windows XP can still access Wikipedia by using Firefox ESR 52, which does support good-enough encryption!

Reply to "Internet Explorer"
BFeely (talkcontribs)

Running MediaWiki 1.31.1 in PHP 7.3.0RC4 produces the following warnings:

PHP Warning:  "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /var/www/ on line 297

PHP Warning:  "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /var/www/ on line 773
Legoktm (talkcontribs)

See phab:T206988 - our goal is that 1.31.2 will be compatible with PHP 7.3.

Jc86035 (talkcontribs)

@Jdforrester (WMF) Is Edge considered "unknown"? Internally it continues the Internet Explorer version numbering (although it does make sense that most of the 30 versions in between the current version and Internet Explorer 11 wouldn't be supported).

Jdforrester (WMF) (talkcontribs)

Whatever the native code does and thinks its version is, it's not exposed to anything we write. :-)

I don't think a decision on intentional (rather than accidental/ad hoc) support for Edge has been made; "Current and previous version" is probably right, but I haven't discussed it with anyone else.

Krinkle (talkcontribs)

Microsoft has been advertising Edge as being an "evergreen" browser (meaning, it automatically updates, similar to Firefox and Chrome). If that is true, then it'd make sense to only support the last two stable versions.

Unfortunately, the data paints a different picture. Possibly tied to the fact that updates for Edge are still (like with IE) tied to OS-level updates for Windows.

In Feb 2016, wrote that 2 months after Edge 13 came out, 26% of Edge users were still on Edge 12. (Based on data from

Looking at our own data, Edge 17 was released April 30, and shows that almost three months later between July 15 - July 25, only 80% of Edge users used Edge 17, 14% used Edge 16, 3.8% Edge 15, and 2.8% Edge 14.

Reply to "Edge"

Extensions that tag releases

Summary by Kghbln

Tagged extensions probably follow the "master" policy. Moreover please do not rely on the compatibility policy information.

Samwilson (talkcontribs)

Currently, extensions can be "master" compatible ("the master branch of the extension is compatible with both current and older versions of MediaWiki" or "release branches" (where REL1_* branches correspond to the core branches of the same names).

What about extensions who use master as unstable development branch, and don't use release branches, but instead tag releases (and include core-compatibility information in extension.json)? Is it okay to say that these have a "tags" compatibility policy?

Krinkle (talkcontribs)

@Samwilson I think that if an extension maintainer uses tags, that in itself would be insufficient.

Of course, one is free to do whatever, but I don't see the benefit of standardising an endless number of differing policies. That's counter to the benefit of standardising. The cost of more policies goes beyond this page. It also affects actual site-admins in how likely it is they will understand, remember, and successfully execute each MW upgrade. Having more strategies definitely makes this harder.

It's fine, of course, for an extension repo to have tags, but for maximum impact on and ease of upgrading for its users, it should also follow a standard policy ("master" or "rel").

For example, they could follow policy "rel" by updating the REL branches after each tag release to be in sync with the latest tag supported for that MediaWiki REL.

Or, even easier, follow policy "master", by using a "develop" branch for the unstable state, and periodically fast-forward "master" to the latest release tag.

In addition to causing confusion for site-admins, it would also ensure the ExtensionDistributor can still be used, given it only offers "master" and "rel". If an extension maintainer insists on using unstable master, tags only and no rel branches; their users would need to download the extension by other means - in which case the Compatibility page matters less.

Samwilson (talkcontribs)

Thanks Krinkle, that makes sense, and I agree that having fewer strategies is simpler to understand! :)

So it seems that tags for extensions do not really add any value (although, of course people can do whatever they like). Nor does adding a version number to extension.json or the extension template on the page — because the rule (for the "rel" strategy) is that anything in a REL1_ branch is to be considered stable and released, regardless of whether it matches a tag (or has a version number).

Kghbln (talkcontribs)

Note that a lot of extensions use tags. It means look at the docu for compat info and it also means that using the extension distributor version may get you into trouble in a lot of cases. I agree with you that it is pointless to have a truly tagged extension in the WMF repo since they do not follow rel nor master as a strategy. Still this leaves us with the problem of how to document these extensions. I think it is best to have a policy label called docu indicating that you should look at the docu or alternatively not add a policy to the extension's page at all to actually force people to look at the compat info. Whatever you think is the better approach I guess.

Kghbln (talkcontribs)

I have read again what master (provides backports) and rel (does not provide backports) is supposed to mean. So tagged ones indeed fit better into master though not entirely. I have seen extensions labeled with master that deliberately break compat with older branches and do not provide backports. Mostly these ill-fated manifest 2 cases I believe to remember. Whatever. The wording of the compat policy needs to be improved I guess. In the end using corresponding branches for extensions to core should always work in an ideal world and exceptions are just the tagged extensions.

Kghbln (talkcontribs)

This was a jolly good conversation. Thanks for you input and all the interaction.

Samwilson (talkcontribs)

Sorry Kghbln; been a busy week. :)

Also, I'm not really sure what the answer is here (I'm confused). It seems that lots of people do tag and don't backport; that's certainly a common model in the PHP world outside MediaWiki. But if we don't support that (as in, we expect extension maintainers to do things differently) then we should probably do more to make it clear that there's no point in tagging extensions.

Another question I have is about testing (I know I should already know this but): if an extension is using the 'master' compatibility policy, there's no way to run tests against anything other than master MediaWiki is there? It's only the REL branches that are run against the corresponding other versions? So what's the best way to maintain backwards-compatibility of the master branch by getting its tests run against all current MediaWiki versions? It's possible to just backport, of course, even if not using the REL branches for releases, but it'd be cool if every patch could be run against older MW versions too, so it wouldn't need to be submitted four times.

Kghbln (talkcontribs)

No worries. I am no longer a grumpy goat. Is this what people refer to if they are talking about goatifying things? ;)

Well it is confusing since the compat tags "rel" and "master" do not improve predictability for extensions created and maintained by third party programmers. A tag means that the extension is compatible for the branches stated by the programmer but for master. If there is a bug for master the extension gets fixed and we get a new tag indicating the new set of branches the extension is meant to be compatible with.

My impression is, I may be wrong here, that most third party programmers who tag do not backport to the WMF specific branches nor do they intend to do so. Au contraire, the advise not the use the software provided by the extension distributor.

I guess testing is also organized differently by every third party programmer if they do automated testing at all. I know from SMW that it uses integration test heavily that are run parallel against a whole set of branches including master to see if he software passes or if issues need to be fixed for the next tagged release. I think that this is a pretty good approach but I have no clue how it fits into the compat policys, i.e. "rel" or "master".

Note that I am writing this as a wiki administrator since I am not a programmer. For me it will be nice to be able to predict which version can be run for what version of MediaWiki I have set up on my server. This was actually my hope for improvement to be enforced by the compatibility policy flag.

Kghbln (talkcontribs)

There is not interest to interact with me here. This is fine but please refrain from re-opening this thread. I conclude that the information provided by compatibility policy continues to be useless for most extensions.