Talk:ResourceLoader/Migration guide for extension developers

Jump to navigation Jump to search

About this board

Scripts from different extensions

1
Krinkle (talkcontribs)

I can not seem to figure out how I can add script files from another extension. My extension relies on a script file of another extension. This file itself handles some images/style files within the /extensions/OtherExtension/skins folder. I tried adding a module for this like so:

$wgResourceModules['ext.OtherExtension'] = array(
   'scripts' => 'libs/neededScript.js',
   'styles'  => 'skins/neededCSS.css',
   'localBasePath' => dirname( __FILE__ ),
   'remoteExtPath' => 'OtherExtension'
);

However, it works with $wgResourceLoaderDebug = true; AND I copied styles / images (e.g. the 'skins' folder) to my extension path. If I set wgResourceLoaderDebug = false; it fails completely, even if I copy the skins folder. What I actually want, is not to have to copy the files, but have the script file loaded and handle the files in the folder of the other Extension. What is the best way to achieve this? -StrongBaf 17:00, 29 October 2011

This post was posted by Krinkle, but signed as StrongBaf.

Reply to "Scripts from different extensions"
Krinkle (talkcontribs)

My site uses a custom skin that we have developed. The skin itself has a lot of external .js and .css that it is dependent upon today. I'm wondering if there is a way that I can load these files through ResourceLoader, as opposed to the old way, in which i link to them directly in the skin's html? I've read through all the documentation, but i wasn't clear how i could do that. --Duke33 17:03, 19 August 2011 (UTC)

This post was posted by Krinkle, but signed as Duke33.

Krinkle (talkcontribs)

Hello Duke - any progress on this?? Help please! --Fladei 05:41, 26 October 2011 (UTC)

This post was posted by Krinkle, but signed as Fladei.

Krinkle (talkcontribs)

Yes. Email me if you want some help. --Duke33 13:08, 26 October 2011 (UTC)

This post was posted by Krinkle, but signed as Duke33.

Reply to "Developing for a custom skin"
Krinkle (talkcontribs)

I'm trying to make an extension compatible with the ResourceLoader. All I have is one .js file to include. Here's what I have so far - (pastebin). Registration seems to work, my page source has:

if ( window.mediaWiki ) { mediaWiki.loader.load( ["mediawiki.legacy.edit","ext.Hi","ext.wikiEditor.toolbar", ... ] ); }

but the javascript functions aren't being loaded. Firefox error console clearly states the function is not defined. What am I missing? --MrC 22:06, 12 October 2010 (UTC)

This post was posted by Krinkle, but signed as MrC.

Krinkle (talkcontribs)

You are probably operating under the assumption that your code is being run in the global scope. ResourceLoader encapsulates code in closures which are executed as soon as all of their dependencies are met, meaning that all of the functions and variables you created are only defined within the scope of the closure. If you want to export functions or variables to the global scope, just use

window.myMethod = function() { ... };

or

window.myVariable = 'some value';

You will be able to refer to them as you normally would from there on out. I will note however that polluting the global scope is tempting, but you should seriously consider wither making your code a jQuery plug-in or following the model of mediaWiki and jQuery objects, in which your entire library is encapsulated in a single object. --Trevor Parscal 00:09, 13 October 2010 (UTC)

This post was posted by Krinkle, but signed as Trevor Parscal.

Krinkle (talkcontribs)

Ok, thanks, that makes sense. Where would the calls to window.myMethod go? I would certainly like to use the MW model, but so far I can find very little documentation on why/when/how to do it. I'm still not sure if I should even be using ResourceLoader. Here's my situation- I have a parser extension that converts my custom tag into some code which makes calls to myExt.js, which is short and only serves this one tag. So any page that has this tag needs to access myExt.js. On a non-MW page, I would just add "script src=myext.js" to the head. What should I do in MW, and how? MrC 15:20, 14 October 2010 (UTC)

This post was posted by Krinkle, but signed as MrC.

Krinkle (talkcontribs)

I understand the conception not to pollute the global namespace, and I want to use this feature of RL, but how? I've already read all of the documentation you provided, but I swear, I didn't find anything related. There's a mediaWiki.loader class and nothing more I can do with that. How can I have the browser recognized my function calls automatically? -- Szotsaki 10:25, 23 July 2011 (UTC)

This post was posted by Krinkle, but signed as Szotsaki.

Reply to "Getting started"
203.97.121.69 (talkcontribs)

Can someone in the know explain why custom skins can't use the same $wgResourceModules['ext.myExtension'] = array(... resource definition method that extensions use?

I've worked around this by treating resources/Resources.php as a configuration file, and have added my skin definitions directly to it, but that's far from portable.

Further more, skin definitions don't seem to honour dependencies; I put jquery.ui.widget in, so I can use a smooth div scrolling plugin, but it never loads (even when I'm using debug=true). I ended up adding it to my scripts section, but given what ResourceLoader is all about, that's a bit of a retrograde step.

(I do love the automatic minify and combine, though. Great stuff.)

Using mediawiki 1.18.

203.97.121.69 (talkcontribs)

Nice move liquidthreads. Let's see if I can reproduce that in comments...

203.97.121.69 (talkcontribs)

Nope. Preview before save did the right thing. I leave it up to a moderator to clean up this mess. Sorry.

Krinkle (talkcontribs)

I'm not very home in the skins area but from what I know, extensions can extend functionality. This includes Skins.

Historically people provided skins and instructed users to download the skin and put it in the ./skins/ directory, however I think in the latest version this is no longer supported (if it works, fine, but it's not tested for). Try creating it as an actual extension instead.

btw, what were you trying to reproduce in the comments? I don't see anything..

203.97.121.69 (talkcontribs)

Of course, the instructions for installing an extension is to download the extension and put it in the ./extensions/ directory, so that's hardly a better distribution and installation system. I'm not sure a skin would behave like a skin under the extensions directory, either.

(I was trying to reproduce double posting on a single submit. An editor has culled the duplicate post.)

Krinkle (talkcontribs)

Using it as an extension is better because it survives any upgrade or change to the core skins directory, and extensions have a place for registering resource modules, hooks, i18n messages etc. etc.

203.97.121.69 (talkcontribs)

So all the old skin documentation really needs to be replaced with new skins-as-extensions docs. Is this something anyone is actually working on?

Reply to "Custom skins"
Krinkle (talkcontribs)

Following this edit, a little info here.

ResourceLoader always loads a module's styles before executing any scripts. It is by no means "desirable for the stylesheet to be loaded before rest of html [by using OutputPage::addModuleStyles]". OutputPage::addModuleStyles will insert a hardcoded <link> tag in your HTML that is ineffeciëntly cached and separate from the whole advanced cache-busting and cache-preserving system around ResourceLoader. Usage of direct <script> and <link> tags in the output should be extremely rare and is imho to be considered deprecated (except for some core stylesheets and the ResourceLoader startup module itself).

The only scenario in which might consider loading the styles of the module from the <head> (separate from the rest of the module) is when your module is serving two purposes, which you shouldn't be doing.

If you've got a module that has a stylesheet that is styling content outputted by PHP and/or moving around elements outputted by PHP, and at the same time have code in this module that is doing dynamic stuff after the document is ready (e.g. something that isn't visible or needed before the page is loaded), then one should split the module.

One module for initialization stuff. This module should have the position property in the module registry set to "top". This will tell the client to load the module from the <head> before parsing the body contents. So that whatever is in here will be in memory before the page is displayed. The other module would contain everything else and can simply be loaded regularly from the asynchronous queue that arrives at or a little after the document is ready.

Both should be added to the load queue in OutputPage::addModules. That way the module properties and the load queue are kept separate, the client will use the module registry properties when it loads it and do the right thing (instead of telling OutputPage to force loading it in a certain way, simply let the client handle it).

76.28.210.219 (talkcontribs)

The problem with what you say above is that the "top" property is not available until version 1.19, which is not yet stable. So with version 1.18 doing it the way you say, the browser displays unstyled html for a second before the styling is applied, which is a very unpleasant user experience. I would rather trade a bit of efficiency for a much better overall experience.

Krinkle (talkcontribs)

I don't know where you get this information from, but position property has been in MediaWiki at least since version 1.18

76.28.210.219 (talkcontribs)

The info-bubble in section "Inline Javascript" on this page says that as far as I can understand it. Perhaps it needs correction.

Krinkle (talkcontribs)

Thanks, I've removed the notice. The "top" queue was implemented earlier then originally planned.

Reply to "Mixed purpose modules"
There are no older topics