Board Thread:Code Review/@comment-24757753-20160428191600/@comment-24757753-20160429184326

Dessamator wrote: I've had ideas for tools that save stuff to the wiki as well, but the fact that everybody can mess with the settings is annoying, and it seemed bit strange to store JS in CSS. Using CSS as storage for js works, but I would suggest that you use commented CSS instead of plain JS to make sure it is at least a valid CSS file, and strip it when reading it.

The user's prefs page is stored (and interpreted) as JSON, rather than JS. I thought about wrapping it within a comment, but it didn't seem worth the code overhead to do so. A user would first have to go out of their way to specifically import the page as CSS (just like they could do with literally any page), and even then, it would be considered invalid CSS and ignored.

Although convention is to keep only CSS content on a page ending with '.css' (and that is generally a good convention to follow!), the page name is, ultimately, unrelated to what content will actually stored on the page.

Alternatively, you could always use local storage for the settings or if you want to go through extremes store it in a normal user subpage, and only parse the last revision made by the page's author (https://www.mediawiki.org/wiki/API:Revisions -> rvuser ). That would make it easier to ignore spam. Alternatively, you could try to convince staff to project .json pages in a user's subpages (https://phabricator.wikimedia.org/T76554).

The user page is only there as persistent storage - local storage is currently used to load/store/access the settings. It serves as a cache, to save having to request the user's pref page on every page load. Already, 2-3 network requests are needed to load whichever scripts/styles are requested by the user, and, in my opinion, that's 2-3 requests too many!

It probably wouldn't be worth trying to coax staff into adding .json user page protection. Storing prefs on any user page (whether a .css, .js, or .json page) is really just a workaround - ideally, Wikia might incorporate this patch from upstream MediaWiki, so any script settings could be correctly stored (via API) with the rest of the user preferences.

It might be a good idea to make a json gui that parses the configuration file and presents it in an interface for the users. There are probably hundreds of tools like that in github.

This is provided; it was part of the core purpose of this script. Visiting the page  presents the user with a UI practically identical to the current Gadgets UI.

I've set the script up on a testing wiki (preferences page) with some example definitions, if you'd like to get a sense of how it works from the user's perspective.