Page MenuHomePhabricator

Create and deploy configuration change to enable TemplateStyles on German Wikipedia on 2018-04-04
Closed, ResolvedPublic

Description

We've reached a community consensus for enabling TemplateStyles in de.Wiki
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/TemplateStyles#Frage

And we are really looking forward to use "real CSS" to fix problems like these:
https://wiki.martinkraft.net/mobileProbleme.html
https://wiki.martinkraft.net/mobileProblemePortale.html
https://wiki.martinkraft.net/whyWeNeedCss.html

Related Objects

StatusAssignedTask
OpenNone
OpenNone
ResolvedNone
DuplicateNone
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
ResolvedJdlrobson
DuplicateNone
DuplicateNone
OpenNone
OpenNone
StalledNone
InvalidNone
OpenNone
OpenNone
ResolvedTheDJ
ResolvedTheDJ
InvalidNone
OpenNone
ResolvedTheDJ
OpenNone
ResolvedJdlrobson
OpenJdlrobson
OpenJdlrobson
ResolvedTgr
ResolvedTgr
ResolvedTgr

Event Timeline

MartinK triaged this task as Normal priority.Mar 28 2018, 9:29 AM
MartinK created this task.

According to T181188, dewiki is already using RemexHtml, so there shouldn't be any technical blockers.

TemplateStyles is being deployed to all Wikivoyages today. I'll schedule dewiki for next week.

Deskana renamed this task from Request to activate TemplateStyles on de.wikipedia.org to Create and deploy configuration change to enable TemplateStyles on German Wikipedia on 2018-04-03.Mar 28 2018, 12:49 PM
Deskana reassigned this task from dr0ptp4kt to Tgr.

Change 422414 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable TemplateStyles on dewiki

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

Tgr added a comment.Mar 28 2018, 4:15 PM

Unchecked CSS changes will not be hidden for readers; filed T190945: FlaggedRevs is not compatible with TemplateStyles. Please advise whether that should be a blocker.

Unchecked CSS changes will not be hidden for readers; filed T190945: TemplateStyles is not comaptible with FlaggedRevs. Please advise whether that should be a blocker.

One could bypass that problem by making css-pages editable only by users with right "Sichter" (editor). For example by using a "Dreiviertelsperre" (editeditorprotected).

T190945 shouldn't be a blocker.
In de.Wiki only admins are allowed to change the content type (to sanitized CSS). So they are in control of the number and purpose of CSS documents and their protection status.
By the way: Although most of the templates aren't protected either, we didn't experience a lot of vandalism there. So why should CSS be worse?

JJMC89 added a subscriber: JJMC89.Mar 28 2018, 5:08 PM

In de.Wiki only admins are allowed to change the content type (to sanitized CSS). So they are in control of the number and purpose of CSS documents and their protection status.

You don't need the editcontentmodel to create a page with the Sanitized CSS content model.

For example, Template:Example/style.css does not exist on testwiki, but if created it will have the Sanitized CSS content model.(1)

Tgr added a comment.Mar 28 2018, 5:09 PM

In de.Wiki only admins are allowed to change the content type (to sanitized CSS).

TemplateStyles sets the default content model to sanitized-css for .css pages in the Template: namespace. I think that would surpass such permission checks.

Although most of the templates aren't protected either, we didn't experience a lot of vandalism there. So why should CSS be worse?

Template vandalism would be prevented by FlaggedRevs and CSS vandalism wouldn't. Judging from the experiences of wikis where there is no FlaggedRevs, template vandalism is not really a problem even without that extra layer of defense, so personally I wouldn't worry about it.

See also T187729 for lots of related discussion.

In de.Wiki only admins are allowed to change the content type (to sanitized CSS).

TemplateStyles sets the default content model to sanitized-css for .css pages in the Template: namespace. I think that would surpass such permission checks.

On the other hand, setting $wgTemplateStylesNamespaces to the empty array would prevent that and so require the explicit content model change.

Template vandalism would be prevented by FlaggedRevs and CSS vandalism wouldn't.

Technically FlaggedRevs doesn't prevent template vandalism, it just hides it from (most?) readers. Assuming someone who can stabilize the template doesn't do so without noticing the vandalism, anyway. I suppose it could "prevent" it by being a disincentive.

IMHO CSS (especially sanitised CSS) does not offer a lot of fun options to vandals. From a vandals point of view it is probably way more satisfying to lease some swear words in articles than changing the font-size.
And if something like this happens, it can be handled easily by 3/4-protecting the CSS files.

Cirdan added a comment.EditedMar 28 2018, 7:27 PM

I don't think we need special protection or flagged revisions for CSS pages. As far as I'm aware, there is no such protection e.g. for Lua modules and I have yet to come across a case of Lua vandalism. Similarly to heavily used templates, also the CSS pages will be 1/2-protected if the need arises.

Let's assume good faith editors, there is nothing a vandal can break which cannot be solved by every other community member by means of a simple rollback.

DC awarded a token.Mar 31 2018, 3:38 PM
DC added a subscriber: DC.
Deskana renamed this task from Create and deploy configuration change to enable TemplateStyles on German Wikipedia on 2018-04-03 to Create and deploy configuration change to enable TemplateStyles on German Wikipedia on 2018-04-04.Apr 3 2018, 6:29 PM

This is scheduled for tomorrow now.

Change 422414 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable TemplateStyles on dewiki

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

Mentioned in SAL (#wikimedia-operations) [2018-04-04T17:26:07Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:422414]] Enable TemplateStyles on dewiki T190910 (duration: 01m 17s)

ggellerman moved this task from Up next to Done on the TemplateStyles board.Apr 4 2018, 9:51 PM
Tgr added a comment.Apr 4 2018, 10:01 PM

On the other hand, setting $wgTemplateStylesNamespaces to the empty array would prevent that and so require the explicit content model change.

That is in fact the case, although for a different reason (dewiki has $wgNamespacesWithSubpages[NS_TEMPLATE] set to false).

So to use TemplateStyles one has to use Special:ChangeContentModel and set the style page content model to sanitized CSS, which is pretty bad user experience (including that the code editor is not activated when creating a new css page).

That is in fact the case, although for a different reason (dewiki has $wgNamespacesWithSubpages[NS_TEMPLATE] set to false).

That's unexpected.

(including that the code editor is not activated when creating a new css page).

Do Special:ChangeContentModel first, then edit it.

Deskana closed this task as Resolved.Apr 5 2018, 10:26 AM
Tgr reopened this task as Open.EditedApr 5 2018, 10:44 AM

Default content model handling should be fixed one way or other. Either by removing the override for $wgNamespacesWithSubpages[NS_TEMPLATE] (dewiki does use subpages, not sure why the software should pretend they are not subpages), or by removing the subpage check from TemplateStyles (I don't think using Template:Foo + Template:Foo.css is necessarily a worse pattern than using Template:Foo + Template:Foo/styles.css, so this would make sense on it's own), or if nothing else works we should add a hook specific to dewiki to the configuration.

Deskana closed this task as Resolved.Apr 6 2018, 10:12 AM

@Tgr and I talked yesterday and decided to close this as resolved since the scope of this task was to deploy the extension, and that is now done. The issue Gergő mentioned above is being tracked in T191612.