Last modified: 2014-03-25 11:54:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65033, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63033 - Clarify how 'default' option should be used for preferences
Clarify how 'default' option should be used for preferences
Status: NEW
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: documentation
  Show dependency treegraph
Reported: 2014-03-24 22:20 UTC by Tisza Gergő
Modified: 2014-03-25 11:54 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Tisza Gergő 2014-03-24 22:20:13 UTC
[[mw:Manual:Hooks/GetPreferences#Example]] suggests the 'default' form option is allowed (suggested, even) for preferences. Looking at Preferences::getPreferences() though, it seems that any default defined that way will override defaults coming from the database and thus cause the preferences form to display wrong data.

Steps to reproduce:
* in the GetPreferences hook add a preference with type=toggle, default=true
* log in as some user, set that preference to false, save
The preference will be correctly set to false but the form will continue to display true (checked checkbox).

The relevant code snippet from Preferences::getPreferences() ($info will be whatever was set by the hook):

// If it validates, set it as the default
if ( isset( $info['default'] ) ) {
	// Already set, no problem
} elseif ( !is_null( $prefFromUser ) && // Make sure we're not just pulling nothing
		$field->validate( $prefFromUser, $user->getOptions() ) === true ) {
	$info['default'] = $prefFromUser;
} elseif ( $field->validate( $globalDefault, $user->getOptions() ) === true ) {
	$info['default'] = $globalDefault;
} else {
	throw new MWException( "Global default '$globalDefault' is invalid for field $name" );

Not sure if this is a bug or a documentation issue, although I can't really imagine a use-case where overriding the user's actual preference setting with a hardcoded default would make sense, so overriding the default with user or global pref makes more sense. (Maybe the actual issue is that the 'default' field returned by getPreferences() is used to set the default input state in the preferences form, but has different semantics in other places?)

Note You need to log in before you can comment on or make changes to this bug.