Page MenuHomePhabricator

Should we allow sanitized-css (TemplateStyles) content under titles where it is not the default content model?
Open, LowPublic

Description

sanitized-css content (the CSS stylesheets used by TemplateStyles) can only be created in the Template namespace, with a .css extension. But there are ways other titles can end up with such content:

  • create as wikitext, change content model via Special:ChangeContentModel (needs admin rights)
  • create in Template namespace then move (anyone can do it)
  • create via the API and set the contentmodel parameter (anyone can do it)

Given that even most admins don't understand the concept of content models, this has a high potential for confusing editors. At the same time there does not seem much use for it; should we just restrict sanitized-css to Template:*.css?

(A somewhat related issue is that moving pages without leaving a redirect is normally an admin-level feature, but it will happen for everyone with template styles because the default content model is not wikitext so a redirect cannot be created. That's again bound to confuse people.)

See also:

Event Timeline

Tgr created this task.Sep 28 2017, 9:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 28 2017, 9:48 PM
JJMC89 added a subscriber: JJMC89.EditedSep 28 2017, 10:47 PM
  • create via the API and set the contentmodel parameter (anyone can do it)

I think this requires the editcontentmodel right outside of Template:*/*.css.

I tested this in the en.wikipedia.beta.wmflabs.org API sandbox for sanitized-css and on enwiki for json and css.

Request
{
	"action": "edit",
	"title": "User:JJMC89/sandbox/sanitized-css",
	"text": ".my-class { dispaly: none; }",
	"contentmodel": "sanitized-css",
	"token": "6e0365823f732a1a14f7111cc60daf9659cd7761+\\",
	"formatversion": "latest"
}
Response
{
    "error": {
        "code": "cantchangecontentmodel",
        "info": "You don't have permission to change the content model of a page.",
        "docref": "See https://en.wikipedia.beta.wmflabs.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
    },
    "servedby": "deployment-mediawiki05"
}
Anomie added a subscriber: Anomie.EditedSep 29 2017, 2:31 PM

Yes, we should allow it. One of the points of ContentHandler was to remove the dependence on magic titles to know what type a page is, let's not take a step backwards in trying to reintroduce such restrictions.

Disallowing it would also cause trouble for several of the use cases described in T176269, e.g. using a user subpage as a sandbox template or using a Project-namespace page as a template.

Given that even most admins don't understand the concept of content models, this has a high potential for confusing editors.

If they don't understand them, it's because they haven't really had to understand them yet. They'll learn quickly if they need to know, just like they learn wikitext, Lua, how to protect and block, and so on.

(A somewhat related issue is that moving pages without leaving a redirect is normally an admin-level feature, but it will happen for everyone with template styles because the default content model is not wikitext so a redirect cannot be created. That's again bound to confuse people.)

That already happens with other content models that already exist. I think you're worrying far too much.

  • create via the API and set the contentmodel parameter (anyone can do it)

I think this requires the editcontentmodel right outside of Template:*/*.css.

Indeed. The check is in EditPage.php, lines 1911–1933.

BTW, there's nothing special about the API in this. The web UI edit form has hidden fields named 'model' and 'format' that can be changed for the same effect.

Tgr updated the task description. (Show Details)Oct 1 2017, 11:33 PM
Tgr added a comment.Oct 1 2017, 11:46 PM

One of the points of ContentHandler was to remove the dependence on magic titles to know what type a page is, let's not take a step backwards in trying to reintroduce such restrictions.

Such restrictions are clearly intended, otherwise ContentHandler::canBeUsedOn would not exist. From an internal point of view, not wanting titles to be the *mechanism* of determining the content model makes sense, of course. That doesn't say anything about whether restricting certain models to certain titles is a good thing or not.

Disallowing it would also cause trouble for several of the use cases described in T176269, e.g. using a user subpage as a sandbox template or using a Project-namespace page as a template.

If we want to support those use cases, then sanitized-css should be the default content model in those namespaces for some title (say *.tcss because *.css is already used for other things). Supporting template CSS in the user namespace but not allowing them to be created in any other way than creating in the template namespace and moving seems a bit ridiculous.

Anomie added a comment.Oct 2 2017, 1:48 PM

Such restrictions are clearly intended, otherwise ContentHandler::canBeUsedOn would not exist.

The intended use of ContentHandler::canBeUsedOn seems to be for restricting content handlers to specific namespaces, e.g. Wikibase entities in the entity namespace only. The documentation also contemplates using it for extensions in File-namespace pages.

If we want to support those use cases, then sanitized-css should be the default content model in those namespaces for some title (say *.tcss because *.css is already used for other things).

So now you're making it even more complicated.

Supporting template CSS in the user namespace but not allowing them to be created in any other way than creating in the template namespace and moving seems a bit ridiculous.

Special:ChangeContentModel, the API action=edit parameter, and the hidden field in the web UI all exist, although use of these are all restricted by a user right.

Disallowing such moves entirely is more likely to cause problems that can't be worked around in a satisfactory manner, e.g. it would be impossible to properly userify a template that has TemplateStyles CSS.

Anomie moved this task from Up next to Non-code on the TemplateStyles board.Jan 29 2018, 4:15 AM
ggellerman moved this task from Non-code to Up next on the TemplateStyles board.Mar 1 2018, 5:40 PM
Deskana triaged this task as Low priority.Apr 11 2018, 12:48 PM
Deskana added a subscriber: Deskana.

This is not an immediate priority for the initial deployment of TemplateStyles.

Just a note that I tried to create it using the api (I don't have editcontentmodel rights) and it wouldn't let me. I don't think that is a possibility for "anyone" to do as stated in the task

Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptJul 22 2019, 2:20 AM