Project:WikiProject Extensions/MediaWiki Workshops/ResourceLoader/Transcript

An IRC conversation transcript from March 2012.

 [21:05:04] 	Welcome folks to the MediaWiki Workshop: MediaWiki's ResourceLoader [21:05:05] *Krinkle 	owns #E3FFC7 [21:05:15] 	Our etherpad is http://etherpad.wikimedia.org/oDy8cQ6Bvb [21:05:39] *MikaelLindmark 	is all ears [21:05:41] *Lcawte 	magicly appears [21:06:18] 	I'll be your facilitator for this session - RoanKattouw and Krinkle will be our ResourceLoader experts [21:06:25] 	And TrevorParscal ! [21:06:31] 	yes - lol [21:06:45] 	sorry TrevorParscal as well - didn't see you there :) [21:06:59] 	can I be the lost newbie? [21:07:09] *varnent 	handing out role cards [21:07:15] 	We'll do a little RL introduction, chat about it's features, how it's used [21:07:17] 	Nikerabbit: I'm the lost newbie :) [21:07:24] 	Then a bit about where it's going [21:07:32] 	Lead into some Q&A and then wrap things up [21:07:50] 	a transcript of this session and a link to the ether pad will be posted online later today [21:08:35] 	so rather than confuse everyone with my own explanation of RL, I'll hand things over to RoanKattouw, TrevorParscal and Krinkle :) [21:08:43] 	is the workshop now? [21:08:54] 	aude: Yes [21:09:05] 	RoanKattouw: yay, i'm actually here for once [21:09:14] 	I believe RoanKattouw has some assembly of notes to start us off  :) [21:09:35] 	I'll add some links about RL to the Etherpad for folks reference - http://etherpad.wikimedia.org/oDy8cQ6Bvb [21:09:37] 	Ah, I do? [21:09:40] *RoanKattouw 	looks confused :D [21:10:17] 	OK so [21:10:36] 	well - let me put it this way [21:10:41] 	Oh that e-mail? [21:10:46] 	I think I know what you'er talking abuot [21:11:03] 	can you start us off by talking a bit about what RL is - in a nutshell :) [21:11:10] 	OK, so let me apologize for the poor preparation here [21:11:22] *varnent 	apologies on my behalf as well btw [21:11:25] 	As you might have heard, I just moved to the US from Europe last Sunday so I've been busy [21:11:56] *Edokter 	did not hear that... big move [21:12:10] 	There was an internal announcement, no real public one yet AFAIK [21:12:15] 	But yeah I work in the SF office now [21:12:18] 	So.... ResourceLoader :) [21:12:36] 	I'll just talk briefly about what it is, what it can do, and how you use it from a developer's perspective [21:12:48] 	excellent :) [21:13:26] 	So ResourceLoader is the new system that Trevor and I wrote just over a year ago. It's a subsystem of MediaWiki introduced in version 1.17, and it handles all of MediaWiki's JS and CSS delivery [21:13:42] *TrevorParscal 	is done adding links for the time being [21:13:43] 	That means RL is the system that takes .js and .css files and makes sure they end up in the client's browser in an efficient way [21:14:40] <RoanKattouw>	That means your JS/CSS is loaded for you by RL, you don't do this directly yourself. It also gets combined with other things, minified, and has other transformations applied on the way [21:15:00] <RoanKattouw>	Those exist mostly for performance, but for CSS we also have some cool things, such as automatic LTR-RTL flipping [21:15:12] 	yay RTL! [21:15:23] <RoanKattouw>	Basically the goal is for the developer to just write stuff and not have to worry about anything, RL does that for you [21:15:41] <RoanKattouw>	You don't have to know how it works in order to learn how to use it, and using it should be simple [21:15:46] <RoanKattouw>	(in theory : ) ) [21:16:54] <RoanKattouw>	So we have some documentation on how to use RL from a dev's perspective, let me dig that up [21:17:18] <RoanKattouw>	https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers [21:17:23] <TrevorParscal>	I will add that it also optimizes things quite well by default - whereas before it was something of a chore and most people either didn't do it at all or did it poorly [21:17:29] <RoanKattouw>	Yeah [21:17:43] <RoanKattouw>	The idea is that developers can't be trusted to optimize things by hand, cause if it takes time they won't do it [21:17:46] <RoanKattouw>	So we automated that process [21:18:04] <MikaelLindmark>	nice [21:18:13] <TrevorParscal>	There are also some extras that developers can use like image embedding [21:18:29] <RoanKattouw>	The documentation page I linked to talks mostly about how to register and use modules, which is the most important thing devs have to deal with [21:18:33] <RoanKattouw>	Ah yes, image embedding [21:18:45] <TrevorParscal>	just add /* @embed */ above a CSS background URL property, and it will be embedded as a data-URI on the fly [21:18:48] <RoanKattouw>	RL has a feature where small (<24KB) images like icons can be embedded into the CSS [21:18:55] <RoanKattouw>	...and yeah that's how you use it :) [21:19:12] <Nikerabbit>	and the path should be relative the location of the css file? [21:19:16] <RoanKattouw>	Yes [21:19:29] <TrevorParscal>	if it can't find it on disk, it will just ignore the suggestion to embed it [21:19:38] <RoanKattouw>	ResourceLoader will deliver the CSS from somewhere else, so that's not the path it'll actually use, but it'll remap things for you automatically [21:19:55] <Edokter>	so absolute urls can't be embedded? line images from wikibits? [21:20:04] <TrevorParscal>	correct [21:20:06] <RoanKattouw>	All of the crazy shit RL does is designed to be totally transparent to you, you can just write your CSS/JS as if they weren't happening mostly [21:20:08] <RoanKattouw>	Yes, that's right [21:20:18] <RoanKattouw>	Embedding only works with relative paths on-disk [21:20:26] <RoanKattouw>	(at this time) [21:20:29] <TrevorParscal>	but copying the image to disk is easy [21:20:43] <Edokter>	that means embedding in gadgets is pretty much impossible [21:20:56] <RoanKattouw>	Right now ye [21:20:58] <RoanKattouw>	s [21:20:59] <Nikerabbit>	but not with all relative path.. I filed a bug for that [21:21:04] <TrevorParscal>	Krinkle: there's a plan for that yes? [21:21:05] <RoanKattouw>	Nikerabbit: bug # ? [21:21:10] *Krinkle 	reads up [21:21:15] <RoanKattouw>	TrevorParscal: We don't have that planned as a feature, no, but we could [21:21:20] <RoanKattouw>	(embedding for GadgetS) [21:21:21] <Nikerabbit>	https://bugzilla.wikimedia.org/show_bug.cgi?id=34493 [21:21:40] <RoanKattouw>	Ooooh, right, you don't know the relative path there of course [21:21:41] <TrevorParscal>	well done Nikerabbit [21:22:14] <Nikerabbit>	just something I ran into few days ago [21:22:20] <TrevorParscal>	because this processing happens on the fly, side-loading an image is very costly and could make a module take ages to be served, so it's not a simple problem [21:22:31] <RoanKattouw>	Yeah these aren't simple problem [21:22:33] <RoanKattouw>	s [21:22:36] <RoanKattouw>	But let's not go in depth right now [21:22:40] <TrevorParscal>	out of curiosity are there mostly extension or core people here? [21:22:49] <Nikerabbit>	I'm both [21:22:50] <Krinkle>	TrevorParscal: Plan to allow embedding of wiki files ? [21:22:54] <RoanKattouw>	So yeah the embedding feature is a little bit incomplete but it covers the 90%-of-the-time use case [21:22:57] <Lcawte>	<-- wannabe both :/ [21:23:00] <Edokter>	I'm more of a gadget guy [21:23:03] <Krinkle>	TrevorParscal: Or semi-random urls [21:23:03] 	\o/ core representttttt [21:23:09] *varnent 	is an extension person [21:23:24] <TrevorParscal>	Krinkle: not sure, some way for gadget people to use this feature would be good though [21:23:30] <Krinkle>	varnent: Well, you have an extensive (or extendable, muhaha) personality [21:23:45] 	lol - exactly :) [21:23:56] <[Haekchen]>	OK, sorry I'm a bit late. To introduct myself: I'm the userscript guy who can't use RL without ugly hacks [21:23:59] <MikaelLindmark>	I'm a newbie extension person [21:24:00] 	in theory loading in embeddable files wouldn't be any eviler than pulling in wiki pages, either way you have to go to a potentially slow storage [21:24:03] <Edokter>	would a url like "/skins/... [21:24:13] 	is there any reason that previous ways of embedding images won't work until this is resolved in RL - i.e. can folks keep doing what they've been doing care-free? [21:24:13] 	and we already have wiki page modules in gadgets :) [21:24:16] <TrevorParscal>	so, RL mostly was designed to solve problems with extensions, RL2 focuses on adding goodies for gadgets [21:24:18] <Edokter>	would a url like "/skins/..."work? [21:24:18] <Krinkle>	TrevorParscal: Yeah, I imagine perhaps something like @wiki-embed Filename.png|23px, supporting local and remote repo's [21:24:43] <Krinkle>	TrevorParscal: But not before RL 2.1 [21:24:43] <RoanKattouw>	varnent: They can do what they were already doing, it just won't be optimized [21:24:54] 	just wanted to clarify - ty :) [21:24:58] 	before we get into RL2 [21:25:02] <RoanKattouw>	Absolute URLs are untouched by the remapper [21:25:07] <Krinkle>	first 1.1 (MW 1.19), 2.0 (Gadgets 2.0), and 2.1 (Gadgets prefs) [21:25:14] <TrevorParscal>	and that's the idea behind this system - minimize the things you have to do differently than you already did [21:25:25] <TrevorParscal>	mostly the change is in how you tell MW about your modules [21:25:30] <RoanKattouw>	[Haekchen]: What's holding you back there? Lack of support for user JS? [21:25:35] <TrevorParscal>	modules = scripts + styles + messages [21:25:50] 	excellent - so once you write your css and js files - you reference them in your extension (or tools) main php file as per the migration guide - correct? [21:25:57] <TrevorParscal>	see: http://www.mediawiki.org/wiki/ResourceLoader/Vocabulary [21:26:01] <RoanKattouw>	Yes [21:26:09] <Krinkle>	and, also part of the module information, sometimes (more often than �you might think) a list of modules that need to be loaded before this module [21:26:11] <Krinkle>	so called "dependencies" [21:26:17] <RoanKattouw>	For extension coders this should be pretty easy [21:26:27] 	TrevorParscal, thank you for defining modules [21:26:33] *brion 	wonders if RL could be used to load things into a sandboxed iframe as in my https://www.mediawiki.org/wiki/Extension:EmbedScript [21:26:37] <[Haekchen]>	Right. It would be cool to have an interface like the gadgets-definition, to define dependencies and stylesheets [21:26:37] <RoanKattouw>	You put in your .js/.css files and follow the instructions for creating modules and loading them [21:26:46] <Krinkle>	e.g. your extension might create a user interface using jquery UI buttons. You can tell the loader that it should check if jquery.ui.buttons is already loaded and if not, load it first before your module is further executed. [21:27:05] <RoanKattouw>	[Haekchen]: That's in the works for Gadgets. For user scripts it would be nice, but that'll take a little while longer [21:27:12] <TrevorParscal>	brion: as long as you load the startup module first, you are good to go [21:27:21] 	i'll have to experiment :DD [21:27:31] <TrevorParscal>	the startup module will get mw and jquery there as well [21:27:38] 	really want to be able to do libraries with that, and RL woul dbe a great fit [21:27:50] <TrevorParscal>	from there on out, you can just use mw.loader.load or mw.loader.using [21:27:53] <[Haekchen]>	And a big thing is the third part of RL, as mentioned in your RL presentation: the I18n [21:28:17] <RoanKattouw>	brion: You might like to know that Trevor and I are also sort-of-working (in our copious non-existent free time) on a "rewrite" of RL (really an RL-like system) in Node.js [21:28:17] <Krinkle>	[Haekchen]: We're hoping though with Gadgest 2.0 (coming soon) that gadgets will be more accessible and more used and more shared. Basically reducing/discouraging somewhat the use of plain user scripts. Because at a gadget level there more possibilities,. [21:28:33] <RoanKattouw>	Yes, i18n is a great benefit of ResourceLoader too [21:28:33] 	dang :D [21:28:35] <Krinkle>	[Haekchen]: One of the things we want to do is split gadget management away from the general sysop-tasks [21:28:52] <RoanKattouw>	So yeah unless anyone else has any questions or remarks about the current state of RL, let's move on to the future [21:29:10] <RoanKattouw>	The future is called RL2 and that's basically what Krinkle and [Haekchen] are talking about now: bringing RL to Gadgets [21:29:11] 	one quick clarifier :) [21:29:14] *TrevorParscal 	already ported CSSJanus to Node.js -> https://github.com/trevorparscal/xchange/tree/master/lib/xform/lib [21:29:15] <RoanKattouw>	Sure [21:29:15] <DanielRenfro>	\me is an extension person, who forgot to hit <ENTER> [21:29:20] <[Haekchen]>	Krinkle: That would be cool, but I think not every userscript should be provided as a gagdet [21:29:24] *RoanKattouw 	doesn't want to move too quickly [21:29:27] <DanielRenfro>	and gets slashes wrong [21:29:27] <Krinkle>	[Haekchen]: Yep [21:29:37] <Nikerabbit>	does that also mean centralised gadget repository (including centralised translation of gadgets)? [21:29:41] 	so once the code is in your main php file (as you were) - the next step is loading them in the various functions they're needed for - or will they then be loaded when your extension is called (such as css) and you can merely reference/call them as needed? [21:29:51] <Krinkle>	[Haekchen]: But many user scripts should really be gadgets. And many gadgets should be shared amongst wikis instead of copied from wiki to wiki waiting to be outdated. [21:30:22] *varnent 	asking questions I've seen asked in various forms numerous times :) [21:30:28] <RoanKattouw>	varnent: No, you need to explicitly load them [21:30:31] <TrevorParscal>	varnent: you need to tell $wgOut to load it [21:30:54] <RoanKattouw>	So, first thing you do is you define the module, that's documented at https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Registering_a_module [21:30:54] <[Haekchen]>	Also I'm missing support for translation of script messages. How can I define script-only system messages to be translated? [21:30:59] <TrevorParscal>	$wgOut->addModules( array( 'foo', 'bar' ) ); [21:31:11] <[Haekchen]>	And how could I include these messages? [21:31:26] <RoanKattouw>	To actually load it, yuo need to call addModules, see https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Adding_a_module_to_a_page [21:31:31] <RoanKattouw>	[Haekchen]: For an extension module? [21:31:34] 	I think that's a part that has confused some folks - they think adding it to the main file will then fully load them - just wanted to clarify that :) [21:31:47] 	sorry for digression - return to RL2  :) [21:31:58] <RoanKattouw>	varnent: Yeah, so no it doesn't work that way, you have to tell it to load it. The whole point of that is to avoid loading superfluous things [21:32:02] <[Haekchen]>	RoanKattouw: No, still only for userscripts. No extensions [21:32:22] <RoanKattouw>	[Haekchen]: Right now user scripts cannot load i18n. Gadgets will be able to in RL2 [21:32:30] <Krinkle>	[Haekchen]: user scripts have no module definition and as such cannot make use of the module i18n system yet. [21:32:56] <[Haekchen]>	Yes, thats the problem today - how can we change that? [21:32:58] <RoanKattouw>	Basically you would just put a list of the message keys you need in the module definition. For core and extensions, that definition lives in a PHP file, for Gadgets that will live on a definition page [21:33:13] <RoanKattouw>	Well, I'm hoping that we can improve user script support in a future version of RL [21:33:20] <Krinkle>	[Haekchen]: Not related to ResourceLoader, but PM me and I can explain how to do it in a user script today. [21:33:21] <RoanKattouw>	But we have our hands full with Gadgets right now [21:33:52] <RoanKattouw>	So we're gonna finish the planned Gadgets support first, then see what else we want to do. User scripts are definitely on our radar for that [21:34:27] <RoanKattouw>	(The progress on Gadgets support (AKA RL2) has been a bit slow because Krinkle and I have both been very busy IRL. Like, I just moved across an ocean :D ) [21:34:57] 	is it slated for MW1.20 or not roadmapped that specifically yet? [21:35:06] <RoanKattouw>	It's not tied to an MW release [21:35:23] <RoanKattouw>	Because we really just rewrote the Gadgets extension, and the core support that was needed was added in 1.19 [21:35:45] 	so RL2 comes alive via the Gadgets extension rather than core [21:35:45] <RoanKattouw>	There is still some polishing work to be done, we're hoping to finish it this month but I fear that might be a bit optimistic still [21:35:48] <RoanKattouw>	Yes [21:35:51] <RoanKattouw>	RL2 is all about Gadgets [21:36:01] 	RL2: Gadget Edition [21:36:02] 	gotcha [21:36:03] <RoanKattouw>	Basically what RL2 does is it makes every Gadget a module [21:36:26] *varnent 	hoping trevor feels more himself now [21:36:38] *TrevorParscal 	hates office wifi [21:36:40] <RoanKattouw>	Instead of having one page (MediaWiki:Gadgets-definition) where all Gadgets are defined as a bullet list, there is a separate page for each gadget (Gadget definition:HotCat.js) [21:36:45] <RoanKattouw>	TrevorParscal: Dude, wire up [21:36:48] <^demon>	RoanKattouw: Is RL2 any better performance-wise? [21:36:56] *TrevorParscal 	is wired.. now :( [21:37:12] <RoanKattouw>	^demon: No, there are no significant performance improvements in RL2, it's mostly feature improvements [21:37:20] <RoanKattouw>	But [21:37:33] <RoanKattouw>	There is another cool RL2 feature that will facilitate performance improvements [21:37:34] <Reedy>	Anyone got Kaldari in view? [21:37:39] <RoanKattouw>	RL2 will allow Gadgets to be shared between wikis [21:37:50] 	that's cool [21:37:59] <RoanKattouw>	So WMF could have a central Gadget repository (say mediawiki.org), host all Gadgets there, and then other wikis can pull them in as needed [21:38:08] <DanielRenfro>	^liking that idea [21:38:10] <^demon>	How does that affect RL performance? [21:38:16] 	including 3rd party wikis or just wmf wikis? [21:38:18] <RoanKattouw>	That way the code lives in one place only and isn't duplicated all over the damn place with each wiki using subtly different outdated copies [21:38:32] <Krinkle>	^demon: it doesn't affect RL performance it affects gadget performance as a while [21:38:33] <RoanKattouw>	varnent: 3rd parties too. We'll have an InstantCommons equivalent for Gadgets [21:38:34] <Krinkle>	whole [21:38:39] <Krinkle>	^demon: Right now there are no cross-wiki gadgets [21:38:43] <RoanKattouw>	^demon: Well currently, shared gadgets exist [21:38:44] <DanielRenfro>	whoo! 3rd party wikis! [21:38:46] 	that is very cool indeed - yes [21:38:48] <RoanKattouw>	But you have to bypass RL to share them [21:38:51] <Krinkle>	^demon: So although a gadget may be loaded with ResourceLoader in the local wiki� [21:39:04] <Krinkle>	^demon: ??? it will be loaded via importScriptURI action=raw when references on another wiki [21:39:05] <RoanKattouw>	To the tune of importScriptURI('http://otherwiki.com/w/index.php?action=raw&...') [21:39:05] <Krinkle>	unminified [21:39:13] <^demon>	Omg, ping attack. [21:39:14] *^demon 	hides [21:39:25] <DanielRenfro>	that doesn't conflict with the same-domain policy? [21:39:25] <RoanKattouw>	So that method of sharing Gadgets works, but bypasses all of RL's performance improvements [21:39:35] <RoanKattouw>	DanielRenfro: Nope, you can execute JS from any domain [21:39:46] <RoanKattouw>	RL already loads all JS from a separate domain (bits.wikimedia.org) [21:40:08] 	is that true of 3rd party's as well? [21:40:09] <^demon>	RoanKattouw: I'd like to see some under-the-hood work :) I've never delved into RL, but I've seen a lot of anecdotal evidence that load.php calls are *slow* as hell. [21:40:13] *varnent 	didn't know that [21:40:13] <RoanKattouw>	And that's totally fine; I mean there are places that load jQuery from a CDN, that's also cross-domain, works fine [21:40:18] <Krinkle>	DanielRenfro: Same-Origin-Policy only applies to iframe access and Ajax requests that read content. [21:40:24] <^demon>	For the majority of 3rd-party sites without varnish and other fancy things, that's a performance drain. [21:40:28] <RoanKattouw>	^demon: They can be, which is why they're cached to hell and back [21:40:32] <DanielRenfro>	gotcah [21:40:36] <RoanKattouw>	Aaron implemented file cache for RL for that reason [21:40:37] <Krinkle>	DanielRenfro: Otherwise half of the web wouldn't work. [21:40:55] <[Haekchen]>	I just believe we would run into problems with a too huge set of modules sometime (especially when often-used userscripts/gadgets become supported). The List of modules delivered along in each page already is very long, are there any thoughts to reduces that? [21:41:09] <^demon>	RoanKattouw: If you configure it as such, yeah. Maybe we need to tweak defaults--because out-of-the-box MediaWiki is painfully slow. [21:41:10] *DanielRenfro 	stays mostly serverside [21:41:18] <^demon>	(That may be something we can investigate generally) [21:41:19] <RoanKattouw>	^demon: Yeah we probably should [21:41:38] <RoanKattouw>	[Haekchen]: Loading a hundred modules is fine as long as they aren't all huge [21:41:40] 	^demon: agreed [21:41:59] <RoanKattouw>	What matters is mostly how much code you're loading; how many modules it's split up in doesn't matter much [21:42:22] 	where there any other lingering questions about RL2? [21:42:36] <RoanKattouw>	Or hmm, I think you're talking about the size of the 'startup module' which lists all modules. Yeah, that'll grow, but I don't foresee that becoming a problem just yet [21:42:56] 	is there anything RL2.1 and beyond you'd like to share/elaborate on? [21:43:01] <[Haekchen]>	RoanKattouw: No, I'm not about loading many modules, but delivering the dependecy / registration information. I think the number of registered modules will grow very large with the time [21:43:11] <RoanKattouw>	Yeah, that's possible [21:43:24] <RoanKattouw>	I think we'll cross that bridge when we come to it [21:43:47] <RoanKattouw>	Plans for RL2.1 and beyond haven't really been made yet [21:43:54] <RoanKattouw>	We have some ideas for things we want to do but nothing firm yet [21:44:19] <RoanKattouw>	For instance, we'd like to provide a way for people to stage Gadgets for themselves only without having to change them for all users [21:44:31] <RoanKattouw>	We'd also like to bring some sort of support to user scripts [21:44:36] <[Haekchen]>	Might it be possilble to request modules that have not been registered? [21:45:40] <[Haekchen]>	The server could resolve the url (crosswiki?) and deliver a script, just fetching its dependency information when requested. [21:46:04] <RoanKattouw>	Maybe [21:46:17] <RoanKattouw>	We'll have to think about that when we plan for the next version [21:46:26] 	btw - unless there are any objections - we'll move into Q&A (although we've had some of that already) - we'll try to field one at a time for logic/reason - but feel free to "ping" that you have a question :) [21:46:41] <Krinkle>	It's important to understand that the biggest reason it's technically hard to improve or support 'user scripts' is that technically 'user scripts' do not exist. [21:46:45] <RoanKattouw>	We're effectively already Q&Aing, so yeah sure, go ahead :) [21:46:59] <Krinkle>	There is no such feature in MediaWiki. User invented it themselves, which is great. [21:47:14] 	yeah - seemed to have naturally flowed to that - but in case anyone was holding back til this point :) [21:47:26] <[Haekchen]>	Krinkle: What do you mean "they don't exist"? [21:47:37] <RoanKattouw>	Good point. So yeah, all questions are welcome now, please do bury us in questions :) [21:47:54] <Krinkle>	[Haekchen]: They are 100% on the loose, maintained fully on the wiki and shared by users. [21:47:58] <RoanKattouw>	[Haekchen]: Using stuff like User:Haekchen/Foobar.js as a user script is not explicitly supported, it's facilited by importScript et al [21:48:22] <Krinkle>	There is no recognition for it as a 'function', it just works as general html/css/javascript. not a mediawiki feature. [21:48:25] <RoanKattouw>	MediaWiki just loads User:Haekchen/vector.js for you and your JS takes it from there [21:48:58] <Krinkle>	For them to have MediaWiki abilities (like extension modules and gadgets) they first need to become part of the general flow. [21:49:02] <RoanKattouw>	So for user scripts what we need to do is change the feature so it fits the way it's actually being used, rather than how it was originally designed [21:49:07] <[Haekchen]>	Yes, that's why there are frameworks to deal with user script dependencies [21:49:17] <Krinkle>	Which doesn't mean everything has to change, we'll everything we can to make the migration smooth or even invisible. [21:49:18] <RoanKattouw>	Right [21:49:34] <RoanKattouw>	Of course that they have to exist is kind of crazy, because we have RL as a dependency management framework [21:49:35] <Krinkle>	but there'll be a lot of changes that have to made for user scripts to 'work', most of which hopefully nobody will notice :) [21:49:58] <RoanKattouw>	So RL needs to be molded around the way user scripts are being used in practice [21:50:03] <Krinkle>	yep [21:50:35] 	Which file is the entry point for RL? [21:50:38] <[Haekchen]>	It would be cool to request a module "de:wp:user:Haekchen/library", and it would load that and trigger moduel events for it [21:50:56] <Krinkle>	aharoni: You mean load.php ? [21:51:12] 	brion: got a sec? i could use some help figuring out how to add support something similar to $wgMobileDomain but in the path portion of the URL [21:51:17] <Krinkle>	aharoni: That's the internal entry point, don't interact with it directly (other than for debugging) [21:51:29] <DanielRenfro>	What is the prefered way to override the jQueryUI styles (without changing core files) ? [21:51:35] <Krinkle>	mw.loader.load is the end user entry point for module loading, (or mw.loader.using ) [21:51:39] 	Probably. [21:51:43] <Krinkle>	DanielRenfro: From an extension? [21:51:52] <[Haekchen]>	That would be enought in the first step, I think. Dependencies, attached css files, translations could come in later [21:51:54] <DanielRenfro>	Krinkle: probably from an extension [21:52:13] <Krinkle>	DanielRenfro: Create a jQuery ui theme folder (just like core has a 'default' and a 'vector' folder') and register it as module and load it [21:52:33] <TrevorParscal>	it's important to remember that .using and .load aren't needed if you used $wgOut->addModules for the modules [21:52:41] <Krinkle>	indeed [21:52:46] <DanielRenfro>	Krinkle: noted. I'll try it out. thanks. [21:52:56] <Krinkle>	For extensions mw.loader.load/using is not really relevant, that's more for user scripts that don't use modules [21:53:03] <TrevorParscal>	.using and .load will allow loading things when you need them, as in, after the page is done loading [21:53:31] <Krinkle>	.. or lazy loading after the page is ready from inside a script ^ [21:53:37] <TrevorParscal>	sometimes extensions use it to lazy load something - like loading jquery-ui only after the user clicks a button that will need it [21:53:56] <Krinkle>	I like how the three of us spend time typing roughly the same [21:53:56] <Krinkle>	:P [21:54:04] <TrevorParscal>	lolz [21:54:31] 	lol - it's actually pretty amusing as you all convey it in slightly differently ways - which is great for folks who comprehend things in different ways :) [21:55:03] <RoanKattouw>	TrevorParscal: I can haz CR? https://www.mediawiki.org/wiki/Special:Code/MediaWiki/112179 [21:55:07] 	were there any other lingering questions from folks? [21:55:31] 	if you have a general development question that's been pestering you - now is a good time to ask that as well  :) [21:55:56] <TrevorParscal>	Krinkle: well done [21:55:59] <MikaelLindmark>	I'll have a go. [21:56:08] 	excellent :) [21:56:40] <Krinkle>	TrevorParscal: the Ie7 hack? [21:56:42] 	I would be satisfied if it would work as it should. E.g. when you add a dependency to a gadget in Gadgets-definintion but not for all modules and attempt to load that module with mw.loader.using it is not loaded and mw.loader.getState tells you it is "loading" without doing so (I inspected the DOM) [21:56:47] <TrevorParscal>	Krinkle: yes [21:57:26] <RoanKattouw>	rillke: Could you explain the bug a little more clearly? [21:57:56] 	Just curious: why is it needed to load i18n messages explicitly? Is there a reason to load only some of them? [21:57:58] <MikaelLindmark>	It's a newbie question:I can't find a hook for the "main area" that are not a victim of the cache. [21:58:48] <RoanKattouw>	aharoni: The i18n messages live on the server (PHP), so they have to be brought to the client (JS). We don't want to load on-demand (slow) and we don't want to load more than necessary, so we make you tell us what you're gonna need in advance, so we can batch it up and load it efficiently [21:58:55] 	Example: 1) MediaWiki:Gadgets-definition: Cat-a-lot[ResourceLoader|dependencies=jquery.ui.dialog]|Cat-a-lot.js|Cat-a-lot.css [21:58:57] <MikaelLindmark>	ParserBeforeStrip is not run on cached page content [21:59:14] <Krinkle>	TrevorParscal: I am hardly the first person to use that hack, but thanks :) [21:59:21] 	mw.loader.using(['jquery.ui.dialog', 'jquery.ui.autocomplete'], function { [21:59:34] *Krinkle 	should disable stalk on 'mw.loader' for now [21:59:41] 	in MediaWiki:Gadget-Cat-a-lot.js [22:00:12] 	Result: the code inside, function { XXX } is never executed [22:00:32] <RoanKattouw>	OK, yeah it looks like that should load jui autocomplete (because jui dialog is already there, it's a dependency), then fire the callback [22:00:33] <DanielRenfro>	MikaelLindmark: let me make sure I understand, you are looking for a hook that will let you edit the raw wikitext of a page (not a cached version of the wikitext), correct? [22:00:40] <RoanKattouw>	That's a strange bug, I'll investigate that [22:00:45] <MikaelLindmark>	yes [22:00:48] <RoanKattouw>	rillke: You got a gadget with that code lying around somewhere? Link? [22:01:03] *DanielRenfro 	searches documentation at http://www.mediawiki.org/wiki/Manual:Hooks... [22:01:12] <MikaelLindmark>	DanielRenfro: ParserBeforeTidy is all over the place ;) [22:01:26] 	MediaWiki:Gadget-Cat-a-lot.js @commons [22:01:40] 	https://secure.wikimedia.org/wikipedia/commons/wiki/MediaWiki:Gadget-Cat-a-lot.js [22:02:27] 	mw.loader.getState('jquery.ui.autocomplete') returned "loading" [22:02:52] 	but there was no call to load.php for module jquery.ui.autocomplete [22:02:56] <RoanKattouw>	secure.wm.o? *shudder* [22:03:15] <MikaelLindmark>	DanielRenfro: "Page Rendering" is rather large [22:03:21] <RoanKattouw>	We have real https now: [22:03:23] <RoanKattouw>	https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Cat-a-lot.js [22:03:35] <[Haekchen]>	RoanKattouw: +1 [22:03:41] <DanielRenfro>	MikaelLindmark:  I think ParserBeforeTidy is what you want [22:03:48] 	thanks. I sometimes like to do cross domain XHRs [22:04:16] <DanielRenfro>	MikaelLindmark:  it gives you a $parser variable, and a $text variable (which should hold all the wikitext of the page.) [22:05:13] <MikaelLindmark>	DanielRenfro: But's all over the place. See http://www.kira.se/devwiki/w/index.php/Main_Page [22:05:14] 	mindful of time - I want to "officially" wrap the workshop up - but folks are welcome to stay, chat and ask questions (the room isn't closing and many folks will be in this room) [22:05:56] 	thank you RoanKattouw, TrevorParscal and Krinkle for their lending their expertise - especially during such a hectic month - we truly do appreciate it :) [22:06:10] 	Yes, thank you. [22:06:12] 	thank you to all of our developers and experts for helping field questions and such  :) [22:06:15] <MikaelLindmark>	DanielRenfro: It's in the botom, in the Validate box and in the main area [22:06:24] <TrevorParscal>	no worries [22:06:35] <DanielRenfro>	MikaelLindmark: ah, I see [22:06:37] <Krinkle>	You're welcome [22:06:48] 	a transcript of this will be posted on https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Workshops