Page MenuHomePhabricator

Perhaps should have a notion of titles that must use default content model
Open, Needs TriagePublic

Description

Currently you can do stuff like make User:Bawolff/common.js have a CSS content model. This seems messed up. I don't think there is any legitimate reason ever to have user js subpage not be a Javascript content model

I think that in addition to having ContentHandler::canBeUsedOn() like we do currently (which restricts what pages a certain content model can be used on), we should also have a restriction in the other direction, where certain titles can only have the default content model (Or at least, cannot be overriden by normal user). Perhaps a Title::isAllowedCustomContentModel() [Alternatively, we could check it during $title->userCan( 'editcontentmodel' ) and just hook it into existing permission checks]. That way we could say personal user css/js cannot have a content model of something other than JS or CSS.

Thoughts?

Event Timeline

Bawolff created this task.Sep 9 2016, 4:35 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 9 2016, 4:35 AM

Hmm, does the ContentModelCanBeUsedOn hook fullfil this need?

Okay, after thinking about it a bit more, I agree that we should have a function like this.

andymw added a subscriber: andymw.EditedSep 13 2016, 4:41 PM

What happens if User:Example/common.css doesn't exist, and User:Example moves User:Example/common (not a CSS page, not in CSS contentmodel) to User:Example/common.css? I'm able to move a sandbox to a new css page: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Andy_M._Wang/sandbox&action=history

It would be nice to ensure that a user cannot move their js/css subpage to some other title, change the contentmodel there, and move it back, right? How does this affect current pages that have a .js or .css extension that are wikitext resulting from moves?

This comment was removed by andymw.

@Bawolff @Legoktm Given the scenarios I tried above, I think it's very difficult to ensure that titles have a default contentmodel. Page moves (like CSS to JS, or even default wikitext to a css subpage) is a workaround to the proposed function.

What happens if User:Example/common.css doesn't exist, and User:Example moves User:Example/common (not a CSS page, not in CSS contentmodel) to User:Example/common.css? I'm able to move a sandbox to a new css page: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Andy_M._Wang/sandbox&action=history

It would be nice to ensure that a user cannot move their js/css subpage to some other title, change the contentmodel there, and move it back, right? How does this affect current pages that have a .js or .css extension that are wikitext resulting from moves?

I guess we would see if the current content model can be converted (losslessly) to the required one. If so do that, if not refuse to move the page.

I guess we would see if the current content model can be converted (losslessly) to the required one. If so do that, if not refuse to move the page.

Makes sense. I think this would solve the other (possible?) issue that Modules (Scribunto) can be moved to the Wikipedia space and stay Scribunto. After this, I believe that module moves would be converted to wikitext.

IKhitron added a subscriber: IKhitron.EditedOct 2 2017, 12:14 AM
@Bawolff wrote:

I don't think there is any legitimate reason ever to have user js subpage not be a Javascript content model.

I do think. There are a lot of wikitext articles *.js. Their drafts will be user subpages with such a name pattern, but not javascript contentmodel, for example User:Bawolff/Node.js.