Page MenuHomePhabricator

Proposed changes to default settings (DefaultSettings.php) (tracking)
Open, MediumPublic

Description

Details

Reference
bz50039

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedJdforrester-WMF
ResolvedUmherirrender
ResolvedJdforrester-WMF
ResolvedKrinkle
ResolvedNone
Resolvedphuedx
DeclinedNone
ResolvedNemo_bis
Resolvedmatmarex
Resolvedmatmarex
ResolvedNone
InvalidNone
ResolvedAmmarpad
DeclinedNone
ResolvedNemo_bis
ResolvedNone
DeclinedNone
Resolved Mattflaschen-WMF
ResolvedBawolff
DeclinedNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedSBisson
OpenNone
ResolvedJdforrester-WMF
Resolved jmatazzoni
Resolved Petar.petkovic
DeclinedNone
ResolvedParent5446
ResolvedNone
DeclinedNone
OpenNone
OpenNone
Resolvedaaron
ResolvedTheDJ
Resolveddmaza
Resolveddmaza
Invaliddmaza
ResolvedNone
Resolveddbarratt
Resolveddmaza
Resolveddmaza
ResolvedKrinkle

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:53 AM
bzimport set Reference to bz50039.
bzimport added a subscriber: Unknown Object (MLST).

This bug tracks proposed changes to default settings.

My understanding is this is intended to refer to everything in DefaultSettings.php, not just preferences.

Is that correct? If so, we should make one specifically for default preferences.

(In reply to comment #2)

Is that correct? If so, we should make one specifically for default
preferences.

Why?

(In reply to comment #3)

(In reply to comment #2)

Is that correct? If so, we should make one specifically for default
preferences.

Default user preferences ($wgDefaultUserOptions) are a distinct subset of what's in DefaultSettings.php. They're end-user focused and they appear in a particular area of the interface, unless they're hidden.

I think this will make it a little easier to organize the bug relationships.

(In reply to comment #4)

Default user preferences ($wgDefaultUserOptions) are a distinct subset of
what's in DefaultSettings.php. They're end-user focused and they appear in a
particular area of the interface, unless they're hidden.

Most of the blockers I see here are quite end-user focused, I don't understand the distinction. It's also not very easy to apply, for instance $wgEnotifMinorEdits is not $wgDefaultUserOptions but it makes one more preference available so I would have no idea where to put it with your proposal. Competing tracking bugs with unclear scope are a nightmare.

I think this will make it a little easier to organize the bug relationships.

Like?

(In reply to comment #5)tle easier to organize the bug relationships.

Like?

For instance, if this is intended for everything in DefaultSettings.php, it does not really make sense to block bug 58223 ("Improvements to the layout and contents of Special:Preferences") (since e.g. $wgIncludeLegacyJavaScript has nothing to do with Special:Preferences).

But it would make sense for a bug about default user preferences to block bug 58223.

I don't see any reason for bug 58223 to be added as dependency of this or any other preferences tracking bug (bug 58229 was closed).