mediawiki-extensions-WikiEd.../modules/ext.wikiEditor.toolbar.js

/*
 * JavaScript for WikiEditor Toolbar
 */
jQuery( document ).ready( function ( $ ) {
	if ( !$.wikiEditor.isSupported( $.wikiEditor.modules.toolbar ) ) {
		$( '.wikiEditor-oldToolbar' ).show();
		return;
	}
	// The old toolbar is still in place and needs to be removed so there aren't two toolbars
	$( '#toolbar' ).remove();
	// Add toolbar module
	// TODO: Implement .wikiEditor( 'remove' )
	$( '#wpTextbox1' ).wikiEditor(
		'addModule', $.wikiEditor.modules.toolbar.config.getDefaultConfig()
	);
} );
Lots of refactoring. This still does not work! But it's getting close. 2010-09-15 22:40:50 +00:00			`/*`
			`* JavaScript for WikiEditor Toolbar`
			`*/`
Peserve jQuery references to avoid conflicts * Added closures for jQuery where missing. * Added closures for mediaWiki where missing. * Using ready( $ ) where possible. * Removed empty CSS block. Change-Id: Ifdd4b10063221a4967d812eafd43858623ec5d28 2013-10-30 16:53:24 +00:00			`jQuery( document ).ready( function ( $ ) {`
Lots of refactoring. This still does not work! But it's getting close. 2010-09-15 22:40:50 +00:00			`if ( !$.wikiEditor.isSupported( $.wikiEditor.modules.toolbar ) ) {`
(bug 34885) Fixes issue where old toolbar was killed, even when the new toolbar was incompatible Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently. Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c 2012-04-17 22:19:03 +00:00			`$( '.wikiEditor-oldToolbar' ).show();`
Lots of refactoring. This still does not work! But it's getting close. 2010-09-15 22:40:50 +00:00			`return;`
Copied over all the resources needed to make WikiEditor stand on it's own two feet. Lots more to do as far as organizing and fleshing out the extensions's PHP bits. 2010-09-15 03:08:35 +00:00			`}`
Lots of refactoring. This still does not work! But it's getting close. 2010-09-15 22:40:50 +00:00			`// The old toolbar is still in place and needs to be removed so there aren't two toolbars`
			`$( '#toolbar' ).remove();`
			`// Add toolbar module`
(bug 25339) Allow specifying separate base paths for local and remote paths in ResourceLoaderFileModule::__construct(). Extensions can use this to properly point the resource loader to their resources in a way that doesn't depend on the extensions/ directory being a subdirectory of phase3/ on the filesystem and that respects $wgExtensionAssetsPath. Also converted all extensions using ResourceLoader to use this approach, except MWEmbed which uses way more indirection building its module registrations than I can deal with after midnight. What actually happens here * Add $localBasePath, $remoteBasePath params to the FileModule constructor, defaulting to $IP and $wgScriptPath respectively * Add getLocalPath() and getRemotePath(), which use this information to build a proper FS or URL path for a file * Make readScriptFiles() non-static so it can use these functions * Run every single file path we use through either getLocalPath() or getRemotePath() as appropriate ** Except file dependencies, these are already prefixed. Our inability to give them special treatment caused bugs earlier * Kill prefixFilePathList() and resolveFilePath(), no longer needed 2010-10-27 22:22:10 +00:00			`// TODO: Implement .wikiEditor( 'remove' )`
(bug 34885) Fixes issue where old toolbar was killed, even when the new toolbar was incompatible Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently. Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c 2012-04-17 22:19:03 +00:00			`$( '#wpTextbox1' ).wikiEditor(`
			`'addModule', $.wikiEditor.modules.toolbar.config.getDefaultConfig()`
			`);`
Lots of refactoring. This still does not work! But it's getting close. 2010-09-15 22:40:50 +00:00			`} );`