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

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


 * "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)


 * (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)

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)