Maniphest T196427

Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitive
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	corey
	Jun 5 2018, 5:53 AM

Description

Yugipedia has been experiencing an issue for the last couple months where user CSS and JS were not being loaded. The following was set in our LocalSettings.php:

$wgAllowUserCSS = true;
$wgAllowUserJS = true;

As it turns out the variables are case-sensitive. Meaning that the default values of false were being applied.

Variables such as these should be case-insensitive in order to prevent confusion like this. Aliases should be added of the following form to DefaultSettings.php, or another appropriate location:

$wgAllowUserCSS = $wgAllowUserCss;
$wgAllowUserJS = $wgAllowUserJs;
$wgUseSiteCSS = $wgUseSiteCss;
$wgUseSiteJS = $wgUseSiteJs;

Event Timeline

corey created this task.Jun 5 2018, 5:53 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 5 2018, 5:53 AM

Note that this also applies to $wgUseSiteCss and $wgUseSiteJs.

That's not possible, we really cannot override PHP's behaviour in case sensitivity. See https://stackoverflow.com/questions/33273941/php-case-sensitivity for details. I'd advice you to look into documentation (https://www.mediawiki.org/wiki/Manual:$wgAllowUserCss) for details before configuration. It can prevent this problem and a lot of other problems.

Martin

That would be fine, if it weren't for the fact that multiple people, including several core MW devs, looked at our configuration and didn't spot the issue. This is a serious stumbling block for site admins since "CSS" and "JS" in these variables don't use their typical, expected capitalization.

Dinoguy1000 reopened this task as Open.Jun 5 2018, 6:30 AM

Dinoguy1000 updated the task description. (Show Details)

Urbanecm added a project: MediaWiki-Configuration.Jun 5 2018, 6:35 AM

Aklapper renamed this task from $wgAllowUserCss and $wgAllowUserJs are case-sensitive to Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitive.Jun 5 2018, 8:31 AM

I agree that the status quo where simple typos are hard to spot sucks. But as long as we continue to store configuration settings in PHP variables, then we'll have to play with PHP's rules about capitalization.

There are vague plans/ideas to allow for configuration in some kind of web UI, that would not have this issue.

• Vvjjkkii renamed this task from Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitive to 0mbaaaaaaa.Jul 1 2018, 1:05 AM

• Vvjjkkii reopened this task as Open.

• Vvjjkkii triaged this task as High priority.

• Vvjjkkii added projects: CheckUser, Connected-Open-Heritage-Batch-uploads (RAÄ-KMB_1_2017-02), Tamil-Sites, Gamepress, Hashtags, Jade, KartoEditor, Language-2018-Apr-June, New-Editor-Experiences, Mail, TCB-Team (now WMDE-TechWish).

• Vvjjkkii updated the task description. (Show Details)

• Vvjjkkii removed a subscriber: Aklapper.

CommunityTechBot renamed this task from 0mbaaaaaaa to Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitive.Jul 1 2018, 9:36 PM

CommunityTechBot closed this task as Invalid.

CommunityTechBot raised the priority of this task from High to Needs Triage.

CommunityTechBot updated the task description. (Show Details)

CommunityTechBot removed projects: TCB-Team (now WMDE-TechWish), Mail, New-Editor-Experiences, Language-2018-Apr-June, KartoEditor, Jade, Hashtags, Gamepress, Tamil-Sites, Connected-Open-Heritage-Batch-uploads (RAÄ-KMB_1_2017-02), CheckUser.

CommunityTechBot added a subscriber: Aklapper.

Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitiveClosed, InvalidPublicActions

Description

Event Timeline

Variable names themselves ($wgAllowUserCss and $wgAllowUserJs) should not be case-sensitive
Closed, InvalidPublic
Actions