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

/*
 * JavaScript for WikiEditor Toolbar
 */

$( document ).ready( function() {
	if ( !$.wikiEditor.isSupported( $.wikiEditor.modules.toolbar ) ) {
		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`
			`*/`
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			`$( document ).ready( function() {`
			`if ( !$.wikiEditor.isSupported( $.wikiEditor.modules.toolbar ) ) {`
			`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' )`
A bit of a reorganisation that fixes bug 27164. Basically the extensive configuration in the ext.wikieditor.* functions is moved to the jquery plugins, to be able to use these configurations in other extensions which don't have a #wpTextbox1. Please review this to check if this is the right way to do it! 2011-02-24 01:45:55 +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			`} );`