You could also create a new topic on https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP. It might add more visibility.

I think that supporting the definition to be either a callable or a string would be ideal (so a combination of your suggestions). It will make it backward compatible and we can start migrating into DI in incremental changes. SpecialPageFactory::getPage() already supports a string or a callable so a "quick" change would be to make $coreList non-static and adjust the SpecialPageFactory accordingly.
I'm not sure about Api Modules 'cause I haven't seen how that works

i did say feature flag originally ;)

You did, sorry I missed it :)

Copying over the "in-patch" comment for better discussion

It might also be a good idea to provide more info about mute (https://www.mediawiki.org/wiki/Help:Notifications#mute) and/or more information on how they can see their current email/mute list on Special:Preferences

Resolved on T218596: Remove stats for measuring when blocks are tracked with a Cookie

I'm going with No matching blocks found for the requested IP address or username

In T191549#5112283, @Tchanders wrote:

If someone is sitewide blocked, and the list is filtered to their username with block type Partial, the message says "The requested IP address or username is not blocked." This is not true any more. Should we change that message (ipblocklist-no-results) to something like: "No blocks found for the requested IP address or username."?

In T219684#5099143, @Mooeypoo wrote:

When did we introduce this? If we introduced it in a previous (and published) release, we might need to deprecate for the upcoming one? ... But if it's in between releases it's probably fine.

Either way, the deprecation should be super straight forward even if we do it because, as you pointed out, no one uses it this way outside our code.

In T219684#5099124, @dbarratt wrote:

@dmaza Also, any dependencies (config, database, etc.) should be injected rather than making the service aware of the container.

What is the plan here exactly? Is there any deprecation process that we have to go through?
Do we want to rename the BlockRestriction class to something else?

@daniel are there any name conventions to follow for this "servicification" we are doing? Or any other conventions for that matter?
"Store, Service, Manager", are we using those names interchangeably?

Declined in favor of T219441: Introduce a BlockManager service for getting and combining the blocks that apply to a user/IP

Also, please consider splitting BlockManager and BlockStore. BlockStore would have all the things that touch the database, while BlockManager builds on top of BlockStore and does all the things related to cookies and sessions and such.

I feel like that's still a bug. We shouldn't allow for non-existing namespaces to be saved. At the very least we shouldn't display an empty namespace in the BlockList.

Right so basically a partially blocked user with the undelete right should be to restore any page. They'll just be unable to do any other actions on it once it is restored (if the id happens to be the same after restoration)

In T218952#5046392, @Krinkle wrote:

Tagging AHT as this affect events from onBlockIpComplete, which might be of interest to you.

@dom_walden good catch. This patch fixes the advertise bug as well. There is a separate issue and that is that the user doesn't get any feedback when they are blocked and try to advertise but that's unrelated to PB.

In T218949#5046885, @alanajjar wrote:

Note: if you want I can make a short video.

@dmaza Did the team ever discuss this? It makes sense to me to update these pages too. I can go ahead and add them to the ticket description if there are no concerns.

That would make sense. IMO I don't think this data is worth keeping. Pinging @Tchanders @dbarratt @aezell for their thoughts.

@Niharika the patch will not remove the data but I'm not sure for how long we keep those metrics around. I can't find anything on wikitech about it.

In T211621#5026677, @dom_walden wrote:

I notice that users in the "staff" group will have

['MinimumPasswordLengthToLogin'] = [
  'value' => 10,
  'suggestChangeOnLogin' => true,
];

and I believe this will force them to change their passwords.