User talk:Lunarity

Welcome
Hi, welcome to Wikia Developers Wiki! Thanks for your edit to the HideRail/code.js page.

Please leave a message on my talk page if I can help with anything! -- Grunny (Talk) 02:20, 10 August 2012

Thanks
Thanks. I've been planning to do this, but my first attempt at using extend failed miserably :P. Thanks for revamping the image lightbox thing, but I've found a better solution in someone's global js that I'm gonna implement, mainly because it doesn't trigger on videos ;). Best, - Kangaroopowah  ( Talk ) 04:57, August 12, 2012 (UTC)

Why?
Why Base64 encode? . -- Kangaroopowah  ( Talk ) 17:23, August 12, 2012 (UTC)


 * It's more network efficient when cold loading and keeps everything together. Loading the images from an URL on the server means that you end up with 1 request for the script then once the script is ready, it downloads 2 more files separately afterward which has a high latency if the images are important to the UI. It also helps keep the images in the browser cache; there's no risk that the browser will kick out the images and have to download them again. As long as the script itself is being cached, the images will be cached as well.


 * It's not something you always want to do. HideRail only uses 2 images and they're both only about 500 bytes each; if they were more than 2KiB then I wouldn't do that (base64 increases the size to about 133%). It's also important that the images are unique; they aren't being shared with any other scripts or already used in Wikia's UI. If the images were already being used in the Wiki interface by Wikia then they would already be cached making the optimisation pointless (counterproductive actually). There's also a small runtime cost from the  variable since the JS engine may keep a separate copy of the base64 strings in memory for each tab depending on the browser architecture, so you really don't want them to get very big.


 * It's a trade-off, so not always a good idea; for a small script like HideRail using a few small unique images, it works, if they were bigger, there were 30 of them, or I was using Wikia's images then it wouldn't. Lunarity 04:34, August 13, 2012 (UTC)

HideRail is not working
Hi Lunarity, since your last edit from August 19 & 20, the HideRail button (Expand Content) is not showing anymore, and I'm wondering, what happend?, I hope you please fix that. PS: I have added the Spanish language. Silver ( Discusión ) 06:17, August 21, 2012 (UTC).


 * I added the missing . Arkondi (talk) 09:27, August 21, 2012 (UTC)


 * Sorry about that. I'm usually much more careful; I retyped that code instead of copy-pasting from my Firefox scratchpad and broke it in the process. I didn't notice because I never Ctrl+R'd it. Lunarity 10:16, August 21, 2012 (UTC)

jQuery / JSHint
Thanks for polishing InactiveUsers/code.js! I especially like the log function. I'll so steal that for future projects :)

You also converted me to jshint btw. Or rather your global.js did :) The (former) code was tested with:

/*jshint jquery:true, browser:true, es5:true, devel:true, camelcase:true, curly:false, undef:true, unused:true, bitwise:true, eqeqeq:true, forin:true, immed:true, latedef:true, newcap:true, noarg:true, unused:true, regexp:true, strict:true, trailing:true */

But what's the point of changing  to  ? How is that "not recommended"? That's news to me... -- peco e s 07:06, September 02, 2012 (UTC)


 * is fine when y is a DOM node but not when it's a jQuery, the constructor function maps jQuerys to  internally but is ridiculously slow at doing that (something like 10% slower then just calling   directly). IIRC, the jQuery devs recommend against it for this reason, can't remember where I read it right now though, I think it was a blog post somewhere. Lunarity 07:36, September 2, 2012 (UTC)


 * Hm. Alright. I'll take your word for it. -- peco e s 08:23, September 02, 2012 (UTC)


 * Here's the jsperf, the site was down earlier so I couldn't check. Anyway, I checked and the actual problem with  is that it doesn't really set the internal context properly, the new jQuery's internal context is still the document. If you pass a DOM node as y then you actually change the context to a proper subtree of the page which can make jQuery more efficient. Practically speaking, it doesn't seem to make any difference in the general case so it probably doesn't matter. Lunarity 18:09, September 2, 2012 (UTC)


 * Ah. Jsperf! That site is quite the treasure-trove, isn't it? I haven't written any tests myself yet, so I did not think of it right away, but I've spent quite a bit of time there rummaging through other people's test. Some of that stuff is downright astonishing :) And some of it is completely nuts :D
 * Well from the jsperf it would seem that the .find method is indeed faster - but only marginally so - hardly enough to mention for anything that processes a handful of nodes...
 * But, uh, um, how do you arrive at the conclusion that jQuery doesn't use the second parameter as the context? The context of the resulting jQuery object is not much evidence to support that. That context was probably copied over from the second parameter's context. -- peco e s 18:36, September 02, 2012 (UTC)


 * I didn't mean that it doesn't constrain the query, it definitely does that. I was talking about, that definitely isn't set unless you use a DOM node. OTOH, the only thing I've been able to dig up is this, this and this so I must have misremembered whatever it was that I was thinking of. In the source it only seems to be used by .live which is deprecated anyway. Lunarity 19:32, September 2, 2012 (UTC)

DisplayClock - Custom format
Do you think it would have an impact on performance if you use (if it is available)? Arkondi (talk) 16:23, September 2, 2012 (UTC)


 * That function is non-standard, it only works in Firefox; I'd have to polyfill it in everything else. In order for the behaviour to be reliable in every browser, I need a strictly defined set of acceptable % flags otherwise someone will get clever and do something which works in their browser but not for anyone else [the month name flags like %a are a big trouble spot, there is no reliable way to get those in pure JS which means that it'll work with  but not in my reimplementation since I can't emulate it].
 * I've tried to offload all the heavy processing onto regexs and other native code which means it should be reasonably lightweight, I hope. I'll profile it later to check. Lunarity 16:55, September 2, 2012 (UTC)


 * I currently found out that wiki-language-localised monthnames can be found in the variables  and  . This information can also be found in the respective MediaWiki messages (ie. MediaWiki:January, MediaWiki:Jan, MediaWiki:Monday or MediaWiki:Mon). Perhaps this information is useful to you. —Preceding unsigned comment added by Arkondi (talk • contribs)


 * I'm aware of, the problem with it is:
 * They are based on the Wiki's language, not the User's language.
 * They only exist on MW 1.19, I'd have to AJAX them manually on MW 1.16.
 * The days (Monday, Tuesday, ...) don't seem to be available in a variable at all, those require AJAXing them.
 * I don't really want to implement AJAX functionality in the clock if I can avoid it, it feels like overkill for such a simple widget. Lunarity 20:01, September 2, 2012 (UTC)

SpoilerAlert
I'm in the process of rewriting SpoilerAlert right now. It's probably best if you hold off on editing until I'm done. There's no need to duplicate efforts. LocalStorage e.g. is already in my new codebase. Just wait a few more days and you can fix my broken code ;) -- peco e s 01:39, September 05, 2012 (UTC)


 * Okay. It still has problems but I wasn't actually planning on doing anything else to it; I've only removed the Cookies logic, fixed for MW1.19 and fixed all the JSHint errors. BTW, I saw your comment on the talk page about creating a custom preferences page, do you have somewhere set up to discuss that or is it still too early? Lunarity 02:15, September 5, 2012 (UTC)


 * The preferences stuff is here: w:c:pecoes:Preferences.js. You can test it on any Preferences page via the console with
 * EDIT: If you have any comments post them on my wall at my test wiki, please! w:c:pecoes:Message_wall:Pecoes
 * peco e s 02:36, September 05, 2012 (UTC) -- peco e s 02:39, September 05, 2012 (UTC)

RevealAnonIP
Hey, thanks for helping to work on this. I've left a note for you on the talk page because there also some changes I'd like to make in addition to yours.

Help
Any idea why my global.js is not working? 11:03, September 13, 2012 (UTC)


 * Can you be more specific? Is it not working anywhere? It loads correctly for me [although I did just discover another UserBadges bug]. If your Wiki is 1.16 then  isn't going to work, you'll have to use   instead. Lunarity 11:27, September 13, 2012 (UTC)
 * Aha, its working on 1.19.1
 * Ok. So basically whats the difference between mw.loader.load and importScriptURI? 11:51, September 13, 2012 (UTC)


 * Short version or long version? Short version: importScriptURI is older, mw.loader is the new hotness. Long version: importScriptURI is a dumb function that just loads an arbitrary URL as a script, mw.loader is an interface to ResourceLoader and provides all sorts of error checking, module loading, dependency management and so forth. Unfortunately, mw.loader was added in MediaWiki 1.17, Wikia is on a blend of 1.16 and 1.19 so it doesn't exist on about half of the Wikis. I recommend something like:


 * This will use mw.loader whenever possible but will stop it from imploding on 1.16. Lunarity 12:22, September 13, 2012 (UTC)
 * [Hows it? 12:36, September 13, 2012 (UTC)


 * Erm, yeah. You copied exactly what I typed but you were supposed to replace the '...' part of the URL with the location of your global.js that you already had. I fixed the example. Lunarity 12:39, September 13, 2012 (UTC)

Lol. Fixed. Thanx. 13:07, September 13, 2012 (UTC)

Just had one more question. Will this be faster or this? 13:12, September 13, 2012 (UTC)


 * importArticles is faster than transclusion. importArticles minifies the script code (eliminates comments and white space which makes it smaller so it downloads quicker). Lunarity 13:46, September 13, 2012 (UTC)

Just something that crossed my mind, what if I use $.getScript in global.js? 16:08, September 13, 2012 (UTC)


 * Yeah, that should work fine. jQuery is 1.7.2 across every Wiki, both 1.16 and 1.19. Lunarity 16:24, September 13, 2012 (UTC)

User Badges
How can I use two custom badges? I tried using: window.UserBadgesJS = { custom: { UltimateSupreme: ['Kage'] } }; window.UserBadgesJS = { custom: { Cerez365: ['Foolish Master'] } }; and window.UserBadgesJS = { custom: { UltimateSupreme: ['Kage'] } custom: { Cerez365: ['Foolish Master'] } }; But both don't seem to work. So how exactly can I do it? 13:40, September 14, 2012 (UTC)


 * You're overriding the entire block, you need to add multiple entries, not replace the entire thing with different copies:


 * Lunarity 15:20, September 14, 2012 (UTC)

Wikia has changed how user scripts work

 * "Wikia has disabled User Scripts from running on MediaWiki namespace pages that end with a '.JS' file extension"

Is this a future change you're aware of that will be coming in say next week's technical release -- or something that's already live? Because I definitely disagree that it's live. I'm staring at MediaWiki:Common.js on several different wikis right now, and my user scripts are running perfectly fine.


 * It's live right now, I filed a bug report and was told "this is intentional, it will be extended to user scripts in a coming update". The reason is that crappy user scripts that crash can screw up Wikia's editor making it impossible to edit the script page itself and disable the broken script. [It's the Edit page, BTW, not the view. Try editing MediaWiki:Common.js, your scripts won't load]. Lunarity 03:32, September 18, 2012 (UTC)


 * Does that mean user scripts won't run at all anymore on the edit page? -- peco e s 03:36, September 18, 2012 (UTC)


 * No, they still load on other Edit pages, just not the Edit pages for MediaWiki:Common|Wikia|Monobook.js or User:Name/wikia|monobook|common|global.js. They also load on all CSS pages, MediaWiki:whatever.css or not (That could be fun if you have  in your global.css; won't stop you from editing global.js but it will stop you from editing global.css).
 * Unfortunately, the entire point of AntiUnicruft was to intentionally run on Common.js, so that script is basically screwed now. I could work around it by AJAXing the page when manually prompted via a tool button added to the admin dashboard but that isn't as nice (and it means i18n again). Lunarity 03:46, September 18, 2012 (UTC)


 * Phew! That just scared me. Thanks for clearing that up :) Disabling those scripts while editing them, makes a lot of sense actually. -- peco e s 03:51, September 18, 2012 (UTC)

Oh, it's while editing - I didn't catch that part. While that does suck for AntiUnicruft... I suppose the point about user scripts breaking the editor kind of makes sense from a safety perspective, although it's not like you're completely out of options...
 * 1) Disable JavaScript in your browser and edit the page using Monobook.
 * 2) Create another account, admin yourself, edit the file.
 * 3) Use the MediaWiki API to make the edit.
 * 4) You can block the user script that is causing the problem (or any JavaScript/CSS files you want) by writing a one-line custom Adblock filter.


 * I know :). I've broken myself a couple of times, I just add an adblock rule for my global.js to disable it, refresh and fix it. That was the reason Wikia gave, I'll dig up the exact response:

Rappy, Sep 14 07:29 pm (UTC):

Hello,

Thanks for contacting Wikia. This is actually intentional. The editor relies heavily on JS to load and any errors in custom user or site-wide JS can result in them not being able to open the editor at all. This allows users to fix errors in user and site-wide JS that would otherwise not be editable.

Soon, this will be extended to user's global/common/wikia/monobook.js pages as well.

Timothy Collins

Wikia Community Support


 * Lunarity 04:41, September 18, 2012 (UTC)

User Tags
With the UserTags, can you help me with something?

I'm trying to add a "Retired bureaucrat" tag to w:c:bloons:User:Roberto1205, however, it doesn't display properly. At the moment, this is my wiki's js configuration:

Thanks! — SW8573 (Message Wall) 07:35, October 9, 2012 (UTC)


 * The problem is that you haven't defined any text for the 'retired bureaucrat' tag, you need to actually tell it what to display:


 * If you open your web console (Press Ctrl+Shift+K in Firefox, or Ctrl+Shift+J in Chrome) then you'll see a bunch of messages produced by the script, amongst them is " ". BTW:
 * The  module is actually , not  . Sorry about that, it was a typo in the article.
 * Is Zelda311 the original founder? You don't need to manually add the group to the real founder unless Wikia is failing to tag them properly (although the founder tag won't show up in monobook unless you add it manually, if that's what you're trying to do then it's fine).
 * You don't need to set  to true, it is automatically enabled in monobook for you [it's more efficient if you don't set it to true as it reduces the amount of data queried from the server in Oasis, although there aren't any bad side effects from leaving it as it is].
 * Is there a precise reason you're defining custom text for the bot-global group? The script has built-in text for that and will automatically translate, overriding it like that will break the translation feature (i.e. someone who has their language set to German will see the English "Global Bot" instead of German "Globaler Bot")
 * Lunarity 09:18, October 9, 2012 (UTC)


 * Has been fixed.
 * Yes, Zelda311 is the original founder, but his rights were revoked due to inactivity, and his tag disappeared along with the rights.
 * Will hopefully be fixed ASAP
 * As above.
 * Thanks for the help, Lunarity. — SW8573 (Talk) 11:23, October 9, 2012 (UTC)


 * All fixed/good now :D — SW8573 (Talk) 11:35, October 9, 2012 (UTC)

It isn't working. I get this error:  ~ 09:34, October 16, 2012 (UTC)


 * Interesting. Apparently neither Firefox or Internet Explorer care about the console object but Chrome does. Odd. It's fixed now, thanks. Lunarity 09:49, October 16, 2012 (UTC)


 * I was actually having this same issue a couple days ago when writing my own logging code. Apparently it's a feature -_-


 * Well, log/info/etc are behaving as prototypical members of the Console interface so they expect  as the   object rather than the   object. It makes sense and I understand exactly what happened, my problem is actually that Firefox didn't complain. The mistake was accessing a non-existent object property and using that  as the scope after I moved the real value to a closured variable instead, the mistake was pretty obvious when I re-read the code but Fx really should have let me know I'd screwed that up. Lunarity 02:51, October 17, 2012 (UTC)


 * I still think the fact that it throws an exception is a bit extreme... preferably' log shouldn't care about  and should work in every context. Why the heck does Console need to ever use its   value for anything? It's not like you would ever plausibly have more than one instance of a Console object, it might as well be static...


 * Every frame and IFRAME has its own  object with its own separate   object. Lunarity 03:23, October 17, 2012 (UTC)


 * Oh yeah, I forgot about those. And JavaScript is single threaded.

Thankyou
The things you wrote gave me a good help modifing my wiki (I'm an admin on my wiki). Anyway, thankyou!

Help with a depricated script
Actually, there is a script which got depricated after the upgarde and someone requested me to see if I can make it compitible. But currently I am away from my home at a place without comp. I am using mobile currently and dont think i would return any soon. If you could upgrade the script, it would be really helpful —UltimateSupreme (Talk) 08:31, October 24, 2012 (UTC)

I'm not clear on what's deprecated about it. The code is ugly but seems to work fine. I'm not aware of any upcoming changes that would break it, especially since it's used on Commons, but I cleaned it up anyway: Lunarity 09:53, October 24, 2012 (UTC)

Why is it so big?
Why is HideRail SO BIG??? ;) I'm not saying it's a bad thing, but couldn't you the same thing with less code? -- Kangaroopowah  ( Talk ) 20:35, October 27, 2012 (UTC)


 * A lot of things seem simple at first glance but aren't when you dig into it. Creating toolbar buttons is a major pain in the ass; most scripts are killed by the "Customize" button which clears the entire toolbar and replaces it. HideRail is the only script I know of which isn't killed by it. Then there's the popup menu, something which doesn't always exist depending on configuration so has to be handled conditionally which complicates things (the fact that I'm sticking checkboxes in it when Wikia's code is only designed to handle links doesn't help either).
 * The actual rail hiding part of the code is quite small, but the other parts are not so much. Creating plugins for the Wikia Editor, especially plugins which drill into the internals of other plugins, is complex. Widening and narrowing the editor involves a lot of CSS and editor internals fiddling to avoid the multitude of bugs that collapsing the Visual Editor's rail causes.
 * Then there's rewriting the SASS stylesheets, I originally did that the easy way but the easy way causes the page to unstyle and restyle which is ugly so that became quite complicated as well (cloning tags, rewriting the URLs, being able to add and remove the cloned tags from the document [in the specific right locations] to turn it on/off without reparsing the CSS files each time [which is noticeably slow because they're big]). Then I had a bunch of problems with transitions which were causing the page to animate as it loaded.
 * The current code is a WIP, I'm not happy with it but I was forced to release it by the WikiaGrid which broke the previous version. I'm still deciding on what I'm going to do about it but HideRail isn't high on my priority list at the moment. Basically, the code sucks, but it works, so I'm not devoting a lot of time to it currently. If you have an idea for making it simpler without losing any features then I'm willing to listen. Lunarity 21:54, October 27, 2012 (UTC)


 * There actually i a easier way to do the toolbar buttons... see VDA it's currently broken because after the grid layout, wikia changed the selector for the toolbar but once you fix that it should work. -- Kangaroopowah  ( Talk ) 16:53, October 31, 2012 (UTC)


 * That's doing what I already do, but less efficiently. It also has the same problem that most of these scripts have: it dies when you click "Customize" &gt; "Save". The simple plugin framework is interesting though, I might use that. Lunarity 19:06, October 31, 2012 (UTC)

SigCheck Modification
Is there a way for the script to be modified so that it will warn users if there are no categories on a page. I'm not much of a JS expert, but glancing over the SigCheck script I noticed that it has been written to only apply to forum and talk namespaces. If it could be written to work with categories, then I would hope it could be modified to work with any namespace except for Thread, Message Wall, and Blog (the first two don't need categories and the third gets the default category of "blogs posts.")

If it is possible, would you be able to write it? As I said I'm not much of a JS expert. Paper  Talk   My Work  15:49, October 28, 2012 (UTC)


 * You are prohibited from doing that. Wikia does not permit forced categorisation. Lunarity 16:17, October 28, 2012 (UTC)
 * Maybe they would allow if its only a confirmation box. Ask tem first but.— UltimateSupreme (Talk) 02:51, October 29, 2012 (UTC)

Mentor
Can you mentor me in the art of coding? Forsbern (talk) 17:30, October 28, 2012 (UTC)


 * I'm not sure I understand what you mean. If you have a specific question about a particular problem then you can ask on the support requests forum at Community. I don't think I'd make a very good tutor, and it isn't really something I want to do. You might want to try the administrator mentoring project, they might be able to help if you want general pointers. Lunarity 02:18, October 29, 2012 (UTC)

mw.util and Resource Loader
I noticed you tweaked a few scripts that depend on mw.util, including RevealAnonIP. What's the rationale behind this? Is this a fix for a demonstrable bug or a "let's play it safe" thing?


 * It's mainly just "play it safe" since a lot of code depends on  so it is usually loaded, but that is not guaranteed. I looked into how ResourceLoader works a few weeks ago and discovered that only mw.config, mw.messages, mw.libs, mw.loader and jQuery exist by default, everything else (mw.user, mw.util, mw.Api, etc) are optional modules that may or may not be loaded.
 * This has actually bitten me twice already; the first time was when I tried to use  in UserTags which "worked" until it turned out that it wasn't loaded in Chrome (  seems to be loaded by something inside Wikia's code in Firefox and Internet Explorer, but not in Chrome). The second time was when I tried to use   in MediaWiki:Common.js and I was getting random crashes due to something "not being a function". That turned out to be that sometimes   hadn't actually been loaded by the time Common.js ran so I had to explicit declare a dependency on   to fix it. As such, I've become much more careful about actually declaring my dependencies in scripts to the loader. Lunarity 05:08, October 30, 2012 (UTC)


 * Here's what I've figure out:


 * You can get a list of all registered modules with
 * You can query the state of modules on that list with
 * The possible states are: 'registered', 'loading', 'loaded', 'ready', 'error' or 'missing'
 * You can load registered(!) modules with .   takes three arguments: the module name, the callback in case of a success and lastly the callback in case of a failure. The last two parameters are optional.
 * You may also request modules with  but it doesn't offer callbacks which makes it inferior to.


 * -- peco e s 05:52, October 30, 2012 (UTC)

(the stuff that was here, was move below to module list)

(reset indent) Interesting. I've looked at Resource loader on mediawiki.org and done a little digging through the codebase on github, but I've never seen a typical case of a user or site-wide script fail because it runs before mw.util or some other mediawiki code. If you do have a reduced test case or really any example you can show me a script failing for lack of declared dependency, please share (especially if the failure happens after ). All empirical evidence in my experience points to the contrary, and I would like to be convinced by means of demonstrable bug.
 * ListFiles uses the same $.fn.makeCollapsible and I've never seen a single random crash.
 * Never saw RevealAnonIP fail while using mw.util for a month before you declared the dependency.
 * I do know by experience that if you place a script on a page with verbatim tags, the script will (highly reproducible) run before the mediawiki code or even jQuery are available simply because the script tag is higher up in the DOM than all the stuff dumped by resource loader. Not a huge concern, edge case.
 * I stuck  in my wikia.js on my test wiki and I've done about 30 page loads with action=view (I use Chrome) and never seen it fail.
 * I do see it fail with action=edit, it alerts undefined (and then you check the console later and mw.Api is defined). I place this as an edge case, just like scripts failing with verbatim tags. Wonky behavior is expected when the editor is opening. Delaying until  is sufficient.


 * The question is one of technical correctness vs pragmatism, or, more simply "future proofing" vs "what happens to work now". Failing to declare a dependency on mw.util is a bug by simple definition; the code is incorrect (an interface contract violation with ResourceLoader) if it does not. The ResourceLoader docs on MediaWiki.org say as much. Does the bug cause visible problems? Usually not; like I said, most code depends on mediawiki.util so it usually works because you can piggyback on other people doing the right thing while you don't.
 * The problem I had with Common.js was because I had the code in Common.js itself, ListFiles is loaded by importArticles/importScriptPage which induces a delay that makes the race condition much less likely. The fundamental problem is that if you look at what the page does, you'll see a giant asynchronous request for a ton of modules, one of which is . Since that request is issued before the browser starts executing Common.js (module=site), it will usually complete before the importArticles does so there's no problem. Code in Common.js itself does not have that luxury; sometimes Wikia's servers are slower than usual, then the race condition hits when things don't load in the perfect order and you get random crashes. (Tends to happen most frequently with a cold cache, hot cache files run instantly without the unpredictable download time race)
 * [I can assure you that  does not load consistently, on user profile pages it was absent on some wikis. Avatar Wiki was the biggest offender, try this page in Chrome,   "undefined"] Lunarity 08:17, October 30, 2012 (UTC)


 * Actually, I just double checked.  is a dependency of  . It has nothing to do with Chrome, it has to do with not being logged in. People who are logged in get , anons do not get  . Lunarity 08:37, October 30, 2012 (UTC)


 * Failing to declare a dependency on mw.util is a bug by simple definition ... The ResourceLoader docs on MediaWiki.org say as much
 * 1) Link please, quote please (spell it out explicitly for me, if you would be so kind). 2) Sounds like a reasonable concern if you're talking about system admin writing a MediaWiki Extension or Gadget which is included on his own MediaWiki installation. 3) Which is a different thing altogether from writing site-wide and user scripts on Wikia.


 * The fundamental problem is that if you look at what the page does, you'll see a giant asynchronous request for a ton of modules, one of which is .
 * Clarification: Are you suggesting that Resource Loader modules may load asynchronously? Because that's news to me. Here's what my knowledge tells me:
 * tags that are part of the HTML document (not dynamically inserted by another script, e.g. importArticles / importScriptPage) will load synchronously when parsed with the rest of the HTML.
 * Resource Loader (PHP server-side) dumps module tags, site-wide tags and user tags inside the tag near the bottom in the HTML document served to the browser. These will all load synchronously (unless you use importArticles / importScriptPage etc. to generate an asynchronous request).
 * Furthermore, the order of those tags in the HTML document is reliable and consistent. First comes Resource Loader modules. Then comes site-wide scripts (Common.js). Then comes user scripts (Username/global.js).
 * P.S. I checked avatar wiki in Chrome and mw.Api was consistently defined.


 * (Edit conflict) Your understanding of script tags is correct, however makeCollapsible is not a script tag. There is no script tag for the ResourceLoader modules in the HTML, the tag that downloads runs those ResourceLoader scripts is generated by  dynamically as the page is building. Unfortunately, the site scripts (Common.js) ARE script tags in the HTML so those do run synchronously, unlike the modules on which they depend. [Try doing a "View Source" and search for "makeCollapsible", you won't find it. It's a dynamic script tag created at runtime. You can find a script tag for   though, this is the root of the problem.]
 * Unfortunately, the MediaWiki site is badly organised so I can't dig up the exact page as I didn't bookmark it, there is this though which talks about gadgets being equivalent to extensions.
 * You missed my appendix,  is required for the Followed Pages feature. Try logging out, you'll find   disappears. Lunarity 09:57, October 30, 2012 (UTC)


 * Amendment/question to #2: Yes, but the Resource Loader module tag is:


 * And if you look inside of that file, you see:


 * ^ addSource creates a dynamic script tag, e.g. the "giant asynchronous request" you vaguely referred to?


 * adds entries to 's internal state, it doesn't download anything, merely says "go here when you want to download stuff". The purpose of the startup module (which I linked to on GitHub earlier, see ResourceLoaderStartUpModule) is to transfer all the wg vars, the resource loader module registrations and to automatically start downloading the mediawiki and jquery modules. It does not load any modules other than those 2.

 if(window.mw){ mw.loader.load(["mediawiki.page.startup","mediawiki.legacy.wikibits","mediawiki.legacy.ajax","mediawiki.user","mediawiki.page.ready","mediawiki.action.watch.ajax","mediawiki.legacy.mwsuggest"]); }
 * This is where the default module load comes from, this happens right before the modules=site and modules=user. This is supposed to be synchronous but it has known bugs (according to the code) where it is, in fact, NOT synchronous. Lunarity 09:57, October 30, 2012 (UTC)


 * I should point out that everything in that list above is decided by PHP extensions on the server, entries can be added or removed at any time by Wikia, and the stuff in it can vary from wiki to wiki depending on what extensions are active or not. Lunarity 10:05, October 30, 2012 (UTC)

(Reset indent) I found some more related materials: here and here. The MW devs are moving in to a "user script = ResourceLoader module using special page format" design, as mentioned here. The direction of movement is this bug which is about the actual implementation of gadgets = ResourceLoader modules. Lunarity 18:30, October 30, 2012 (UTC)

mw.util and Resource Loader, part 2

 * "Your understanding of script tags is correct, however ... There is no script tag for the ResourceLoader modules in the HTML, the tag that downloads runs those ResourceLoader scripts is generated by  dynamically as the page is building. Unfortunately, the site scripts (Common.js) ARE script tags in the HTML so those do run synchronously, unlike the modules on which they depend ... this is the root of the problem."
 * Understood. Extremely counter-intuitive... but okay. (Resource loader) Why in the world would you use JavaScript to load JavaScript when you have access to the PHP layer? Put it all in the HTML. Make. It. Synchronous. That way all the dependencies are guaranteed to be loaded before modules=site and modules=user ... and end-users don't have to litter their code with.
 * What I don't like about : It uses callbacks. So if you have 10 dependencies, you need 10 different callbacks. And if you need ALL 10 of those dependencies to be ready before you can execute something, then you have to do some more juggling. Whoever thought up that brilliant idea? -sigh- If this were C or Java where you just declare your includes/imports at the top of the file, that'd be perfectly reasonable. But no, we have callbacks ... because somebody thought it would be a good idea for Resource Loader to load extremely important modules asynchronously?


 * Actually, source code for  says it accepts an array of modules for its dependencies parameter (despite the fact that documentation at ResourceLoader/Default_modules only demonstrates a string with a single module as dependency), so you wouldn't need 10 callbacks... whew. Still irks me that I must now think about dependencies due to some hidden, asynchronous resource loader module nonsense.


 * I can confirm that mediawiki.Api is not a core module. I tried to use it for the Preferences module and had quite the opposite experierence from you (Mathmatician): It wasn't loaded on any of the pages I tried it on.


 * It's a bit baffling that mediawiki.Util is not a core module that's loaded by default. The list of modules that use it, seems to be so long, that I wasn't even aware it's not loaded by default. That seems to be an omission that will probably corrected eventually.


 * But I'll probably stop using it for now - unless I have to load something else as well. For what it does, mediawiki.Util doesn't seem to be worth the wait. -- peco e s 21:54, October 30, 2012 (UTC)


 * is a dependency of  so it should always be loaded by that if nothing else AFAICT. The only problem is that it is loaded asynchronously due to the aforementioned problem that   is not reliably synchronous. Declaring a dep on it should only cause a load delay in the rare circumstance that the not-synchronous bug happens + importArticles completing before the load.php for the start-up modules does.   is a bigger problem since that is only loaded if you have the follow/unfollow button in your Wikia toolbar. Lunarity 22:26, October 30, 2012 (UTC)


 * (Edit conflict) The developers like the fact that the PHP doesn't have to do any dependency graph calculations. The network of dependencies can be somewhat complex if you look at the Resources.php file, the ResourceLoader design pushes the graph construction and execution onto the client so the server can be stupid and just accept an array of names without doing its own dependency checking. I agree with you though, the server should be the smart part, not the client scripts.
 * BTW, even if it did require separate calls, you wouldn't necessarily need 10 callbacks, there are alternative patterns like this:


 * Of course, you should use the array form instead since doing it this way will cause 10 separate  requests.
 * As far as declaring dependencies goes, it's one of the standard drudgeries of programming; not declaring dependencies means importing everything which has negative performance and size consequences, it also floods the namespaces which makes the software difficult to understand and debug. OTOH, I have my own problem with RL, specifically that it tries to implement AMD but does not do so correctly [the callback receives no parameters]. Lunarity 22:14, October 30, 2012 (UTC)


 * That code example is a bit silly. Why trigger 10 requests, when one would suffice? Also: If you must indeed chain Deferreds use $.when - it's already built into jQuery. -- peco e s 22:37, October 30, 2012 (UTC)
 * peco e s 22:37, October 30, 2012 (UTC)


 * doesn't return promises, the only thing it does is invoke the callback. Mathmagician was saying that he'd need 10 callbacks to deal with an asynchronous function that only took callbacks instead of using promises. I was simply demonstrating that you don't actually need to nest 10 callbacks to deal with that sort of problem. Of course, if you can get promises instead, conglomerating them with  is definitely the best way to go. Lunarity 22:46, October 30, 2012 (UTC)


 * You're right. It doesn't return promises. I stand corrected. I just assumed because that's what jQuery does with $.getScript and $.ajax. -- peco e s 22:59, October 30, 2012 (UTC)


 * That is a neat pattern. I haven't really used Deferreds (and hence Promises) before, so that wouldn't have been immediately obvious to me. This is probably a case of "the asynchronous stuff isn't really as bad as I think it is, but it seemingly creates hard to solve problems if you don't have the right knowledge to work with". Although, I am comfortable with callbacks off of $.ajax, which returns an object that implements the Promise interface, so it's sort of like I've been using (one type of) Promise all along and just didn't really pay much attention to it.

(Reset indent) Hm. How about correcting the loader then?

peco e s 00:09, October 31, 2012 (UTC)


 * You can do that, certainly. It's less efficient though since you're creating a lot more deferreds. Of course, this is all academic anyway since you'll usually only need the one callback for your entire array of dependencies (which functions as an implicit  across all of the array entries anyway). Lunarity 00:58, October 31, 2012 (UTC)

Resource Loader (Again)
"A call to document.write from an asynchronously-loaded external script was ignored. @ http://slot1.wikia.com/load.php?debug=false&lang=en&modules=mediawiki&only=scripts&skin=oasis&version=20121031T183057Z&*:7"

*facepalm* (That's inside )

Code that caused this? Race conditions; race conditions as far as the eye can see... god damn it.

The solution to this crap is: Argh. This is what happens when you don't commit to being asynchronous; the fact that the loader tries to have it both ways just creates more problems than it solves. The best part is that there is no way to recover from this fault! Once the stupid  fails, RL will get stuck in the   state while it waits forever for a request that it didn't successfully make in the first place. I don't really want to imagine what happens if you do a synchronous  after something else already made an async request for some subset of the same modules that the second one needs, I'm sure that will work perfectly (not). Lunarity 03:20, November 1, 2012 (UTC)

Module list
(split from previous discussion)

The relevant code (Wikia's modified versions) files are here (standard modules) and here (Wikia's non-standard extra ones). There's also the relevant classes like which is the one responsible for dumping all the , the list of module registrations, and inserts the script tags for the "jquery" and "mediawiki" core modules [the only "guaranteed" ones which I was alluding to earlier]. You can also stare at the modules themselves here. (The official mainline source is in Gerrit which I find to be pig-dipped-in-molasses slow, GitHub is much faster for browsing through) Lunarity 06:18, October 30, 2012 (UTC)


 * Looking at the list of all those modules I cannot tell from the names what most of them are supposed to do. Maybe we should start a list here and add a little context to the names... -- peco e s 06:49, October 30, 2012 (UTC)


 * There's somewhat poor descriptions of most of them on mediawiki.org. Lunarity 08:17, October 30, 2012 (UTC)

(Reset indent) Ha. If only... :) Here's the list of modules that Wikia lists which aren't features on that MediaWiki page:

peco e s 13:29, October 30, 2012 (UTC)


 * site &mdash; PHP class that is responsible for merging Wikia.js, Common.js, bureaucrat/sysop/user/insert-group-here.js into a single minified file.
 * noscript &mdash; generates &lt;noscript&gt; CSS link stylesheet tags to compensate for browsers with JS disabled
 * startup &mdash; explained above, dumps the server state (module list, wg vars) into a JS file
 * user &mdash; Same as site, but for users. (Merge wikia.js/global.js/common.js into a single minified file and return it)
 * user.groups &mdash; these are parts of.
 * user.options
 * user.cssprefs
 * user.tokens &mdash; contains the edit and watch tokens for api.php, these are always available separately from  itself
 * filepage
 * skins.chick &mdash; these are all generic code specific to a particular skin, like JS support for special buttons.
 * skins.cologneblue
 * skins.modern
 * skins.monobook
 * skins.nostalgia
 * skins.simple
 * skins.standard
 * skins.vector
 * jquery &mdash; self explanatory, this is the jQuery core.
 * jquery.appear &mdash; Adds a new jQuery event for whenever something scrolls into view
 * jquery.arrowSteps
 * jquery.autoEllipsis &mdash; Finds text that is too long and chops the end off, replacing it with an ellipsis
 * jquery.byteLength &mdash; determines length of string in bytes instead of characters. I wouldn't use this though, the algorithm doesn't seem to know the difference between a byte and a short.
 * jquery.byteLimit &mdash; plugin for limiting a textbox length by bytes instead of characters (e.g. UTF-8 chars, 1-5bytes=1char)
 * jquery.checkboxShiftClick &mdash; allows you to check and uncheck a heap of checkboxes at once by clicking one and holding shift when clicking the second (every box in between will be toggled as well)
 * jquery.collapsibleTabs &mdash; something to do with making the top tabs in Monobook/Vector collapsible.
 * jquery.colorUtil &mdash; this is a jQuery plugin for converting colors, e.g. take a  and convert it to RGB so it will work in IE which doesn't support HSL. It's also useful for manipulating colors, you can convert an RGB value to HSL, tweak it (reduce the luminance by 10% to make it darker) then convert it back to RGB.
 * jquery.delayedBind &mdash; this is a jQuery plugin for debouncing event handlers
 * jquery.expandableField &mdash; automatic animation plugin, makes textboxes wider when they gain focus and shrinks them when they lose it
 * jquery.farbtastic &mdash; A color wheel widget for letting the users pick colors.
 * jquery.footHovzer &mdash; floating footer (like the Wikia toolbar), it's an arbitrary space in which to stick things that you want to float in the viewport. It's used to replace console.log in IE since that doesn't work reliably there.
 * jquery.form
 * jquery.getAttrs
 * jquery.highlightText
 * jquery.hoverIntent
 * jquery.localize
 * jquery.makeCollapsible &mdash;
 * jquery.messageBox
 * jquery.mockjax &mdash; You can find this with Google, it's a plugin for testing your code using fake AJAX responses (replaces $.ajax with a fake one that returns predefined data)
 * jquery.mw-jump &mdash; accessibility feature for links (something about motor impaired people, the code doesn't really explain)
 * jquery.mwExtension &mdash; legacy stuff, includes trimRight, trimLeft, escapeRE and a few other random functions.
 * jquery.qunit &mdash; Unit test framework, don't know much about it
 * jquery.qunit.completenessTest
 * jquery.spinner &mdash; A throbber.
 * jquery.tabIndex
 * jquery.textSelection &mdash; framework for selecting text in a textbox, or design mode iframe. Also allows you to wrap the selection with prefix and postfix. Used by Edit Tools (e.g. the toolbar buttons use this in the Source mode of the editor to insert the stuff, I've used it here)
 * jquery.validate
 * jquery.xmldom
 * jquery.ui.core &mdash; jQuery UI framework pieces.
 * jquery.ui.widget
 * jquery.ui.mouse
 * jquery.ui.position
 * jquery.ui.draggable
 * jquery.ui.droppable
 * jquery.ui.resizable
 * jquery.ui.selectable
 * jquery.ui.sortable
 * jquery.ui.accordion
 * jquery.ui.autocomplete
 * jquery.ui.button
 * jquery.ui.datepicker
 * jquery.ui.dialog
 * jquery.ui.progressbar
 * jquery.ui.slider
 * jquery.ui.tabs
 * jquery.effects.core &mdash; more jQuery UI pieces
 * jquery.effects.blind
 * jquery.effects.bounce
 * jquery.effects.clip
 * jquery.effects.drop
 * jquery.effects.explode
 * jquery.effects.fade
 * jquery.effects.fold
 * jquery.effects.highlight
 * jquery.effects.pulsate
 * jquery.effects.scale
 * jquery.effects.shake
 * jquery.effects.slide
 * jquery.effects.transfer
 * mediawiki &mdash; the MediaWiki core module.
 * mediawiki.api.category &mdash; parts of mw.Api for various specific interfaces. This one is for requesting categories a page belongs to, determine if a category exists, etc via API.
 * mediawiki.api.edit &mdash; mw.Api for editing API
 * mediawiki.api.parse &mdash; action=parse
 * mediawiki.api.titleblacklist &mdash; add page title to site's black list (if Extension is installed and active)
 * mediawiki.api.watch &mdash; API for add/remove from Followed Pages (Watchlist)
 * mediawiki.debug &mdash; not sure, some sort of "debugging toolbar"
 * mediawiki.debug.init
 * mediawiki.feedback &mdash; some sort of feedback prompt dialog thing
 * mediawiki.htmlform
 * mediawiki.Title &mdash; Cut down JavaScript implementation of the PHP Title class.
 * mediawiki.Uri &mdash; Library for working with URLs. Provides window.location for any arbitrary URL string (separates out query string, path string, port, host, protocol, hash).
 * mediawiki.action.edit &mdash; these are UI components, this is for edit page, things like the MediaWiki toolbar (Bold/Italic/Signature/etc in Source mode)
 * mediawiki.action.history
 * mediawiki.action.history.diff
 * mediawiki.action.view.dblClickEdit &mdash; implementation of the "double click heading to edit" feature from Special:Preferences
 * mediawiki.action.view.metadata
 * mediawiki.action.view.rightClickEdit &mdash; dblClickEdit, but right clicking instead
 * mediawiki.action.watch.ajax &mdash; Followed pages framework (implements Follow/Unfollow for the toolbar)
 * mediawiki.language &mdash; framework for i18n stuff, handles number conversions, plurals, per gender nouns, etc
 * mediawiki.jqueryMsg &mdash; A basic WikiText-&gt;HTML parser. It exists to let you do
 * mediawiki.libs.jpegmeta
 * mediawiki.page.ready &mdash; Standard page features like mw-collapsible and such, all that automatic JS stuff that happens when the page loads.
 * mediawiki.page.startup &mdash; marks the page with the JS enabled CSS class
 * mediawiki.special &mdash; these are JS pieces for various special pages
 * mediawiki.special.block &mdash; Special:Block, etc
 * mediawiki.special.changeemail
 * mediawiki.special.changeslist
 * mediawiki.special.movePage
 * mediawiki.special.preferences
 * mediawiki.special.recentchanges
 * mediawiki.special.search
 * mediawiki.special.undelete
 * mediawiki.special.upload
 * mediawiki.special.javaScriptTest
 * mediawiki.tests.qunit.testrunner
 * mediawiki.legacy.ajax &mdash; these are all old things that are being phased out (these all add stuff to  rather than  )
 * mediawiki.legacy.commonPrint
 * mediawiki.legacy.config
 * mediawiki.legacy.IEFixes
 * mediawiki.legacy.mwsuggest &mdash; search suggestions while you type
 * mediawiki.legacy.preview &mdash; AJAX preview of some sort, not Wikia's, some other one for Monobook/Vector
 * mediawiki.legacy.protect &mdash; action=protect
 * mediawiki.legacy.shared
 * mediawiki.legacy.oldshared
 * mediawiki.legacy.upload &mdash; Special:Upload
 * mediawiki.legacy.wikibits &mdash; legacy junk: importScript, importScriptURI, etc
 * mediawiki.legacy.wikiprintable

Lunarity 15:29, October 30, 2012 (UTC)


 * Wow! Nice! You've done some research already! :)


 * Okay, I admit some of the stuff on the list is quite obvious. All the jQuery stuff e.g. This list simply contains the array keys from https://github.com/Wikia/app/blob/dev/resources/Resources.php . I did not hand-edit it. But I will. This should be turned into a page of its own. If we can write a few lines about each module - plus some deep links to the jQuery and mediaWiki docs - we'll do ourselves and others a big favor. This needn't be a huge project either. Just something we complete piece by piece as we go along... -- peco e s 21:54, October 30, 2012 (UTC)

Rating
Hey there Lunarity! :D

How's it hangin'?

It's amazing that you've done so much for this wiki in such a short period of time! :D

Anyway, I have been very curious about this for a while. Is it possible to introduce a similar star rating system like the ones on IMDb and TV.com ? Like a star rating system to rate articles or episodes of TV shows in particular? Just since apparently 'practically anything is possible with CSS and JS'. I'd just like to know if this in particular is possible? Thanks! :D

Ḡwẵine Ḹٍٍkƨ Ĺiĸe Ͼềлȑềd aka Alfons 09:49, October 31, 2012 (UTC)


 * Implementing such a thing is possible, the problem is storing the data. I assume you want to actually save the ratings somewhere. I'd recommend looking for a third party widget and importing it with verbatim tags since Wikia's servers don't really offer anything more sophisticated than the  tag AFAIK. I suppose it would be possible to construct a fake UI for a normal wiki poll to make it show stars instead the normal appearance.
 * I'd need a mock-up of what exactly you want to be before I can be more precise.
 * In any case, here's something I found on Google, if that fits your needs then you can probably just use that. Lunarity 11:51, October 31, 2012 (UTC)


 * Wikia actually has a system for voting on articles. I don't know if it ever went live though. Maybe it did and they couldn't make it work. Or maybe it never became popular. Maybe it was just an idea they toyed with. I haven't been around long enough to know. It's still accessible via the API though. If you were to establish a strict equivalency one page <-> one episode/movie/game/whatever, you could probably use this system. -- peco e s 16:10, October 31, 2012 (UTC)


 * It was a lab that they discontinued. -- Kangaroopowah  ( Talk ) 16:48, October 31, 2012 (UTC)


 * Right. I remember you mentioning that :) Did it work? Or didn't it and that was the reason they discontinued it? -- peco e s 16:57, October 31, 2012 (UTC)


 * I think it was a combo of that it was buggy, the way they presented it was all wrong and that the WMF was working on Article Feedback which could then be incorporated into Wikia. -- Kangaroopowah  ( Talk ) 01:21, November 1, 2012 (UTC)


 * I tried to add the link you suggested to me Lunarity however I don't see any change happening... Ḡwẵine Ḹٍٍkƨ Ĺiĸe Ͼềлȑềd aka Alfons 07:20, November 3, 2012 (UTC)

You have to create a page in the MediaWiki namespace on the wiki and import the code with verbatim tags. E.g.  then in the page put. Lunarity 07:35, November 3, 2012 (UTC)


 * So I need to copy the entire code to a page called 'MediaWiki:Stars ' and then add the StarsS01E01 to articles?Ḡwẵine Ḹٍٍkƨ Ĺiĸe Ͼềлȑềd aka Alfons, November 3, 2012 (UTC)


 * That's correct. The stars should appear wherever you place the Verbatim in the article. [Make sure you have a different userkey for each article, otherwise the stars will be for everything instead of separate] Lunarity 16:10, November 3, 2012 (UTC)


 * Still not working. I've followed your steps.
 * http://merlin.wikia.com/wiki/MediaWiki:S04E10
 * http://merlin.wikia.com/wiki/A_Herald_of_the_New_Age
 * Yet nothing is happening.
 * Could you help me out? I have given your admin rights on the wiki.
 * User:Ḡwẵine Ḹٍٍkƨ Ĺiĸe Ͼềлȑềd

Preferences
The Preferences module is nearing completion. And there's already a full-fledged demo for the language preferences we talked about. You can find the documentation and links to the demo and the module itself here. Let me know what you think, please! -- peco e s 23:39, November 03, 2012 (UTC)

I've tried to absorb as much as I can. Notes: Lunarity 01:49, November 4, 2012 (UTC)
 * Special:Scripts crashes in Monobook.
 * The post on form objects doesn't seem to offer any way to abort the post due to invalid/required field values. If that's intentional, you should probably add a note.
 * Wikia doesn't have jQuery UI stylesheets but I notice you're using a slider in the UI, having jQuery UI stylesheets set up for the basic widgets by the form loader may be a useful feature.


 * Here's the list of missing features:


 * Monobook support is missing. Completely.
 * The update promise is still missing
 * There's still no way to access the localStorage


 * As for the post promise: I was hoping - maybe that's a little naive - that everybody could make it so that it's impossible to enter invalid data. This isn't your regular webform after all. In regular web forms the user can bypass the JavaScript and post whatever he wants regardless. That's impossible here. The languages form is an example of what I mean. You cannot enter an unknown language or an unknown level for it.


 * Also keep in mind that Special:Scripts will ultimately run code from many different addons and addon-authors. It should not be up to a single one of them to block everything for everybody else.


 * Not sure, if you've noticed but I also wrote this other quick little hack in the last few days: FloatingToc. It uses the jQuery UI dialog and button widgets. I'm seriously asking myself now whether I should try to create a Wikia theme for the entire jQuery UI. That's the kind of thing I should be able to get support from Wikia Staff for. And then maybe I could get the stylesheet onto their actual SASS server.


 * It should be a little more than a theme though. There should be a lot of presets for buttons and the like. A "dock to siderail" button e.g. would be very useful e.g. You should be able to manipulate the menu at the top of page with the jQuery UI menu widget. etc. etc. The goal should be to seamlesslessly integrate the jQuery UI into the Wikia environment.


 * That would not be a quick little hack however. That would be a really ambitious project. One that would keep me busy for weeks and I do not have that kind of time right now. I'll probably do this though... -- peco e s 06:40, November 04, 2012 (UTC)


 * EDIT: Oh, and yes I will also add presets for a few basic jQuery UI features to the Special:Scripts stylesheet. At the moment the list is short. I have presets for these HTML tags: input[type="text"], input[type="button"], button, select, a, legend, fieldset, label and for the jQuery UI slider. That list needs to be expanded.


 * But returning to the language preferences for a moment :) My hope was that you would integrate them (and the skill preferences I'll soon add) into your UserTags. Otherwise I'd have to start editing UserTags in a major way and I'd rather not. Also: I do need a tester other than myself for the Preferences module :D


 * The format for the languages is quite simple:


 * peco e s 07:05, November 04, 2012 (UTC)


 * Here's the complete language list:


 * The property of the shared object is called "languages". It is itself an object. The language codes are its keys and the levels are their values. Values will be between 1 (basic) and 5 (native). 0 (none) will not be saved.


 * For the skills the structure will be: An object named "skills" with the keys "css", "js" and "templates". The values will range from 1 (basic) to 4 (pro). -- peco e s 07:21, November 04, 2012 (UTC)


 * Okay, I've got the prototype module written. You can try it by running (in your console):


 * If you want to modify the code then you can, I'm not sure about the I18N implications of this. Lunarity 08:34, November 4, 2012 (UTC)


 * Seems to work fine. But say, why don't you add the CSS that's required for UserTags with JS?
 * peco e s 08:44, November 04, 2012 (UTC)

(Reset indent) The CSS isn't technically required, except in Monobook. I prefer to keep it separate to keep it customisable. If I set the spacing between tags with JS, the cascade order would make it hard to override if people wanted a bigger or smaller gap without resorting to. Lunarity 08:52, November 4, 2012 (UTC)


 * You are an option spammer! :D
 * peco e s 09:34, November 04, 2012 (UTC)


 * I just contradicted myself by killing that entirely. The CSS is no longer needed at all, except for the link-tag colors. Lunarity 09:36, November 4, 2012 (UTC)


 * A wise choice! :)
 * peco e s 09:43, November 04, 2012 (UTC)


 * One last thing though: There's no need to put the Preferences-related bits of UserTags into a separate script. You can simply put the loader in an if-block and Preferences.js will not be loaded if the user/site doesn't want it. -- peco e s 09:48, November 04, 2012 (UTC)


 * This is originally what I created the the module system to do, piling stuff into the core is just a convenience. Putting the preferences module in the core would have the negative consequence that "My scripts" would only show up on user pages and Special:Scripts won't work. The script core is only loaded on user pages (See UserTags/code.js). Determining that the module isn't wanted isn't possible, the core decides that internally and will simply not call any of the module's functions if it isn't enabled. That means I'd have to put the loader inside the start function which doesn't appeal to me from an architectural standpoint. Executing the loader in the top level lets it start doing the IFRAME/AJAX load-wait whilst the UserTags core is running.


 * An additional consideration is that the core modules have no external dependencies. In any case, the core is also rather large so whenever I feel like doing major work on UT again, I was planning to improve the loader then factor out most of the core modules into separate files that will only load on demand via bulk /load.php anyway. Lunarity 10:54, November 4, 2012 (UTC)

(Reset indent) Hm. Not sure we understood each other... I'll have to double-check:

"IFRAME/AJAX load-wait"? Everything loads completely asynchronously if that's what you're getting at. And as I said: You can run the loader conditionally:  The only caveat is that this would have to happen before the conditional that checks whether this is a user-page or not. If the users want a feature that requires Preferences, then the Preferences module has to load everywhere - not just on user-pages. The loader itself is less than 1K in size. So if you're worried about bloat: Don't worry about the loader! Also keep in mind that Preferences.js, the iframe, etc. will only be loaded once - regardless of how many addons run the loader. Or to put it differently: If Preferences catches on, it will probably load regardless of whether your script happens to be the one to request it. peco e s 13:10, November 04, 2012 (UTC)


 * Accessing the values in the UserTagsJS global is not part of the module interface. The core is responsible for interpreting the global, even the loader doesn't touch it. Separation of Concerns dictates that doing that would increase coupling between the loader, modules and the core, which makes it an anti-pattern. The problem is that there isn't really a reason for the UserTags core to depend on Preferences directly. The module is what needs it so it should be responsible for loading it; the core itself is entirely administrator controlled with no user configuration. Like I said, the difference should become less pronounced after I work on UT again; I'm going to move all of the rest of the modules into separate script files as well then have the loader conceal that from users by automatically doing an importArticles across all of them. Preferences is more at home being built into HideRail and ReferencePopups.


 * On a tangentially related note, did you know that this works?


 * Is that intentional? Also, it feels rather odd that I need to look up the current user's username when Preferences already knows the answer to that, shouldn't  work? Lunarity 05:05, November 5, 2012 (UTC)


 * Please look at what you've done: You've banished the Preferences code onto an extra page - outside of the main UserTags page - where it's much harder to notice. You've banished the code that uses the Preferences into an exta script and thus you're making people who might be interested jump through an extra hoop. It's good to hear that makes a lot of sense from an architectural perspective but it doesn't help much in promoting the Preferences module.


 * The idea to add a boolean parameter is a good one. I'll probably adopt that.


 * And, er, what exactly is odd about that code? -- peco e s 05:59, November 05, 2012 (UTC)


 * That's not intentional, the documentation pages for UserTags are just crap and massively disorganised at the moment; I fully admit that the main page is not light reading and the sub-page makes it harder it find. That is not intentional, it's just a lack of good article design around the documentation on my part [You can reorganise it if you want, I honestly have no idea what I'm going to clean that mess up]. I can add a hack to the loader to hide the extra import required if you really want me to but I'm not sure that actually gains very much.


 * The question about that code was whether adding arbitrary unauthorised data to the shared store is intentionally allowed or not. Lunarity 06:23, November 5, 2012 (UTC)

Random comment about Preferences / your talk page

 * Preferences conversation with Pecoes is interesting. I'm following it, but not really saying much because it's about halfway over my head.
 * I think your talk page is possessed by a ghost, because I'm seeing a lot of this:

Only happens here on your talk page on this wiki. Doesn't happen on other people's talk pages. Happens logged in and logged out. After purging many times, 100% reproducible on my end. Only in Chrome, Firefox is perfectly fine.


 * Interesting. The problem is that jQuery isn't working, so everything that uses jQuery (i.e. everything) is crashing, but it only happens in Chrome. That's rather bizarre. If you do  in your console, you get " ", I've checked and that's an alias for  . I'm also getting window.jQuery = " ". This seems to imply that, somehow, the jQuery H2 heading on this page is finding its way into the   object and replacing jQuery with the DOM node... All I can say to that is, WTF? I think this may be a Special:Contact/bug, I'll need to try it on another page. Lunarity 05:05, November 5, 2012 (UTC)


 * Confirmed. It's the heading that does it, beats me how it does it though... Lunarity 05:17, November 5, 2012 (UTC)


 * Yeah, I'm seeing that too. Really, really bizarre... P.S Special:Contact/bug report filed, albiet this is probably a pretty obscure one.