No other extensions have this problem, there have a boolean there.

Yah, it needs to be "with continue=". The api returns in most cases the requested limit and a continue or less than the limit and no continue. I know some modules, which have a hint, that there can return less pages. But I was unsure if that was required or not. But it is okay for me, when it is up to the maintainer.

In T208691#4948650, @gerritbot wrote:

Change 489929 merged by jenkins-bot:
[mediawiki/extensions/PageViewInfo@master] Skip invalid titles from pageview API in ApiQueryMostViewed

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

Thanks. Will wait for the next regular run to get new stats on https://commons.wikimedia.org/wiki/Special:MediaStatistics

It seems the fix already backported to REL1_31

Your copy of KEY_FORMAT_REGEX includes an escaped -, your php example does not use a escaped -

A workaround exists: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/489140/

In T212852#4936669, @Ramsey-WMF wrote:

Confirmed that newly uploaded DjVu files are indexed as office. Will keep this ticket open for a bit longer while we see if Cirrus does reindex old files properly.

This affects TorBlock, which is wmf deployed.

Have you try prop=redirect? Your linked doc is for the case to resolve redirect, that means going from redirect to page. Try the the other way, going from page to all its redirects (0..N)

Also broken on PronunciationRecording:
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/33879/console

So a patch set is needed to validate @covers on class and function level and it have to validate @coversDefaultClass on class level and ignore @covers starting with :: on function level

Thanks for the feedback

Sounds similar to T208901, but I am not sure

It also fails on CheckUser, so this can affect the whole gate

I am not sure, if there could be more tools in the futher with this exit codes.
Maybe a wrapper script can reset the unwanted exit codes.
Upstream does not change this (I have read that month ago in a issue or so)

Okay, that information was missing for me in the task description.

MediaWiki is encoding the ? to %3F when using it in forms.

"The MassMessage extension allows a user to send a message to a list of pages via special page Special:MassMessage"

According to https://atj.wikipedia.org/wiki/Kotakahi:Version the extension is installed.

It is looking for punctations (regex class \p{P} which include \ when looking at https://www.fileformat.info/info/unicode/category/Po/list.htm

For mediawiki-codesniffer the upstream version is always bundled with a new version. That is needed to install it correctly with composer.

I support "Get reviewers based on paste code-reviews votes"
Use Code-Review+1/+2/-1/-2 to find new reviewers, because that would let people review the code and repository which already does it. Using git blame and searching for authors must not find people able to merge patch sets. With the Code-Review that is possible.

Just for information: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/483614/

In T202922#4840542, @Umherirrender wrote:

phpcs3.4.0 contains new sniff Generic.CodeAnalysis.EmptyPHPStatement, needs check if that works in this case

The sniff for review under https://gerrit.wikimedia.org/r/#/c/mediawiki/tools/codesniffer/+/446271/ has a autofix and works pretty well from my point of view.

Using a define sounds good to me, but it seems modern code is not using this style. So having a class constant is also a way to do it. I did not prefer any way here.