Page MenuHomePhabricator

Huggle should store user preferences using the userjs- preference keys instead of CSS pages
Open, LowestPublic

Description

Per T76204#799990, Huggle should the userjs- preference keys¹ instead of CSS pages.

¹ https://gerrit.wikimedia.org/r/#/c/37503/

Event Timeline

He7d3r created this task.Dec 2 2014, 12:38 AM
He7d3r raised the priority of this task from to Needs Triage.
He7d3r updated the task description. (Show Details)
He7d3r changed Security from none to None.
He7d3r added a project: Huggle.
He7d3r added a subscriber: He7d3r.
Se4598 triaged this task as Low priority.EditedDec 2 2014, 12:18 PM
Se4598 added a subscriber: Se4598.

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.

Petrb lowered the priority of this task from Low to Lowest.Dec 2 2014, 12:21 PM
Petrb added a subscriber: Petrb.

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?

Petrb moved this task from Backlog to Need discussion on the Huggle board.Dec 2 2014, 12:22 PM
Petrb added a comment.Dec 2 2014, 12:24 PM

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)

That sounds good to me

Currently our config is stored on a CSS-page, but isn't CSS. This task is a request to move the user configuration into (hidden) user options (stored by mediawiki) with keys prefixed with "userjs-". You can e.g. easily get and set the options via javascript on a wiki page.

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.

Petrb added a comment.Dec 2 2014, 12:54 PM

That would as inefficient as everything that contains java in its name :P

Petrb added a comment.Dec 2 2014, 12:55 PM

Like replacing 1 query with 80+ queries is a bad idea for me

Se4598 added a comment.Dec 2 2014, 1:02 PM

Like replacing 1 query with 80+ queries is a bad idea for me

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...

He7d3r added a comment.Dec 2 2014, 1:42 PM

That would as inefficient as everything that contains java in its name :P

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?

Petrb added a comment.EditedDec 2 2014, 2:01 PM

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)
-- Ugly
? 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

Petrb added a comment.Dec 2 2014, 2:04 PM

Fucking remarkup of phabricator is bugged, that circle stands for minus, but it seems to ignore that I disabled it

matmarex added a subscriber: matmarex.EditedDec 2 2014, 2:04 PM

Yes, action=query&meta=userinfo&uiprop=options to get, action=options&change=… to set.

matmarex removed a subscriber: matmarex.Dec 2 2014, 2:05 PM

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.

Restricted Application added subscribers: Luke081515, Aklapper. · View Herald TranscriptAug 22 2015, 8:32 PM