Help talk:Including additional CSS and JS

importScriptURI vs. $.getScript
Hi Kangaroo! I'm going to revert the edit where you replaced  with. returns  when the script is already loaded. So to play it safe, you would have to write:

Other scripts might load  as well, so simply assigning a value to   is risky:

covers all of the above:

-- peco e s 05:09, August 24, 2012 (UTC)

ImportArticles misleadingly generic function name
ImportArticles sounds pretty generic for something that really only supports CSS and JS. Why use that name? Wouldn't something like ImportCSSorJS have been better? -- Fandyllic  (talk &middot; contr) 24 Aug 2012 6:53 AM Pacific


 * Hi Fandyllic! Haven't heard from you in ages! How are you?


 * Anyway: You should probably post that question in the Blog that introduced : w:User_blog:DaNASCAT/Update_Your_CSS_and_JavaScript_To_Speed_Up_Your_Wiki. My guess is - and I haven't really studied the ResourceLoader yet - that   is used for a lot more than loading scripts and stylesheets... That's just a guess though. -- peco e s 15:44, August 24, 2012 (UTC)


 * From a user perspective, it can be a little confusing since it is mainly a way to add scripts or styles to a wiki. However, at a deeper level, these scripts and styles are actually articles, so in essence you are importing articles that contain scripts or styles. Kyle Florence (talk) 17:41, August 24, 2012 (UTC)

Using importArticles in MediaWiki 1.16.5
If you would like to use  syntax in a MediaWiki 1.16.5 Wiki then you can place the following code at the top of your   page.

You can use this code in your global.js, wikia.js or monobook.js so that you can 'fast-load' your personal scripts across all Wikis without it breaking when you visit a 1.16.5 Wiki.


 * WARNING:  cannot interwiki import from the Wiki you are on.   will work on every wiki except the dev wiki itself (where the script is located), you'll just get an error there.

importArticles in user scripts
I'm getting the impression that it's best to avoid importArticles in user scripts altogether. Especially in global ones because - as Kyle said - the speed advantage melts away since every wiki you go to has to create its own minified merge of your scripts.

So my suggestion would be to "anchor" all user scripts to Community Central. This is what my own global.js currently looks like:

What do you guys think? -- peco e s 13:03, September 01, 2012 (UTC)


 * Can you clarify on what the benefit of "anchoring" the load.php to a single wiki is? The minified merge thing just happens *once* right? I.e. the first time you visit a new wiki, it has to create that merge. But on subsequent page loads, it's already done and doesn't need to happen again (for some time)? If that's the case, isn't the benefit of this "anchoring" thing rather minimal? — Mathmagician (message wall) 18:40, September 11, 2012 (UTC)


 * Where do you see the downside of this method? -- peco e s 18:46, September 11, 2012 (UTC)


 * I don't see a downside per se, I'm just not seeing very much of an upside. Isn't this just writing extra code for essentially no reason? — Mathmagician (message wall) 21:12, September 12, 2012 (UTC)


 * * sigh* At the time I wrote the code above, the help page stated:
 * "Fast loading personal scripts may actually be slower when using because your browser will not be able to use its cache effectively.   invokes   on the current Wiki which means that whenever you change to a different Wiki, the whole set of scripts is downloaded again. Using   will download directly from the target wiki instead of the current one so your browser can cache the pages and only load them once."
 * Kyle removed that passage in the mean time and just a few hours ago Wladekb posted in the blog that scripts are cached for 10 minutes only. That makes the code I posted above moot. I updated the help page with that bit of info. -- peco e s 21:23, September 12, 2012 (UTC)