Varargs in use and the error suppressions are removed, so this is fixed now.

Another problem with $wgUser not init was https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533190/1/includes/cache/MessageCache.php
That was the case when exception needs messages

Already filled as T235316

Special:ComparePages makes it better https://www.wikidata.org/wiki/Special:ComparePages?page1=&rev1=11&page2=&rev2=772301402&action=&diffonly=&unhide=

lhprop=pageid skipps the addition of necessary fields to the result set, added a condition for that

The new message for the reasons is MediaWiki:revdelete-reason-dropdown-suppress, the old message is kept. Needs moving on each wiki when needed.

No need to look for PHPUnit methods, because the tests folder is not part of the default config

Codesniffer can help you on avoiding new annotations.

By the way, there is now a stub for getID3.php, so this may not use the composer version

Maybe not the user is blocked, but the IP used by the user. Global blocks can also prevent login.

Possible a regression from the addition of extension.json - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/LogoFunctions/+/509154/

The new PSR12.ControlStructures.BooleanOperatorPlacement from release 3.5.0 sounds a bit like this

The wiki page says

This can be used in combination with Phan's template support.

I am not sure if @phan-assert on the lib code would be read by phan

.phan/config.php and the composer change are still needed.

In T59109#5492517, @AndyRussG wrote:

@Umherirrender, could you or anyone else perhaps confirm if this is still an issue today? Thanks much!!!

Hopefully that is PhanTypeMismatchArgument, which is worked on: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/517740/

I would say, nothing more to do

I am fine with work on issues found by phan and I support such work, but on an old codebase like mediawiki/core you cannot assume that 7 days and 10+ patch sets with 2000+ changed line will bring you to a better world without global suppressions. Phan is running since some months (or years) with all the suppressions for a reason (no one work on it).

Fixed by patch sets for T231636

Looks good now

In T227608#5324961, @Krinkle wrote:

It does mean that img_size is missing from the query, which might also be causing issues for Wikipedia in production.

The special page is using IDatabase::buildConcat, but not IDatabase::buildStringCast

This can happen when the refresh job is not finished after addition of a url to a template.
Go throught the list of templates of the reported pages and try to find an edit.

Getting the first revision of a page is expensive from the current database schema, see also T44135 for the same underlying issue

Sounds like T104756

The stack trace should be gone since https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/502348/

Sounds that it is T189560, because the error message indicates a class from a composer package

The exception is not only for empty titles, also for invalid ones:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:NewSection?page=This_is_<_invalid -> Go

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/527212/?

At the moment for all extensions the necessary patch sets exists

Last code snippet replaced