VOOZH about

URL: https://phabricator.wikimedia.org/T52039

⇱ ⚓ T52039 Proposed changes to default settings (tracking)

Maniphest T52039

Proposed changes to default settings (tracking)
Open, MediumPublic

Description

Details

Reference
bz50039

Related Objects

StatusSubtypeAssignedTask
OpenNoneT52039 Proposed changes to default settings (tracking)
ResolvedJdforrester-WMFT35837 Set $wgLegacyJavaScriptGlobals = false by default
ResolvedKrinkleT58550 Show deprecation notices when accessing wg* JavaScript globals
ResolvedNoneT67011 Set $wgLegacyJavaScriptGlobals = false on test2wiki
ResolvedphuedxT177259 Collection using deprecated global variables
ResolvedJdforrester-WMFT35836 Set $wgIncludeLegacyJavaScript = false by default
ResolvedUmherirrenderT37858 Migrate legacy redirectToFragment to modern structure
DeclinedNoneT32401 Create option to disable interface animations
ResolvedNemo_bisT37785 Make enhanced recentchanges the default
ResolvedmatmarexT19616 Enhanced recent changes JavaScript: clicking arrow should keep it in focus, keyboard accessibility
ResolvedmatmarexT53749 jquery.makeCollapsible() on enhanced watchlist/recentchanges annoyingly slow
ResolvedNoneT51626 jquery.makeCollapsible causes memory leaks in all major browsers
InvalidNoneT42621 Usability should be default (tracking)
ResolvedAmmarpadT42622 Deprecate and remove $wgUseTwoButtonsSearchForm from core
DeclinedNoneT44594 Stop using rel=nofollow on all external links
ResolvedNemo_bisT47022 Make preference "Email me when a page or file on my watchlist is changed" true by default
ResolvedNoneT47020 Make preferences "Add pages I create and files I upload to my watchlist" and "pages and files I edit" true by default
DeclinedNoneT52040 Set $wgWellFormedXml = false by default
Resolved• Mattflaschen-WMFT54210 closeElement causes UI breakage when $wgWellFormedXml = false;, does not conform to spec
ResolvedBawolffT51232 $wgWellFormedXml = false; breaks our EditPage broken bot protection in edittoken
DeclinedNoneT53941 Merge "Recent changes" and "Watchlist" preferences tabs
ResolvedParent5446T56948 Kill $wgPasswordSalt
ResolvedNoneT61114 Maintenance script to convert from unsalted (:A:) to salted passwords (:B:)
DeclinedNoneT71301 Remove "viewmywatchlist" user right from anonymous users
OpenFeatureNoneT70298 Give sysops deletelogentry and deleterevision rights by default
OpenNoneT20674 History page excessively cluttered, esp. with suppressrevision
ResolvedaaronT20827 PageHistory.php deleterevision <form> breaks on ugly URL wikis
ResolvedTheDJT97711 Correct default of wgNoReplyAddress
Resolved• dmazaT191922 Enable $wgCookieSetOnIpBlock by default after the IP cookie block feature is fully tested and released
Resolved• dmazaT152462 Add cookie when blocking anonymous users
Invalid• dmazaT191542 Implement event logging for IP cookie blocks to make sure it's working reasonably
ResolvedNoneT192016 Release anon cookie blocking on test.wikipedia.org
ResolveddbarrattT192017 Enable anon cookie blocking on all Wikimedia wikis
Resolved• dmazaT195930 Enable set cookie with IP/IP-Range blocks when blocking logged-out users
Resolved• dmazaT196121 Enable set cookie with IP/IP-Range blocks when blocking logged-out users on itwiki
ResolvedKrinkleT31374 Set default for $wgVectorUseSimpleSearch to true
OpenNoneT172350 Consolidate preferences for all 'Change Monitoring' pages
OpenNoneT172349 Consolidate Preferences: New UX on RC but NOT Watchlist (option #2)
OpenNoneT172352 Consolidate Preferences: New UX on RC AND Watchlist (option #1)
OpenNoneT172468 Consolidate preferences: Users who don’t have the new UX at all (option #3)
OpenNoneT172474 Consolidate preferences: new UX on Watchlist, but NOT RC page (option #4 )
ResolvedSBissonT172757 Migrate and convert user preferences to the new UX
OpenNoneT173542 When Watchlist graduates out of beta, put a Watchlist New Filters opt-out onto the Change Monitoring preferences tab
ResolvedJdforrester-WMFT168376 Put an opt-out for the New Filters onto the current (unconsolidated) RC Preferences page
Resolved• jmatazzoniT175314 Confirm beta opt-in and (graduated) New Filters opt-out are compatible
Resolved• Petar.petkovicT175765 Move New Filters opt-out preference to its own section on the page
DeclinedNoneT173716 Get some community input about the plan to consolidate preferences for all 'Change Monitoring' pages
OpenNoneT270058 Remove the $wgWatchlistExpiry feature flag

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

This bug tracks proposed changes to default settings.

Comment Actions

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.

Comment Actions

(In reply to comment #2)

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

Why?

Comment Actions

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

Comment Actions

(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?

Comment Actions

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

Comment Actions

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

Bugreporter renamed this task from Proposed changes to default settings (DefaultSettings.php) (tracking) to Proposed changes to default settings (tracking).May 8 2024, 1:23 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits