Change 177172 had a related patch set uploaded (by Krinkle):
content: Recognise .json as JsonContent User and MediaWiki namespace

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

Patch-For-Review

Change 177172 merged by jenkins-bot:
content: Recognise .json as JsonContent in User and MediaWiki namespace

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

In T76554#1334272, @Jdforrester-WMF wrote:

Does the above patch restrict editing of user-json?

No, this patch is a prerequisite for that.

• https://gerrit.wikimedia.org/r/177172 (branch master): MW-1.26-release, WMF-deploy-2015-06-09_(1.26wmf9)

@Legoktm, thanks!
@Krinkle, hello, any progress here?

Does this function account for content model changes?

In T76554#2959058, @JEumerus wrote:

Does this function account for content model changes?

What do you mean?

What I mean is that changing the content model of a JS page causes it to lose its protection; see links in T85847#2959070

Change 408940 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [WIP] Add protection for User: and MediaWiki: JSON pages

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

In T76554#2974497, @JEumerus wrote:

What I mean is that changing the content model of a JS page causes it to lose its protection; see links in T85847#2959070

The code currently stops a third party editing a user's page if it's a subpage with the JS or CSS content model; it doesn't actually depend on being called .js or .css, but that's the only way non-admins can make a JS/CSS content model page. With this change, it would also extend to the JSON content model (and the .json extension), yes. The particular issue you highlighted would no longer break – User:Foo/bar.json pages (or User:Foo/bar.js with the JSON content model) would not be editable by other users except admins.

Thank you for the task description expansion!

Change 408940 merged by jenkins-bot:
[mediawiki/core@master] Add protection for User: JSON pages in the same manner as JS & CSS ones

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

Hello! I see many good reasons for this change, but perhaps this wasn't brought up: Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

For our use case, we'd have to change the content model to wikitext so that anyone could edit it. This is fine except you then don't have the nifty JSON editor that validates your input, nor the pretty JSON formatting when viewing the page directly.

Would it make sense to allow admins to lower the protection level? I assume adding this functionality wouldn't be a trivial change. I'm just curious if you at all think it is a good idea.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do:

• Code that you insert on this page could contain malicious content capable of compromising your account. (MediaWiki:Jswarning)
• The code will be executed when previewing this page. (MediaWiki:Jswarning)
• After saving, you have to bypass your browser's cache to see the changes. (MediaWiki:Clearyourcache)

Depending on what's using the JSON, these could be true, but they certainly aren't in our case. It's just misleading, is all.

In T76554#4188271, @MusikAnimal wrote:

Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

In T76554#4188271, @MusikAnimal wrote:

Hello! I see many good reasons for this change, but perhaps this wasn't brought up: Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

For our use case, we'd have to change the content model to wikitext so that anyone could edit it. This is fine except you then don't have the nifty JSON editor that validates your input, nor the pretty JSON formatting when viewing the page directly.

You could move it to the Project namespace? In general, asking users to edit JSON isn't ideal.

Would it make sense to allow admins to lower the protection level? I assume adding this functionality wouldn't be a trivial change. I'm just curious if you at all think it is a good idea.

I think this opens up a can of worms.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do:

• Code that you insert on this page could contain malicious content capable of compromising your account. (MediaWiki:Jswarning)
• The code will be executed when previewing this page. (MediaWiki:Jswarning)
• After saving, you have to bypass your browser's cache to see the changes. (MediaWiki:Clearyourcache)

Depending on what's using the JSON, these could be true, but they certainly aren't in our case. It's just misleading, is all.

Could you file a separate bug for that?

In T76554#4188285, @Ciencia_Al_Poder wrote:

In T76554#4188271, @MusikAnimal wrote:

Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

Yes, that's what I'd recommend if you really do want anyone (not just sysops) able to redirect the work of an automated tool.

I'd like to echo what @MusikAnimal wrote above about lowering the protection level. An alternate could be to not have this apply on bot account pages.
I'm surprised this change went through without a wider announcement ahead of rollout.

In T76554#4188317, @Niharika wrote:

I'd like to echo what @MusikAnimal wrote above about lowering the protection level.

OK. But implementing that would be a serious amount of work, and not generally a good idea from a product perspective (yet more complication in an area that already confuses many sysops).

An alternate could be to not have this apply on bot account pages.

As above, this sounds like a bad idea to provide a hack that shouldn't exist.

I'm surprised this change went through without a wider announcement ahead of rollout.

Discussed for multiple years, announced in Tech/News, highlighted in Scrum of Scrums at least twice over the years. If anything, rather more announcement than something this mild deserves.

In T76554#4188341, @Jdforrester-WMF wrote:

I'm surprised this change went through without a wider announcement ahead of rollout.

Discussed for multiple years, announced in Tech/News, highlighted in Scrum of Scrums at least twice over the years. If anything, rather more announcement than something this mild deserves.

Not everyone's been around for years. That bot came into existence last year.
I don't see a mention in the recent few scrum of scrums notes but I didn't look too closely.

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

You could move it to the Project namespace?

Given the nature of our bot, I think we could get away with this. However on enwiki anything in the WP namespace is usually subject to scrutiny, so other bot operators probably will have trouble storing their config pages there. I realize this probably won't be an issue some 90-something percent of the time, as any given bot config is rarely edited. It was just really neat that we could allow non-admins to make configuration changes.

In general, asking users to edit JSON isn't ideal.

In general, yes. The old Popular Pages Bot had a full-on wiki-like interface on Toolforge, such that any changes can be audited. The community asked that we replicate this functionality, and instead of building a whole new tool we opted for an on-wiki config page since it offers a revision history.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do

Could you file a separate bug for that?

Created at T194086

For now we will try to move the Popular Pages Bot documentation and config to the WP namespace. Thanks!