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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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.