Actually... let's protect this until the upcoming security release.

See also related discussion in T297416#7568198 mentioning a different approach than deprecating.

We're going to be renaming this variables anyway given their language, but if people really want to keep this around as a variable, fine.

In T297651#7573605, @Jdforrester-WMF wrote:

We're going to be renaming this variables anyway given their language, but if people really want to keep this around as a variable, fine.

I'd guess we could re-open this task (or create a similar task) down the road. Personally, I don't love the idea of these globals sticking around indefinitely.

In T297651#7573618, @sbassett wrote:

In T297651#7573605, @Jdforrester-WMF wrote:

We're going to be renaming this variables anyway given their language, but if people really want to keep this around as a variable, fine.

I'd guess we could re-open this task (or create a similar task) down the road. Personally, I don't love the idea of these globals sticking around indefinitely.

I've never run a world-facing private wiki, so I'd be interested to hear from actual users about how much these variables are critical to their world. Probably "lots". :-(

I honestly see this as a defense in depth principle. It's possible that future actions miss to add the given check, or current check mistakenly gets removed.

In T297651#7573653, @Ladsgroup wrote:

It's possible that future actions miss to add the given check, or current check mistakenly gets removed.

The new check fails closed, so if someone misses it they're protected. I would hope someone trying to remove a check for read permissions is properly scrutinized as security sensitive. As noted in the other ticket, this check exists in the Action API and now REST API subsystems without much issue.

I think there is value in having a public "home page" for private wikis versus a private one, and it's nice if we didn't have to resort to message overrides for it because that will cause complications in the future if we want to rename the message or add more parameters, etc. If we were implementing this feature today I think something like $wgPublicMainPage = 'Foobar'; would be simpler (and then you could do neat tweaks like switching where the logo points if you're logged in or out).

This may also be a new message like MediaWiki:Publicmainpage (and the current MediaWiki:Loginreqpagetext be removed, see T17484: Redirect to Special:UserLogin when logging is in required to proceed, instead of showing an error message).