at least, load site js first.

Wiki.Melancholie wrote:

Gadget scripts are meant here, they now get loaded before
/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook
That's bad.

Assigning to Michael on the assumption that this is related to the script loader changes. :)

not gadget scripts only, also wikibits.js etc.

we should move site js to the top.

mdale wrote:

hmm output flow is a bit of a mess trying to clean up ... we want sitejs above wikibits.js? I think we want sitejs right after core scripts no?

Wiki.Melancholie wrote:

No, wikibits.js has to remain the very first.
Common.js, Monobook.js etc. heavily depend on stuff provided by wikibits.js ;-)

But the gadget scripts seem to have changed their position in source code, although they may depend on site scripts (now coming afterwards).

Wiki.Melancholie wrote:

1. Core
2. Site
3. Gadget
4. User

Wiki.Melancholie wrote:

Not quite sure, but shouldn't the line

<script type="text/javascript"
src="/w/extensions/FlaggedRevs/flaggedrevs.js?60"></script>

come directly after the core scripts? At the moment it comes last (</head>); maybe there is a reason for this, but if not it should be grouped with all the other core & extension scripts (like centralnotice.js e.g.).

Please see also bug 20690.

mdale wrote:

oky see commit 56746 moved to the

1. Core ( wikibits.js , jquery etc)
2. Site ( MediaWiki:Common.js, MediaWiki:Monobook.js, etc )
3. Extensions ( any extension that adds to mScripts or makes an outputPage->addScript* call at any time)
4. User ( the user page User:$name$/monobook.js etc)

Script includes with scriptloader enabled is the following:

1. core scripts
2. everything else in the above order that uses new Output page calls (addScriptFile, addScriptClass)
3. things added with outputPage->addScript

make a link: r56746

Wiki.Melancholie wrote:

3. Extensions ( any extension that adds to mScripts or makes an outputPage->addScript* call at any time)

Hmm, wouldn't

1. Core
2. Extensions
3. Site
4. Gadget
5. User

be better (I considered "Extensions" being pretty much "Core" in comment #7, sorry)? Meaning extensions scripts coming second, _right_ after core scripts, instead after site scripts.

With site, gadget and user scripts the communities and users can use functions as well as use or adapt variables/arrays of core and extension scripts.

If extension scripts now will come after MediaWiki:Common.js and MediaWiki:Monobook.js, communities cannot customize vaiables e.g.

mdale wrote:

Comment #11 makes sense. But will require some modifications to the gadget & outputpage since Gadget is itself an extension and there is presently no way to call "add script after site but before user" from an extension :( .. We would have to add a few more "hooks".

At any rate this is only an intermediary solution to configuration problem. We eventually want a system for the script-loader to package in configuration that is stored in a database and requested on a per Script-Class level (similar to how we package in the language msgs). This way we can have actual interfaces for customizing configuration instead of having to modify the JS files or modify mediaWiki pages with JS code). This should be part of the overall configuration flatfile to db rewrite.

In the mean time .. we can structure development so the order does not matter so much... doing all configuration with inline-execution and inheriting the defaults onDomReady: see how editPage.js is structured in customizing the add-media-wizard: http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/js2/editPage.js

another made up example for configuration handling :

core script editPage.js

if(! wgConfigToolbar )
wgConfigToolbar = {};

//the default configuration is short since the wikiEditor application supplies its own "defaults"
wgDefaultToolBarSettings = { 'enabledModules':['sidepanel', 'help', 'tocnav'], 'otherDefaults: ['values'] };

js2AddOnloadHook( function() {
also see http://docs.jquery.com/Utilities/jQuery.extend
wgConfigToolbar = $j.extend(true, wgDefaultToolBarSettings, wgConfigToolbar);
$j('#textEditBox').wikiEdit( wgConfigToolbar );
}
the regardless of the order any script can set the configuration (although last scripts included wins where there are conflicts )

script site js

if(! wgConfigToolbar)
wgConfigToolbar = {};
wgConfigToolbar = $j.extend(wgConfigToolbar, { enabledModules: ['licenceHelper'] });

script addEditWidget.js

if(! wgConfigToolbar)
wgConfigToolbar = {};

wgConfigToolbar = $j.extend(wgConfigToolbar, { 'enabledModules': ['myCustomTool'], //array will be "merged" and default settings
'customModules':{

		myCustomTool:function( wikiEditObj ){
			wikiEditObj.getTextSelection();
			//custom toolbar calls here
			wikiEditObj.insertBefore( 'my custom insert');
			//etc
		}

}
}
//alternatively extension code can depend on core stuff being ready at js2AddOnloadHook time so:
js2AddOnloadHook(function(){
$j('#textEditBox').wikiEdit('addToolModule', :function( wikiEditObj ){

			wikiEditObj.getTextSelection();
			//custom toolbar calls here
			wikiEditObj.insertBefore( 'my custom insert');
			//etc
		}

); //could also work.
});

Wiki.Melancholie wrote:

Ah, okay. So it's currently (but not yet live):

1. Core
2. Site
3. Extensions (incl. Gadget (and maybe other 'group JS/CSS scripting' extensions out there)
4. User

That's ok for the moment, I think.
Like that, it at least seems to be like it was before (fixing this bug), I guess.