In T102581#5910460, @Amorymeltzer wrote:

@Umherirrender, et al.: this is much appreciated, but as-yet incomplete. AFAICT, the dropdown for AbuseFilter entries still only draws from MediaWiki:Revdelete-reason-dropdown and doesn't account for the new page. I can open a new task if you like, but since AF logs can only be suppressed, not revision-deleted, that means the new page can't really be used.
It would seem reasonable to me for the AF dropdown to only pull from this new page, but in practice it should probably take both as well.

In T244157#5907956, @dmaza wrote:

In T244157#5907944, @Tchanders wrote:

@dmaza It's explained in T244157#5892494

I don't understand. Why do we care about timestamp when ipb_id is unique and auto-increment?

Timestamps are often not the right choose when it is possible to have duplicates of it for different actions from different users (Yes, it is possible to have two edits of one page in the same second, so it could be possible to have two deletion of different revisions in the same second, maybe not very likly to get, but possible).

Maybe phan can do the work better (In my opinion phan can do things with many files involved or dependenies between files, codesniffer is better when only check one file)

https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.5.4 contains one fix:

Squiz.ControlStructures.ForLoopDeclaration now has a setting to ignore newline characters

• Default remains FALSE, so newlines are not allowed within for definitions
• Override the ignoreNewlines setting in a ruleset.xml file to change

Another test case - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Auth_remoteuser/+/571076/5..6/src/AuthRemoteuserSessionProvider.php

It seems the following code does not take function call in account

You could also bring it to the LinkRenderer service as it holds some other Linker class function.
But that maybe include more technical debt, because this function needs the permission manager, the current function of LinkRenderer does not

Have found in phan's BlockExitStatusChecker.php:

A similar issue is tracked with T232451 where also a invalid user name is a problem

It seems the user name is not suppressed. Suppression logs and suppression a user are different actions

The export of aliases from translatewiki.net has stopped some ages ago.

mediawiki/core is using eslint now

In T243599#5837194, @Dzahn wrote:

from [mwmaint1002:/var/log/mediawiki/updateSpecialPages/s6@16-AncientPages.log] $

  1 -------------------------------------
  2 #
  3 -------------------------------------
  4 no version entry for `#`.
  5 Fatal error: no version entry for `#`.
  6  in /srv/mediawiki/multiversion/MWMultiVersion.php on line 423
~              
And this Fatal error shows up in all the other shards as well for the same crons.

In T243652#5837762, @ashley wrote:

In T243652#5837176, @DannyS712 wrote:

Noted. Perhaps it should officially be deprecated? Its currently not even soft deprecated.

That would certainly make sense. I do want to note that for things like SocialProfile, the reason why it's still using the old class instead of the newer class is that I'm not sure how to properly migrate old log entries over. Migrating the code to use the newer classes would also help improve the i18n as well as overall aesthetic appearance of the relevant log entries (see, for example, the user profile edit log on Brickipedia to see how the entries currently display).

Thanks for the explaination, I am happy to see that it now uploads one patch set for both upgrading.

I just want noted that LogPage::addEntry is an old way to provide log entries on Special:Log.
The new way is direct use of LogFormatter class.
In my opinion there must be no complex actions to avoid global state in that class.
It would be more future proofed (but sometimes more complex) to migrate the extension to the new logging
But when the caller already have a context, than it is okay to avoid the fallback to $wgUser. That are simpel patch sets.

In puppet is mediawiki::maintenance::updatequerypages::ancientpages which is running the update with the override option to get the special page updated.

Other extensions:

• GoogleAppEngine
• EditSubpages

MobileFronted also says about differences

karma runs now, thanks for the fix

MobileFrontend would have the same error, but fails at other location for the moment - https://libraryupgrader2.wmflabs.org/r/mediawiki/extensions/MobileFrontend

Another one:
https://libraryupgrader2.wmflabs.org/r/mediawiki/services/parsoid

On Html2Wiki there is an issue with autofix - T243721 - but I have no idea if that produce the error in the web ui

In T219139#5701986, @Umherirrender wrote:

The last question is, if this should be done also for unset()
I would say yes, because it makes the code easier when doing one thing in one line and not combine multi unsets in one line.

Is there an easy way to skip the first parameter in a method call, no matter how complicated the code is?