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 <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: [email protected] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
