I don't see the advantage or equality of that way (from the huggle dev and user view)
This would mean a overhead in transferred html/js-code that is never used when using a wiki (preferences are transferred and set in the html-head).
Also HG-Prefs would not be seeable by others (most important version info but also other settings)
In addition there is currently no other way of disabling huggle access on per user basis, also for only a limited time amount ("enable:false"/ page delete + page protection)
what could be possible made if really needed to comment the whole content out to not have "invalid" css. (also the linked task/comments is/are mainly about .js-subpages, not css)
I'm leaning towards wontfix.
Can you be more specific about how we should do this and what should we exactly do? "Huggle should the userjs- preference keys" I don't even understand this :)
Do you mean we should use a different page or syntax for user config or what?
The external api for that is https://www.mediawiki.org/wiki/API:Options
Goal is to have no user config page, i.e. no "misused" JS or CSS subpage. As already stated I see there some problems in this approach.
Could be one query, see doc:
There are currently no hard limits on the length or contents of the value, nor is there a limit on the number of user options you can set at once. You can even store a complex tree of data within a user option by encoding it as a JSON string.
So storing and retrieving with one query (+1 token), all as text in one key, could be done. Bad, if they set a size limit.
Still why not simply a open, public wikipage, where even a user can change easily things manually in the config if needed and not sending the whole huggle config if you only want to read a article? IMHO currently (or ever) no change necessary...
How so? Could you clarify this? If it is about the prefix "userjs", see comments after T42124#425652.
Still why not simply a open, public wikipage...
I really dislike having my personal preferences in a public page instead of stored into my preferences.
... there is currently no other way of disabling huggle access on per user basis...
Isn't possible to do that using some MediaWiki user permissions? Or maybe using a (Black/White)list of users per wiki?
The problem here is that now we can easily load all configuration using 1 api query, is that possible with the mediawiki internal configuration mechanism? Is it even possible to easily export / import that?
PAGE vs USERJS
+ Single-query management
+ Versioning of configuration (you can revert back your previous configuration if you fucked up)
? People can see your options - I can't say if that is + or - these aren't private and it helps a lot when debugging some of their reports
+ You can easily transfer configuration from wiki to wiki
+ Sysops can disable your huggle access by protecting the page and changing enable:false
I see one big problem with userjs and that is that huggle doesn't have interface to change most of these settings and they can be changed now only by modifying the user's page directly using wiki interface. There is however no such a thing possible with this new thing, which would make some settings unchangeable to regular people who don't know how to modify these settings that would be now hidden somewhere inside mw.