just wanted to report that i've had my Mediawiki 1.37.1 installation running on Debian Unstable's PHP 8.1.2 for about a week now, and seen zero problems. this has included search, editing, and creating new pages. looking good!

In T248925#7659109, @Sosodank wrote:

just wanted to report that i've had my Mediawiki 1.37.1 installation running on Debian Unstable's PHP 8.1.2 for about a week now, and seen zero problems. this has included search, editing, and creating new pages. looking good!

I think most of the more recent fixes are potential logspam (for upcoming deprecations)... Most things should work fine otherwise

In T248925#7661046, @Reedy wrote:

In T248925#7659109, @Sosodank wrote:

just wanted to report that i've had my Mediawiki 1.37.1 installation running on Debian Unstable's PHP 8.1.2 for about a week now, and seen zero problems. this has included search, editing, and creating new pages. looking good!

I think most of the more recent fixes are potential logspam (for upcoming deprecations)... Most things should work fine otherwise

Hello,

For us persists a problem on the wf19 when searching with a ": ".
For example "Fallout: " :

[baf8af3c0dc979cc96acd2d3] /index.php?search=Fallout+%3A+&title=Sp%C3%A9cial%3ARecherche&wprov=acrw1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns274=1&ns275=1&ns710=1&ns711=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1&ns3000=1&ns3001=1 ParseError: syntax error, unexpected token "match"

Backtrace:

from /extensions/Elastica/vendor/ruflin/elastica/lib/Elastica/Query/MatchQuery.php(10)
#0 /vendor/composer/ClassLoader.php(322): Composer\Autoload\includeFile()
#1 /extensions/CirrusSearch/includes/MetaStore/MetaNamespaceStore.php(95): Composer\Autoload\ClassLoader->loadClass()
#2 /extensions/CirrusSearch/includes/MetaStore/MetaNamespaceStore.php(79): CirrusSearch\MetaStore\MetaNamespaceStore->queryFilter()
#3 /extensions/CirrusSearch/includes/Searcher.php(469): CirrusSearch\MetaStore\MetaNamespaceStore->find()
#4 /extensions/CirrusSearch/includes/Util.php(125): CirrusSearch\Searcher->CirrusSearch\{closure}()
#5 /includes/poolcounter/PoolCounterWorkViaCallback.php(74): CirrusSearch\Util::CirrusSearch\{closure}()
#6 /includes/poolcounter/PoolCounterWork.php(162): PoolCounterWorkViaCallback->doWork()
#7 /extensions/CirrusSearch/includes/Util.php(183): PoolCounterWork->execute()
#8 /extensions/CirrusSearch/includes/Searcher.php(475): CirrusSearch\Util::doPoolCounterWork()
#9 /extensions/CirrusSearch/includes/Searcher.php(701): CirrusSearch\Searcher->findNamespace()
#10 /extensions/CirrusSearch/includes/Hooks.php(544): CirrusSearch\Searcher->updateNamespacesFromQuery()
#11 /includes/HookContainer/HookContainer.php(338): CirrusSearch\Hooks::onSearchGetNearMatch()
#12 /includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#13 /includes/HookContainer/HookRunner.php(3234): MediaWiki\HookContainer\HookContainer->run()
#14 /includes/search/SearchNearMatcher.php(168): MediaWiki\HookContainer\HookRunner->onSearchGetNearMatch()
#15 /includes/search/SearchNearMatcher.php(70): SearchNearMatcher->getNearMatchInternal()
#16 /includes/specials/SpecialSearch.php(341): SearchNearMatcher->getNearMatch()
#17 /includes/specials/SpecialSearch.php(200): SpecialSearch->goResult()
#18 /includes/specialpage/SpecialPage.php(671): SpecialSearch->execute()
#19 /includes/specialpage/SpecialPageFactory.php(1378): SpecialPage->run()
#20 /includes/MediaWiki.php(314): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#21 /includes/MediaWiki.php(903): MediaWiki->performRequest()
#22 /includes/MediaWiki.php(563): MediaWiki->main()
#23 /index.php(53): MediaWiki->run()
#24 /index.php(46): wfIndexMain()
#25 {main}

fallout-wiki.com

Hi and welcome @Falloutgen, please bring this up on https://www.mediawiki.org/wiki/Project:Support_desk (or in a separate ticket, if you know for sure this is related to PHP 8.1). Thanks!

I think this is at least related to T267524.

In T248925#7661324, @IijimaYun wrote:

I think this is at least related to T267524.

Wrong task. T268861: CirrusSearch uses Elastica's Match class and it's tree is probably better. And has people reporting similar issues. The report isn't related to MW core, it's related to CirrusSearch and libraries.

I've no idea what wf19 is.

Hello,

I would say that the problem is related to this task, Elastica does not update its dependencies automatically with compose in the MediaWiki source folder:

https://phabricator.wikimedia.org/T173141

In T248925#7661441, @Reedy wrote:

In T248925#7661324, @IijimaYun wrote:

I think this is at least related to T267524.

I've no idea what wf19 is.

Sorry, mediawiki wmf 19 :)

Kims

In T248925#7661452, @Falloutgen wrote:

I would say that the problem is related to this task, Elastica does not update its dependencies automatically with compose in the MediaWiki source folder:

https://phabricator.wikimedia.org/T173141

And that's not a PHP 8 specific issue either.

I can confirm that MediaWiki 1.37.1 has been runing on PHP 8.0 without issues. Some extension dependencies needed to be updated using composer.

In T248925#7712630, @Dusoft wrote:

I can confirm that MediaWiki 1.37.1 has been runing on PHP 8.0 without issues. Some extension dependencies needed to be updated using composer.

Most of the recent fixes have been targetted towards logspam more than anything.

But good to know!

What about PHP 8.1 for MediaWiki 38? Can we expect it to work as well as MW 37 on PHP 8.0?

In T248925#7723615, @JeroenDeDauw wrote:

What about PHP 8.1 for MediaWiki 38? Can we expect it to work as well as MW 37 on PHP 8.0?

8.1 is not a major release and does not seem to have any breaking changes compared to 8.0.

PHP makes limited breaking changes in minor releases. I already updated two MediaWiki extensions to avoid issues on PHP 8.1.

See also: MediaWiki PHP support history https://www.mediawiki.org/wiki/Compatibility#PHP

In T248925#7723615, @JeroenDeDauw wrote:

What about PHP 8.1 for MediaWiki 38? Can we expect it to work as well as MW 37 on PHP 8.0?

I’m trying to backport 8.1 fixes and such when we make them

I think it mostly works. See the php 8.1 tag and workboard. There is at least one issue that’s waiting on an upstream release of a fix. Somewhat out of our control

Bugs running on 8.1 are definitely accepted. But most of the log spam has been addressed I think

I’m on my phone, so can’t easily link the board..

https://phabricator.wikimedia.org/tag/php_8.1_support/

T299693: Memcached::cas(): Argument #4 ($expiration) must be of type int, int given is one known out of our control…

MediaWiki is going to be updated to PHP 8 soon. Please calm down

I am sorry, but I am highly confused by this task or ticket. This has been open for a while now and do we have to wait for all subtasks to be closed? I am not used to phabricator or gerrit, so I am drawing a blank here.

PHP 7.4 is already EOL and PHP8 which this task should support will be EOL in 3 months. Everywhere I go it says MediaWiki is not compatible with PHP8. Will PHP 8 be supported by MediaWiki when PHP8 is no longer supported by PHP? I am confused.

Can someone please give an official statement and a proper timeline (and maybe weekly or bi-weekly updates)? I am very sorry for this request, but I just don't know what's going on.

@Tessus: PHP 7.4 is supported until 28 November 2022 and not "already EOL". PHP 8.0 is supported until November 2023 and not "EOL in 3 months". At some point, MediaWiki will support PHP 8, when the work is done (see open subtasks). Feel free to follow this task and open subtasks if you are interested in updates. Thanks.

@Aklapper I checked here, but you are correct. The EOL definition I used might have been off. But the status "security updates only" is not an active product. So my concerns are still valid.

At some point, MediaWiki will support PHP 8, when the work is done (see open subtasks).

This is exactly my point. I believe there's no way to make this even less specific. Projects usuallly work with deadlines, ETAs, roadmap, dates.

The beatings will continue until morale improves.

Media wiki is powerful, multilingual, free and open, extensible, customizable, reliable, and free of charge no warranties given.

I’ve always been amazed by the fact this works at all. I recognize PHP 8 is a major change with affects scattered on hundreds of lines throughout Mediawiki’s large body of code. Been there in my working life and it’s hard work, no fun and receives very little recognition for it’s complexity and required testing.

I appreciate all you do and if I can help at all let me know?

You’ve been done a great job to date and I can run on earlier versions until you are able to get your globally scattered ice skating cats herded into a figure 8.

Be well,
Johnny
A backwater kind of guy.

In T248925#8095760, @Tessus wrote:

@Aklapper I checked here, but you are correct. The EOL definition I used might have been off. But the status "security updates only" is not an active product. So my concerns are still valid.

Not really. Software that is security supported is more than reasonable to be continued to be used in production. You'll probably find that various distributions (Debian for example) continue to ship and maintain software that is unsupported by their upstream.

In T248925#8095760, @Tessus wrote:

At some point, MediaWiki will support PHP 8, when the work is done (see open subtasks).

This is exactly my point. I believe there's no way to make this even less specific. Projects usuallly work with deadlines, ETAs, roadmap, dates.

There isn't a project, ETA or roadmap or date.

Wikimedia is still running PHP 7.2, and is currently working on upgrading to PHP 7.4 (see T271736: Migrate WMF production from PHP 7.2 to PHP 7.4). Unfortunately due to the powers that be, that's not really a priority either. But at least it's moving forward again now.

7.2 is definitely EOL.

PHP 8 will come, but that is likely post the Kubernetes migration.

But to answer your question, MediaWiki should mostly work on PHP 8 and PHP 8.1. It's not been massively well tested by "us", but various sites have been running MediaWiki on PHP 8. It should work fine.

We aren't actively running tests for most "sub projects" of MediaWiki on PHP 8 or PHP 8.1. We know of some issues, but a lot of it is deprecated warnings and such, rather than actual major failures (I believe we've fixed most of them).

One major reason is due to the version of ElasticSearch libraries ( elasticsearch/elasticsearch specifically), that don't support PHP 8 and means we can't run our sets of tests easily.

As such, I think it's unreasonable to actually declare that MediaWiki unilaterally supports PHP 8.

You're more than welcome to run MW on PHP 8, and bug reports are very much welcome welcome. Fixes applied to master will be backported to supported release branches (as such, REL1_35, REL1_37 and REL1_38) on a best effort basis.

MediaWiki is an open source project, and the community helping with this sort of venture is definitely necessary.

The reason the task tree is complex, is because the "project" is complex. There's MediaWiki core, many extensions, libraries and everything else that potentially need testing, changes, releases and integrated.

In T248925#8095355, @Tessus wrote:

Can someone please give an official statement and a proper timeline (and maybe weekly or bi-weekly updates)? I am very sorry for this request, but I just don't know what's going on.

No, because it's not an official project. It doesn't have a product manager, never mind a timeline, and therefore no weekly/bi-weekly updates.

Most of the relevant changes will be tagged against this task, or a more specific subtask.

You might find following PHP 8.0 support and or php_8.1_support helpful.

Or just try it out and see. You might be surprised.

I have been running MediaWiki on PHP 8.0 since 1.38 was released, with CirrusSearch+Elastica and a number of other extensions. Using PostgreSQL back-end, to boot.

The wikis I host get plenty of visits and there have been no reports of any issues, nor do I see any obvious problems or errors in the logs.

If you do not use extensions extensively, MediaWiki should work on PHP 8 just fine.

There isn't a project, ETA or roadmap or date.

See, this I didn't know.

As such, I think it's unreasonable to actually declare that MediaWiki unilaterally supports PHP 8.

This is perfectly fine. So let's tone down this highly annoying red warning section that PHP 8 is not supported or at least let's put it out there that mediawiki-core is working on PHP8 just fine.
Nobody expects you to test all 3rd party extensions. That's up to the extension devs to do.

You're more than welcome to run MW on PHP 8, and bug reports are very much welcome welcome. Fixes applied to master will be backported to supported release branches (as such, REL1_35, REL1_37 and REL1_38) on a best effort basis.

I will do that.

No, because it's not an official project. It doesn't have a product manager, never mind a timeline, and therefore no weekly/bi-weekly updates.

I didn't know this either.

This is perfectly fine. So let's tone down this highly annoying red warning section that PHP 8 is not supported or at least let's put it out there that mediawiki-core is working on PHP8 just fine.

This is a valid point. Does standalone MediaWiki support PHP 8? I don't know. It would be nice if it was made clear whether it did or not since a lot of the subtasks of this task are for elasticsearch which is an extension and not part of the MediaWiki codebase.

Clarifying MediaWiki supports PHP 8 will give the green light to developers that they can start using PHP 8 features in the MediaWiki and their extensions.

Current status is (as far as i know):

• no currently known bugs on mediawiki core against php8 (Edit: against php 8.0)
• test suite passes, but is not being run on every commit for php8
  • more specificly, there are two versions of test suite, either using normal composer install, or using a static vendor bundle. The composer install version works fine. The static vendor one does not work against master (but does work against 1.37 and 1.38). This is because its impossible to make a static vendor bundle that works for both php 7.2 and php 8, when also including dependencies needed for extensions wikibase, cirrussearch and Oauth (to be clear, these extensions may be fine on php8, its just making them work on php8 and 7.2 at the same time). This seems more an implementation detail than something that matters.
• WMF does not use php8, so mediawiki on php8 does not have the rigorous testing that wmf does. However other users have tested it and have not reported issues.

In my opinion, our "lack" of php8 support is a bit overblown. I think we should get CI running the (composer variant) test suite on php8 for every commit, at which point we should call it a day and say mediawiki supports php8.

I have already toned down the warning somewhat.

Clarifying MediaWiki supports PHP 8 will give the green light to developers that they can start using PHP 8 features in the MediaWiki and their extensions.

Extension devs can do whatever they want, however mediawiki core will be maintaining php 7.2 compatibility for a little while yet, regardless of the state of php8 support.

In T248925#8099325, @Bawolff wrote:

• no currently known bugs on mediawiki core against php8

See T313662: failing parser tests for PHP 8.1 for a start.

Yeah, we wouldn't claim MW works on PHP8 just because it works on PHP 8.0. In the same way we don't claim it works on PHP 7 just because it works on 7.4.

The minor release version is important.

8.1 changed many things, but most of them aren't complete failures, they're mostly logspam from deprecation of things.

One thing that is not log spam (because it actually changes behavior) is the use of array_key_exists().

This results in failing tests in core.

In PHP 7.4:

$ php7.4 -d error_reporting=-1 -r 'var_dump( array_key_exists( null, null ) );'; echo $?
PHP Warning:  array_key_exists() expects parameter 2 to be array, null given in Command line code on line 1
NULL
0
$ php7.4 -d error_reporting=0 -r 'var_dump( array_key_exists( null, null ) );'; echo $?
NULL
0
$

In PHP 8.0:

$ php8.0 -d error_reporting=-1 -r 'var_dump( array_key_exists( null, null ) );'; echo $?
PHP Fatal error:  Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, null given in Command line code:1
Stack trace:
#0 {main}
  thrown in Command line code on line 1
255
$ php8.0 -d error_reporting=0 -r 'var_dump( array_key_exists( null, null ) );'; echo $?
255
$ 

I said the changes in PHP 8.1 were mostly deprecation logspam ;)

In T248925#8099367, @Reedy wrote:

I said the changes in PHP 8.1 were mostly deprecation logspam ;)

Thanks for clarifying. I think that is true, but now I must find a failure, just to emphasize the "mostly" part of your statement. :)

In T248925#8099382, @MarkAHershberger wrote:

...but now I must find a failure, just to emphasize the "mostly" part of your statement. :)

Ah, I already had one. Not in core, but CirrusSearch.

First item on incompatible changes for 8.1.

Here is a fatal in core for 8.1 that doesn't exist in 8.0: Update BatchRowIterator and NotRecursiveIterator interface for php 8.1

I think we should discuss php 8.0 and 8.1 on separate tasks as this is already really hard to follow.

Another question - In order to declare we support php8.0, is it a requirement that we run tests in CI under php8.0 for all the bundled extensions?

In T248925#8099843, @Bawolff wrote:

Another question - In order to declare we support php8.0, is it a requirement that we run tests in CI under php8.0 for all the bundled extensions?

Yes. CI should be set up for php8.*.

Hello,
We use mediawiki on two wikis in Wmf21 (and follow the wmf cycle) with PHP 8.1 and elasica, no problem to report since many months.
Sincerely
Kims

In T248925#7661535, @Reedy wrote:

In T248925#7661452, @Falloutgen wrote:

I would say that the problem is related to this task, Elastica does not update its dependencies automatically with compose in the MediaWiki source folder:

https://phabricator.wikimedia.org/T173141

And that's not a PHP 8 specific issue either.

FYI: PHP 8.1 made major changes to how $GLOBALS works, and one of the side effects is that using array_key_exists on $GLOBALS is now a linear-time operation instead of constant-time. MediaWiki uses this construct pretty extensively in GlobalVarConfig, which is ~1000 times slower in 8.1 than it is in 8.0, due to $GLOBALS having 1000-2000 entries in it.

The effect of this (in our testing on runescape.wiki, at least) is that total parse time silently went up about 50% when switching from 8.0 to 8.1, due to many thousands of calls to GlobalVarConfig::get, which now takes about 20 microseconds each.

I have filed a bug against PHP core about this. In the mean time, changing GlobalVarConfig::get to

isset( $GLOBALS[$var] ) || array_key_exists( $var, $GLOBALS );

seems to reduce the time spent in array_key_exists back down to pre-8.1 levels (note that just using isset on its own won't quite work if the value is null). If you are currently using PHP 8.1 in production, I recommend trying this out.

Change 826917 had a related patch set uploaded (by Aaron Schulz; author: Aaron Schulz):

[mediawiki/core@master] Avoid PHP 8.1 failures in SpecialPreferencesTest::testT43337

https://gerrit.wikimedia.org/r/826917

Change 826917 merged by jenkins-bot:

[mediawiki/core@master] Avoid PHP 8.1 failures in SpecialPreferencesTest::testT43337

https://gerrit.wikimedia.org/r/826917

In T248925#8188458, @cookmeplox wrote:

FYI: PHP 8.1 made major changes to how $GLOBALS works, and one of the side effects is that using array_key_exists on $GLOBALS is now a linear-time operation instead of constant-time.

Thank you, I've filed T317951: Adjust MediaWiki to avoid the slowness of array_key_exists on `$GLOBALS` in PHP 8.1+ for us to adjust to this.

Strcasecmp-related error in CookieSessionProvider, MediaWiki 1.38.2.

In T248925#8244134, @Huwmanbeing wrote:

Strcasecmp-related error in CookieSessionProvider, MediaWiki 1.38.2.

That was fixed with https://github.com/wikimedia/mediawiki/commit/2a917876614fedc6d5673b4d0ca06d832512871a I think

In T248925#8244136, @Paladox wrote:

In T248925#8244134, @Huwmanbeing wrote:

Strcasecmp-related error in CookieSessionProvider, MediaWiki 1.38.2.

That was fixed with https://github.com/wikimedia/mediawiki/commit/2a917876614fedc6d5673b4d0ca06d832512871a I think

Yup, which will be in MW 1.38.3 and later.

Just a status update - mediawiki core unit tests should now pass on REL1_38, REL1_39 and master branches for php 8.0 and 8.1. (This is for the` composer install` variant. The CI tests that are using mediawiki/vendor.git do not work on master but do work on REL branches)

Still to do, is to verify that they pass for bundled extensions and also that the tests that come with vendor dependencies all pass. Also REL1_35 and REL1_37 if anyone is interested, but I'm not sure interest is there to put in the effort for the older branches.

Clarifying title as this appears to about both core (T283275: Make MW master tests pass on PHP 8.0) and bundled extensions (T274965: Make PHP 8.0 voting on currently supported MW release branches).

How much more effort should we put into this?