Page MenuHomePhabricator

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

Description

Details

Reference
bz50039

Related Objects

StatusAssignedTask
OpenNone
ResolvedJdforrester-WMF
ResolvedUmherirrender
OpenNone
ResolvedKrinkle
ResolvedNone
Resolvedphuedx
DeclinedNone
ResolvedNemo_bis
Resolvedmatmarex
Resolvedmatmarex
ResolvedNone
InvalidNone
StalledNone
StalledNone
ResolvedNemo_bis
ResolvedNone
DeclinedNone
Resolved Mattflaschen-WMF
ResolvedBawolff
DeclinedNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedSBisson
OpenNone
ResolvedJdforrester-WMF
Resolved jmatazzoni
ResolvedPetar.petkovic
DeclinedNone
OpenParent5446
ResolvedNone
OpenEugene233
OpenNone
OpenNone
Resolvedaaron
ResolvedTheDJ
Resolveddmaza
Resolveddmaza
Invaliddmaza
ResolvedNone
Resolveddbarratt
Resolveddmaza
Resolveddmaza
ResolvedKrinkle

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:53 AM
bzimport set Reference to bz50039.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle created this task.Jun 23 2013, 8:49 AM

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).

Liuxinyu970226 set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 11 2015, 11:42 AM
Krinkle removed a subscriber: Krinkle.Mar 30 2016, 2:42 AM
Liuxinyu970226 added a subscriber: Liuxinyu970226.