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 updating". 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)