It should be noted, though, that only the new API for user options allows this. The GUI user preferences form will ignore any user option that is not added using the GetPreferences hook.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Sep 10, 2012 at 6:11 PM, Krinkle krinklemail@gmail.com wrote:
I think MZMcBride is referring to the fact[1] that the current preferences backend stores whatever it is given, even keys that don't exist anywhere and have no registry or default value.
This is inherited by how User.php implements setOption(), saveSettings() and saveOptions().
I personally think it is a bad thing to allow arbitrary stuff with no documentation and conventions to be stored through a simple api.php request into the user_options table.
On the other hand, do keep in mind that Gadgets (not the gadget scripts but the extension itself) (ab)uses this by checking whether there is a preference is set for "gadget-" + gadgetId.
It may be useful to require a server side registry, for Gadgets this wouldn't be an issue since all gadget Ids are known. For backwards compatibility array_keys of wgDefaultOptions could be registered automatically / implicitly.
-- Krinkle
On Sep 10, 2012, at 5:23 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Someone can feel free to correct me if I'm wrong, but currently user preferences uses an HTMLForm object to handle everything, and new preferences can be added arbitrarily using the GetPreferences hook. I'd imagine this will definitely be supported in the future as it is the primary way for extensions to add new user preferences.
As such, the only real restriction on the key size is that of the
database,
which is currently varbinary(32). Since each preference gets its own row, there is no limit on how many extensions can be added (unless you count limits on the size of the database).
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Sep 9, 2012 at 8:37 PM, MZMcBride z@mzmcbride.com wrote:
Forwarding from <
https://bugzilla.wikimedia.org/show_bug.cgi?id=40124#c0%3E:
A lot more functionality around user preferences was added with https://gerrit.wikimedia.org/r/#/c/5126/
Thank you for that.
Recently I found that one can add new options (''keys''). This is very useful for Community scripts. So I hope this was intentional behaviour
and
this bug is about clarifying that.
What in particular, I'd like to know is:
Will it be supported in future?
Which max. size (i.e. how many bytes) can the pref have?
How many prefs can be added?
Is it possible to remove one particular pref without having to reset
all?
Again, it would be really useful if I could get started using this
feature.
Currently I have to publicly store user prefs for my scripts using ( https://commons.wikimedia.org/wiki/MediaWiki:Gadget-SettingsManager.js) in their common or <skin>.js. Having a private place to store them would be great, especially because one can retrieve them with both, the API and
they
are by default in mw.user.options JavaScript RL module.
Any help in answering these questions on this list and/or on the bug
would
be great.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l