Thanks to Gergo for the clarification! Here’s what I find from further testing:
(1) Gergo is correct that a default value specified in onGetPreferences doesn’t take
effect until the user goes to the Preferences form.
(2) If DefaultUserOptions does specify a default value, and onGetPreferences does not,
then the default from DefaultUserOptions is displayed correctly in the Preferences form.
(3) If DefaultUserOptions and onGetPreferences both specify default values, and they
differ, onGetPreferences wins. I believe this scenario should be avoided. Having an option
whose default is “X” before you go to the Preferences form, but changes to “Y” when you do
go there, could give the user the false impression that the value has been “Y” all along,
and lead to confusion and instability.
(4) If DefaultUserOptions and $wgDefaultUserOptions both specify default values, and they
differ, $wgDefaultUserOptions wins. This might be useful for a wiki to change the behavior
of an extension without modifying the extension itself. Maybe there should be a way to do
this without using a global variable; I don’t know if there is such a way.
(5) Preferences with 'type' => 'info' are exceptional. They involve
nothing in DefaultUserOptions, and a crash may occur unless 'default' is specified
in onGetPreferences. They seem to involve HTMLInfoField, which is “An information field
(text blob), not a proper input” per
https://doc.wikimedia.org/mediawiki-core/master/php/classHTMLInfoField.html .
Question: When does it make sense to specify a default in onGetPreferences?
Tentative answer: Never [except for 'type' => 'info' as in (5) above].
If it agrees with DefaultUserOptions, it’s redundant; if it disagrees, it’s a bug.
Tentative conclusion: The documentation in
https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences is wrong, specifically this
line in the example:
'default' => 'choice1', // A 'default' key is required!
A default is NOT required there. If there’s a default in onGetPreferences but not in
DefaultUserOptions, there’s a bug per (1) above. If a default in onGetPreferences agrees
with DefaultUserOptions, it’s redundant per (2) above. If it disagrees, there’s a bug per
(3) above.
The CodeEditor extension specifies the default for 'usecodeeditor' in both
DefaultUserOptions and getPreferences. Should that redundancy be removed, to serve as a
better example and to avoid bugs if it’s changed in one place but not the other?
Can anyone provide further confirmation or clarification? I’ll update the documentation
soon based on the above, unless it turns out I’m wrong again.
Tom
On Mar 17, 2019, at 5:49 PM, Gergo Tisza
<gtisza(a)wikimedia.org> wrote:
GetPreferences does not set defaults; it provides form elements for the
preferences form. The 'default' field there will be the default value in
the form; it won't actually get added to user preferences until the user
goes there and saves the form. Until then (and for anonymous users) the
value from DefaultUserOptions will be used.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wenlin(a)wenlin.com Web:
http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯