2013-07-03 22:14:52 +00:00
|
|
|
/*!
|
|
|
|
* VisualEditor MediaWiki ViewPageTarget init.
|
|
|
|
*
|
|
|
|
* This file must remain as widely compatible as the base compatibility
|
|
|
|
* for MediaWiki itself (see mediawiki/core:/resources/startup.js).
|
|
|
|
* Avoid use of: ES5, SVG, HTML5 DOM, ContentEditable etc.
|
|
|
|
*
|
2014-01-05 12:05:05 +00:00
|
|
|
* @copyright 2011-2014 VisualEditor Team and others; see AUTHORS.txt
|
2013-07-03 22:14:52 +00:00
|
|
|
* @license The MIT License (MIT); see LICENSE.txt
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*global mw */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Platform preparation for the MediaWiki view page. This loads (when user needs it) the
|
|
|
|
* actual MediaWiki integration and VisualEditor library.
|
|
|
|
*
|
|
|
|
* @class ve.init.mw.ViewPageTarget.init
|
|
|
|
* @singleton
|
|
|
|
*/
|
|
|
|
( function () {
|
2013-08-02 20:25:44 +00:00
|
|
|
var conf, tabMessages, uri, pageExists, viewUri, veEditUri, isViewPage,
|
2013-09-30 16:18:46 +00:00
|
|
|
init, support, getTargetDeferred, enable, userPrefEnabled,
|
Infrastructure for loading plugins in the MW integration
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.
When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.
This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.
User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.
If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );
For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)
VisualEditor.php:
* Add $wgVisualEditorPluginModules
VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS
ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
values in an array and passes them into the mw.Target when it's
being initialized
ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
to load this.modules plus user and site, and fire onModulesReady()
when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
returned promises, wait for all of them to be resolved, then resolve
this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
using a second using() call
Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
2013-07-22 20:34:28 +00:00
|
|
|
plugins = [];
|
2013-07-03 22:14:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Use deferreds to avoid loading and instantiating Target multiple times.
|
2013-07-31 22:53:29 +00:00
|
|
|
* @returns {jQuery.Promise}
|
2013-07-03 22:14:52 +00:00
|
|
|
*/
|
|
|
|
function getTarget() {
|
|
|
|
var loadTargetDeferred;
|
|
|
|
if ( !getTargetDeferred ) {
|
|
|
|
getTargetDeferred = $.Deferred();
|
|
|
|
loadTargetDeferred = $.Deferred()
|
|
|
|
.done( function () {
|
2014-04-01 20:17:58 +00:00
|
|
|
var debugBar, target = new ve.init.mw.ViewPageTarget();
|
2013-07-03 22:14:52 +00:00
|
|
|
ve.init.mw.targets.push( target );
|
2013-07-05 06:01:31 +00:00
|
|
|
|
2014-04-01 20:17:58 +00:00
|
|
|
if ( ve.debug ) {
|
|
|
|
debugBar = new ve.init.DebugBar();
|
|
|
|
target.on( 'surfaceReady', function () {
|
|
|
|
$( '#content' ).append( debugBar.$element.show() );
|
|
|
|
debugBar.attachToSurface( target.surface );
|
|
|
|
target.surface.on( 'destroy', function () {
|
|
|
|
debugBar.$element.hide();
|
|
|
|
} );
|
|
|
|
} );
|
|
|
|
}
|
|
|
|
|
2014-01-16 20:33:14 +00:00
|
|
|
// Tee tracked events to MediaWiki firehose, if available (1.23+).
|
|
|
|
if ( mw.track ) {
|
|
|
|
ve.trackSubscribeAll( function ( topic, data ) {
|
|
|
|
mw.track.call( null, 've.' + topic, data );
|
|
|
|
} );
|
|
|
|
}
|
|
|
|
|
2013-07-05 06:01:31 +00:00
|
|
|
// Transfer methods
|
2013-08-04 14:09:04 +00:00
|
|
|
ve.init.mw.ViewPageTarget.prototype.setupSectionEditLinks = init.setupSectionLinks;
|
2013-07-05 06:01:31 +00:00
|
|
|
|
Infrastructure for loading plugins in the MW integration
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.
When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.
This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.
User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.
If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );
For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)
VisualEditor.php:
* Add $wgVisualEditorPluginModules
VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS
ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
values in an array and passes them into the mw.Target when it's
being initialized
ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
to load this.modules plus user and site, and fire onModulesReady()
when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
returned promises, wait for all of them to be resolved, then resolve
this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
using a second using() call
Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
2013-07-22 20:34:28 +00:00
|
|
|
// Add plugins
|
|
|
|
target.addPlugins( plugins );
|
|
|
|
|
2013-07-03 22:14:52 +00:00
|
|
|
getTargetDeferred.resolve( target );
|
|
|
|
} )
|
|
|
|
.fail( getTargetDeferred.reject );
|
|
|
|
|
|
|
|
mw.loader.using( 'ext.visualEditor.viewPageTarget', loadTargetDeferred.resolve, loadTargetDeferred.reject );
|
|
|
|
}
|
|
|
|
return getTargetDeferred.promise();
|
|
|
|
}
|
|
|
|
|
|
|
|
conf = mw.config.get( 'wgVisualEditorConfig' );
|
2013-08-02 20:25:44 +00:00
|
|
|
tabMessages = conf.tabMessages;
|
2013-07-03 22:14:52 +00:00
|
|
|
uri = new mw.Uri();
|
2013-09-04 20:07:27 +00:00
|
|
|
// BUG 49000: For special pages, no information about page existence is
|
|
|
|
// exposed to mw.config (see BUG 53774), so we assume it exists.
|
2013-08-01 22:50:33 +00:00
|
|
|
pageExists = !!mw.config.get( 'wgArticleId' ) || mw.config.get( 'wgNamespaceNumber' ) < 0;
|
2013-11-07 22:21:08 +00:00
|
|
|
viewUri = new mw.Uri( mw.util.getUrl( mw.config.get( 'wgRelevantPageName' ) ) );
|
2013-07-03 22:14:52 +00:00
|
|
|
veEditUri = viewUri.clone().extend( { 'veaction': 'edit' } );
|
|
|
|
isViewPage = (
|
2013-08-01 22:14:51 +00:00
|
|
|
mw.config.get( 'wgIsArticle' ) &&
|
2013-07-03 22:14:52 +00:00
|
|
|
!( 'diff' in uri.query )
|
|
|
|
);
|
|
|
|
|
2013-07-19 01:56:25 +00:00
|
|
|
support = {
|
2013-07-26 20:20:10 +00:00
|
|
|
es5: !!(
|
2013-07-19 01:56:25 +00:00
|
|
|
// It would be much easier to do a quick inline function that asserts "use strict"
|
|
|
|
// works, but since IE9 doesn't support strict mode (and we don't use strict mode) we
|
|
|
|
// have to instead list all the ES5 features we do use.
|
|
|
|
Array.isArray &&
|
|
|
|
Array.prototype.filter &&
|
|
|
|
Array.prototype.indexOf &&
|
|
|
|
Array.prototype.map &&
|
2013-07-31 20:10:28 +00:00
|
|
|
Date.now &&
|
2013-07-19 01:56:25 +00:00
|
|
|
Date.prototype.toJSON &&
|
|
|
|
Object.create &&
|
|
|
|
Object.keys &&
|
|
|
|
String.prototype.trim &&
|
|
|
|
window.JSON &&
|
|
|
|
JSON.parse &&
|
|
|
|
JSON.stringify
|
|
|
|
),
|
|
|
|
contentEditable: 'contentEditable' in document.createElement( 'div' )
|
|
|
|
};
|
2013-07-03 22:14:52 +00:00
|
|
|
|
|
|
|
init = {
|
|
|
|
|
2013-07-19 01:56:25 +00:00
|
|
|
support: support,
|
2013-07-03 22:14:52 +00:00
|
|
|
|
2013-10-10 12:33:49 +00:00
|
|
|
blacklist: conf.blacklist,
|
2013-07-03 22:14:52 +00:00
|
|
|
|
Infrastructure for loading plugins in the MW integration
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.
When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.
This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.
User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.
If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );
For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)
VisualEditor.php:
* Add $wgVisualEditorPluginModules
VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS
ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
values in an array and passes them into the mw.Target when it's
being initialized
ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
to load this.modules plus user and site, and fire onModulesReady()
when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
returned promises, wait for all of them to be resolved, then resolve
this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
using a second using() call
Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
2013-07-22 20:34:28 +00:00
|
|
|
/**
|
|
|
|
* Add a plugin module or function.
|
|
|
|
*
|
|
|
|
* Plugins are run after VisualEditor is loaded, but before it is initialized. This allows
|
|
|
|
* plugins to add classes and register them with the factories and registries.
|
|
|
|
*
|
|
|
|
* The parameter to this function can be a ResourceLoader module name or a function.
|
|
|
|
*
|
|
|
|
* If it's a module name, it will be loaded together with the VisualEditor core modules when
|
|
|
|
* VE is loaded. No special care is taken to ensure that the module runs after the VE
|
|
|
|
* classes are loaded, so if this is desired, the module should depend on
|
|
|
|
* ext.visualEditor.core .
|
|
|
|
*
|
|
|
|
* If it's a function, it will be invoked once the VisualEditor core modules and any
|
|
|
|
* plugin modules registered through this function have been loaded, but before the editor
|
|
|
|
* is intialized. The function takes one parameter, which is the ve.init.mw.Target instance
|
|
|
|
* that's initializing, and can optionally return a jQuery.Promise . VisualEditor will
|
|
|
|
* only be initialized once all promises returned by plugin functions have been resolved.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* // Register ResourceLoader module
|
|
|
|
* ve.libs.mw.addPlugin( 'ext.gadget.foobar' );
|
|
|
|
*
|
|
|
|
* // Register a callback
|
|
|
|
* ve.libs.mw.addPlugin( function ( target ) {
|
|
|
|
* ve.dm.Foobar = .....
|
|
|
|
* } );
|
|
|
|
*
|
|
|
|
* // Register a callback that loads another script
|
|
|
|
* ve.libs.mw.addPlugin( function () {
|
|
|
|
* return $.getScript( 'http://example.com/foobar.js' );
|
|
|
|
* } );
|
|
|
|
*
|
|
|
|
* @param {string|Function} plugin Module name or callback that optionally returns a promise
|
|
|
|
*/
|
2013-12-06 02:34:44 +00:00
|
|
|
addPlugin: function ( plugin ) {
|
Infrastructure for loading plugins in the MW integration
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.
When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.
This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.
User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.
If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );
For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)
VisualEditor.php:
* Add $wgVisualEditorPluginModules
VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS
ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
values in an array and passes them into the mw.Target when it's
being initialized
ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
to load this.modules plus user and site, and fire onModulesReady()
when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
returned promises, wait for all of them to be resolved, then resolve
this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
using a second using() call
Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
2013-07-22 20:34:28 +00:00
|
|
|
plugins.push( plugin );
|
|
|
|
},
|
|
|
|
|
2013-08-02 20:25:44 +00:00
|
|
|
setupSkin: function () {
|
|
|
|
init.setupTabs();
|
|
|
|
init.setupSectionLinks();
|
2013-07-05 06:01:31 +00:00
|
|
|
},
|
|
|
|
|
2013-08-02 20:25:44 +00:00
|
|
|
setupTabs: function () {
|
2014-04-10 18:57:17 +00:00
|
|
|
// HACK: Remove this when the Education Program offers a proper way to detect and disable.
|
|
|
|
if (
|
|
|
|
mw.config.get( 'wgNamespaceIds' ).hasOwnProperty( 'education_program' ) &&
|
|
|
|
/*jshint -W069*/
|
|
|
|
mw.config.get( 'wgNamespaceIds' )['education_program'] === mw.config.get( 'wgNamespaceNumber' )
|
|
|
|
) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-08-01 19:14:41 +00:00
|
|
|
var caVeEdit,
|
2013-07-03 22:14:52 +00:00
|
|
|
action = pageExists ? 'edit' : 'create',
|
|
|
|
pTabsId = $( '#p-views' ).length ? 'p-views' : 'p-cactions',
|
|
|
|
$caSource = $( '#ca-viewsource' ),
|
|
|
|
$caEdit = $( '#ca-edit' ),
|
2013-08-01 19:14:41 +00:00
|
|
|
$caVeEdit = $( '#ca-ve-edit' ),
|
2013-07-03 22:14:52 +00:00
|
|
|
$caEditLink = $caEdit.find( 'a' ),
|
2013-08-01 19:14:41 +00:00
|
|
|
$caVeEditLink = $caVeEdit.find( 'a' ),
|
2013-07-03 22:14:52 +00:00
|
|
|
reverseTabOrder = $( 'body' ).hasClass( 'rtl' ) && pTabsId === 'p-views',
|
2013-08-01 19:14:41 +00:00
|
|
|
/*jshint bitwise:false */
|
2013-08-02 20:25:44 +00:00
|
|
|
caVeEditNextnode = ( reverseTabOrder ^ conf.tabPosition === 'before' ) ? $caEdit.get( 0 ) : $caEdit.next().get( 0 );
|
2013-08-01 19:14:41 +00:00
|
|
|
|
|
|
|
if ( !$caVeEdit.length ) {
|
|
|
|
// The below duplicates the functionality of VisualEditorHooks::onSkinTemplateNavigation()
|
|
|
|
// in case we're running on a cached page that doesn't have these tabs yet.
|
2013-07-03 22:14:52 +00:00
|
|
|
|
|
|
|
// If there is no edit tab or a view-source tab,
|
|
|
|
// the user doesn't have permission to edit.
|
2013-08-01 19:14:41 +00:00
|
|
|
if ( $caEdit.length && !$caSource.length ) {
|
|
|
|
// Add the VisualEditor tab (#ca-ve-edit)
|
|
|
|
caVeEdit = mw.util.addPortletLink(
|
|
|
|
pTabsId,
|
|
|
|
// Use url instead of '#'.
|
|
|
|
// So that 1) one can always open it in a new tab, even when
|
|
|
|
// onEditTabClick is bound.
|
|
|
|
// 2) when onEditTabClick is not bound (!isViewPage) it will
|
|
|
|
// just work.
|
|
|
|
veEditUri,
|
|
|
|
tabMessages[action] !== null ? mw.msg( tabMessages[action] ) : $caEditLink.text(),
|
|
|
|
'ca-ve-edit',
|
|
|
|
mw.msg( 'tooltip-ca-ve-edit' ),
|
|
|
|
mw.msg( 'accesskey-ca-ve-edit' ),
|
|
|
|
caVeEditNextnode
|
|
|
|
);
|
|
|
|
|
|
|
|
$caVeEdit = $( caVeEdit );
|
|
|
|
$caVeEditLink = $caVeEdit.find( 'a' );
|
|
|
|
}
|
2014-03-18 05:25:08 +00:00
|
|
|
} else if ( $caEdit.length && $caVeEdit.length ) {
|
2013-08-01 19:14:41 +00:00
|
|
|
// Make the state of the page consistent with the config if needed
|
|
|
|
/*jshint bitwise:false */
|
|
|
|
if ( reverseTabOrder ^ conf.tabPosition === 'before' ) {
|
|
|
|
if ( $caEdit[0].nextSibling === $caVeEdit[0] ) {
|
|
|
|
$caVeEdit.after( $caEdit );
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if ( $caVeEdit[0].nextSibling === $caEdit[0] ) {
|
|
|
|
$caEdit.after( $caVeEdit );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if ( tabMessages[action] !== null ) {
|
|
|
|
$caVeEditLink.text( mw.msg( tabMessages[action] ) );
|
|
|
|
}
|
2013-07-03 22:14:52 +00:00
|
|
|
}
|
|
|
|
|
2013-08-01 19:14:41 +00:00
|
|
|
// Alter the edit tab (#ca-edit)
|
2014-04-08 23:07:33 +00:00
|
|
|
if ( $( '#ca-view-foreign' ).length ) {
|
|
|
|
if ( tabMessages[action + 'localdescriptionsource'] !== null ) {
|
|
|
|
$caEditLink.text( mw.msg( tabMessages[action + 'localdescriptionsource'] ) );
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if ( tabMessages[action + 'source'] !== null ) {
|
|
|
|
$caEditLink.text( mw.msg( tabMessages[action + 'source'] ) );
|
|
|
|
}
|
2013-08-01 19:14:41 +00:00
|
|
|
}
|
2014-04-03 01:14:54 +00:00
|
|
|
|
|
|
|
if ( conf.tabPosition === 'before' ) {
|
|
|
|
$caEdit.addClass( 'collapsible' );
|
|
|
|
} else {
|
|
|
|
$caVeEdit.addClass( 'collapsible' );
|
|
|
|
}
|
|
|
|
|
2013-08-01 19:14:41 +00:00
|
|
|
// Process appendix messages
|
|
|
|
if ( tabMessages[action + 'appendix'] !== null ) {
|
|
|
|
$caVeEditLink.append(
|
|
|
|
$( '<span>' )
|
|
|
|
.addClass( 've-tabmessage-appendix' )
|
|
|
|
.text( mw.msg( tabMessages[action + 'appendix'] ) )
|
2013-07-03 22:14:52 +00:00
|
|
|
);
|
2013-08-01 19:14:41 +00:00
|
|
|
}
|
|
|
|
if ( tabMessages[action + 'sourceappendix'] !== null ) {
|
|
|
|
$caEditLink.append(
|
|
|
|
$( '<span>' )
|
|
|
|
.addClass( 've-tabmessage-appendix' )
|
|
|
|
.text( mw.msg( tabMessages[action + 'sourceappendix'] ) )
|
2013-07-03 22:14:52 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ( isViewPage ) {
|
|
|
|
// Allow instant switching to edit mode, without refresh
|
2013-08-01 19:14:41 +00:00
|
|
|
$caVeEdit.click( init.onEditTabClick );
|
2013-07-05 06:01:31 +00:00
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2013-08-02 20:25:44 +00:00
|
|
|
setupSectionLinks: function () {
|
|
|
|
var $editsections = $( '#mw-content-text .mw-editsection' );
|
2013-07-05 06:01:31 +00:00
|
|
|
|
|
|
|
// match direction to the user interface
|
|
|
|
$editsections.css( 'direction', $( 'body' ).css( 'direction' ) );
|
|
|
|
// The "visibility" css construct ensures we always occupy the same space in the layout.
|
|
|
|
// This prevents the heading from changing its wrap when the user toggles editSourceLink.
|
2013-08-01 19:14:41 +00:00
|
|
|
if ( $editsections.find( '.mw-editsection-visualeditor' ).length === 0 ) {
|
|
|
|
// If PHP didn't build the section edit links (because of caching), build them
|
|
|
|
$editsections.each( function () {
|
|
|
|
var $editsection = $( this ),
|
|
|
|
$editSourceLink = $editsection.find( 'a' ).eq( 0 ),
|
|
|
|
$editLink = $editSourceLink.clone(),
|
|
|
|
$divider = $( '<span>' ),
|
|
|
|
dividerText = mw.msg( 'pipe-separator' );
|
|
|
|
|
|
|
|
if ( tabMessages.editsectionsource !== null ) {
|
|
|
|
$editSourceLink.text( mw.msg( tabMessages.editsectionsource ) );
|
2013-07-03 22:14:52 +00:00
|
|
|
}
|
2013-08-01 19:14:41 +00:00
|
|
|
if ( tabMessages.editsection !== null ) {
|
|
|
|
$editLink.text( mw.msg( tabMessages.editsection ) );
|
|
|
|
}
|
|
|
|
$divider
|
|
|
|
.addClass( 'mw-editsection-divider' )
|
|
|
|
.text( dividerText );
|
2014-04-28 15:07:03 +00:00
|
|
|
// Don't mess with section edit links on foreign file description pages
|
|
|
|
// (bug 54259)
|
|
|
|
if ( !$( '#ca-view-foreign' ).length ) {
|
|
|
|
$editLink
|
|
|
|
.attr( 'href', function ( i, val ) {
|
|
|
|
return new mw.Uri( veEditUri ).extend( {
|
|
|
|
'vesection': new mw.Uri( val ).query.section
|
|
|
|
} );
|
|
|
|
} )
|
|
|
|
.addClass( 'mw-editsection-visualeditor' );
|
|
|
|
if ( conf.tabPosition === 'before' ) {
|
|
|
|
$editSourceLink.before( $editLink, $divider );
|
|
|
|
} else {
|
|
|
|
$editSourceLink.after( $divider, $editLink );
|
|
|
|
}
|
2013-08-01 19:14:41 +00:00
|
|
|
}
|
|
|
|
} );
|
|
|
|
}
|
2013-07-05 06:01:31 +00:00
|
|
|
|
2013-08-01 19:14:41 +00:00
|
|
|
// Process appendix messages
|
|
|
|
if ( tabMessages.editsectionappendix ) {
|
|
|
|
$editsections.find( '.mw-editsection-visualeditor' )
|
|
|
|
.append(
|
|
|
|
$( '<span>' )
|
|
|
|
.addClass( 've-tabmessage-appendix' )
|
|
|
|
.text( mw.msg( tabMessages.editsectionappendix ) )
|
|
|
|
);
|
|
|
|
}
|
|
|
|
if ( tabMessages.editsectionsourceappendix ) {
|
|
|
|
$editsections.find( 'a:not(.mw-editsection-visualeditor)' )
|
|
|
|
.append(
|
|
|
|
$( '<span>' )
|
|
|
|
.addClass( 've-tabmessage-appendix' )
|
|
|
|
.text( mw.msg( tabMessages.editsectionsourceappendix ) )
|
|
|
|
);
|
|
|
|
}
|
2013-07-05 06:01:31 +00:00
|
|
|
|
2013-08-01 19:14:41 +00:00
|
|
|
if ( isViewPage ) {
|
|
|
|
// Only init without refresh if we're on a view page. Though section edit links
|
|
|
|
// are rarely shown on non-view pages, they appear in one other case, namely
|
|
|
|
// when on a diff against the latest version of a page. In that case we mustn't
|
|
|
|
// init without refresh as that'd initialise for the wrong rev id (bug 50925)
|
|
|
|
// and would preserve the wrong DOM with a diff on top.
|
|
|
|
$editsections
|
|
|
|
.addClass( 'mw-editsection-expanded' )
|
|
|
|
.find( '.mw-editsection-visualeditor' )
|
|
|
|
.click( init.onEditSectionLinkClick )
|
|
|
|
;
|
|
|
|
}
|
2013-07-05 06:01:31 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
onEditTabClick: function ( e ) {
|
|
|
|
// Default mouse button is normalised by jQuery to key code 1.
|
|
|
|
// Only do our handling if no keys are pressed, mouse button is 1
|
|
|
|
// (e.g. not middle click or right click) and no modifier keys
|
|
|
|
// (e.g. cmd-click to open in new tab).
|
|
|
|
if ( ( e.which && e.which !== 1 ) || e.shiftKey || e.altKey || e.ctrlKey || e.metaKey ) {
|
|
|
|
return;
|
2013-07-03 22:14:52 +00:00
|
|
|
}
|
2013-07-05 06:01:31 +00:00
|
|
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
|
|
|
getTarget().done( function ( target ) {
|
2013-08-02 23:40:52 +00:00
|
|
|
ve.track( 'Edit', { action: 'edit-link-click' } );
|
2013-07-05 06:01:31 +00:00
|
|
|
target.activate();
|
|
|
|
} );
|
|
|
|
},
|
|
|
|
|
|
|
|
onEditSectionLinkClick: function ( e ) {
|
|
|
|
if ( ( e.which && e.which !== 1 ) || e.shiftKey || e.altKey || e.ctrlKey || e.metaKey ) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
e.preventDefault();
|
|
|
|
|
|
|
|
getTarget().done( function ( target ) {
|
2013-08-02 23:40:52 +00:00
|
|
|
ve.track( 'Edit', { action: 'section-edit-link-click' } );
|
2013-07-05 06:01:31 +00:00
|
|
|
target.saveEditSection( $( e.target ).closest( 'h1, h2, h3, h4, h5, h6' ).get( 0 ) );
|
|
|
|
target.activate();
|
|
|
|
} );
|
2013-07-03 22:14:52 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-07-19 01:56:25 +00:00
|
|
|
support.visualEditor = support.es5 &&
|
|
|
|
support.contentEditable &&
|
|
|
|
( ( 'vewhitelist' in uri.query ) || !$.client.test( init.blacklist, null, true ) );
|
|
|
|
|
2013-09-30 16:18:46 +00:00
|
|
|
enable = mw.user.options.get( 'visualeditor-enable', conf.defaultUserOptions.enable );
|
|
|
|
|
2013-08-02 20:25:44 +00:00
|
|
|
userPrefEnabled = (
|
2013-07-19 02:44:22 +00:00
|
|
|
// Allow disabling for anonymous users separately from changing the
|
|
|
|
// default preference (bug 50000)
|
2013-08-01 01:43:16 +00:00
|
|
|
!( conf.disableForAnons && mw.config.get( 'wgUserName' ) === null ) &&
|
2013-07-19 02:44:22 +00:00
|
|
|
|
2013-07-24 01:11:56 +00:00
|
|
|
// User has 'visualeditor-enable' preference enabled (for alpha opt-in)
|
|
|
|
// User has 'visualeditor-betatempdisable' preference disabled
|
2013-07-26 20:20:10 +00:00
|
|
|
// Because user.options is embedded in the HTML and cached per-page for anons on wikis
|
|
|
|
// with static caching (e.g. wgUseFileCache or reverse-proxy) ignore user.options for
|
|
|
|
// anons as it is likely outdated.
|
|
|
|
(
|
2013-08-01 01:43:16 +00:00
|
|
|
mw.config.get( 'wgUserName' ) === null ?
|
2013-07-26 20:20:10 +00:00
|
|
|
( conf.defaultUserOptions.enable && !conf.defaultUserOptions.betatempdisable ) :
|
|
|
|
(
|
2013-09-30 16:18:46 +00:00
|
|
|
enable && enable !== '0' &&
|
2013-07-26 20:20:10 +00:00
|
|
|
!mw.user.options.get(
|
|
|
|
'visualeditor-betatempdisable',
|
|
|
|
conf.defaultUserOptions.betatempdisable
|
|
|
|
)
|
|
|
|
)
|
2013-08-02 20:25:44 +00:00
|
|
|
)
|
|
|
|
);
|
|
|
|
|
|
|
|
// Whether VisualEditor should be available for the current user, page, wiki, mediawiki skin,
|
|
|
|
// browser etc.
|
|
|
|
init.isAvailable = (
|
|
|
|
support.visualEditor &&
|
|
|
|
|
2013-07-19 02:44:22 +00:00
|
|
|
// Only in supported skins
|
2013-07-24 01:11:56 +00:00
|
|
|
$.inArray( mw.config.get( 'skin' ), conf.skins ) !== -1 &&
|
2013-07-19 02:44:22 +00:00
|
|
|
|
|
|
|
// Only in enabled namespaces
|
|
|
|
$.inArray(
|
|
|
|
new mw.Title( mw.config.get( 'wgRelevantPageName' ) ).getNamespaceId(),
|
|
|
|
conf.namespaces
|
|
|
|
) !== -1 &&
|
|
|
|
|
2014-03-19 00:26:54 +00:00
|
|
|
// Not on pages which are outputs of the Page Translation feature
|
|
|
|
mw.config.get( 'wgTranslatePageTranslation' ) !== 'translation' &&
|
|
|
|
|
2013-07-19 02:44:22 +00:00
|
|
|
// Only for pages with a wikitext content model
|
|
|
|
mw.config.get( 'wgPageContentModel' ) === 'wikitext'
|
|
|
|
);
|
|
|
|
|
2013-07-10 13:55:17 +00:00
|
|
|
// Note: Though VisualEditor itself only needs this exposure for a very small reason
|
|
|
|
// (namely to access init.blacklist from the unit tests...) this has become one of the nicest
|
2013-08-03 04:33:03 +00:00
|
|
|
// ways to easily detect whether the VisualEditor initialisation code is present.
|
|
|
|
//
|
|
|
|
// The VE global was once available always, but now that platform integration initialisation
|
|
|
|
// is properly separated, it doesn't exist until the platform loads VisualEditor core.
|
|
|
|
//
|
|
|
|
// Most of mw.libs.ve is considered subject to change and private. The exception is that
|
|
|
|
// mw.libs.ve.isAvailable is public, and indicates whether the VE editor itself can be loaded
|
|
|
|
// on this page. See above for why it may be false.
|
2013-07-03 22:14:52 +00:00
|
|
|
mw.libs.ve = init;
|
|
|
|
|
2013-11-26 09:46:42 +00:00
|
|
|
if ( init.isAvailable && userPrefEnabled ) {
|
2013-09-04 17:57:29 +00:00
|
|
|
$( 'html' ).addClass( 've-available' );
|
|
|
|
} else {
|
2013-08-01 19:14:41 +00:00
|
|
|
$( 'html' ).addClass( 've-not-available' );
|
2013-09-04 17:57:29 +00:00
|
|
|
// Don't return here because we do want the skin setup to consistently happen
|
|
|
|
// for e.g. "Edit" > "Edit source" even when VE is not available.
|
2013-08-02 20:25:44 +00:00
|
|
|
}
|
|
|
|
|
2013-07-03 22:14:52 +00:00
|
|
|
$( function () {
|
2013-11-26 09:46:42 +00:00
|
|
|
if ( init.isAvailable ) {
|
|
|
|
if ( isViewPage && uri.query.veaction === 'edit' ) {
|
2013-07-03 22:14:52 +00:00
|
|
|
getTarget().done( function ( target ) {
|
|
|
|
target.activate();
|
|
|
|
} );
|
|
|
|
}
|
|
|
|
}
|
2013-11-26 09:46:42 +00:00
|
|
|
|
|
|
|
if ( userPrefEnabled ) {
|
|
|
|
init.setupSkin();
|
|
|
|
}
|
2013-07-03 22:14:52 +00:00
|
|
|
} );
|
|
|
|
}() );
|