mediawiki-extensions-Visual.../modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js

566 lines
19 KiB
JavaScript
Raw Normal View History

/*!
* 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.
*
* @copyright 2011-2015 VisualEditor Team and others; see AUTHORS.txt
* @license The MIT License (MIT); see LICENSE.txt
*/
/**
* Platform preparation for the MediaWiki view page. This loads (when user needs it) the
* actual MediaWiki integration and VisualEditor library.
*
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
* @class mw.libs.ve
* @alternateClassName ve.init.mw.ViewPageTarget.init
* @singleton
*/
( function () {
var conf, tabMessages, uri, pageExists, viewUri, veEditUri, isViewPage,
init, support, targetPromise, enable, tempdisable, 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 = [];
function showLoading() {
if ( !init.$loading ) {
init.$loading = $(
'<div class="ve-init-mw-viewPageTarget-loading-overlay">' +
'<div class="ve-init-mw-viewPageTarget-progress">' +
'<div class="ve-init-mw-viewPageTarget-progress-bar"></div>' +
'</div>' +
'</div>'
);
}
var $content = $( '#content' ),
contentRect = $content[0].getBoundingClientRect(),
offsetTop = $content.offset().top,
windowHeight = $( window ).height(),
top = Math.max( contentRect.top, 0 ),
bottom = Math.min( contentRect.bottom, windowHeight ),
middle = ( top + bottom ) / 2;
init.$loading.css( 'top', middle - offsetTop );
$content.prepend( init.$loading );
}
function setLoadingProgress( target, duration ) {
var $bar = init.$loading.find( '.ve-init-mw-viewPageTarget-progress-bar' ).stop();
if ( duration ) {
$bar.animate( { width: target + '%' }, duration );
} else {
$bar.css( 'width', target + '%' );
}
}
function hideLoading() {
if ( init.$loading ) {
init.$loading.detach();
}
}
/**
* Use deferreds to avoid loading and instantiating Target multiple times.
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
* @private
* @return {jQuery.Promise}
*/
function getTarget() {
if ( !targetPromise ) {
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
// The TargetLoader module is loaded in the bottom queue, so it should have been
// requested already but it might not have finished loading yet
targetPromise = mw.loader.using( 'ext.visualEditor.targetLoader' )
.then( function () {
// Add modules specific to desktop (modules shared between desktop
// and mobile are already added by TargetLoader)
// Note: it's safe to use .forEach() (ES5) here, because this code will
// never be called if the browser doesn't support ES5
[
'ext.visualEditor.viewPageTarget',
'ext.visualEditor.mwformatting',
'ext.visualEditor.mwgallery',
'ext.visualEditor.mwimage',
'ext.visualEditor.mwmeta'
].forEach( mw.libs.ve.targetLoader.addPlugin );
// Add requested plugins
plugins.forEach( mw.libs.ve.targetLoader.addPlugin );
plugins = [];
return mw.libs.ve.targetLoader.loadModules();
} )
.then( function () {
// Transfer methods
ve.init.mw.ViewPageTarget.prototype.setupSectionEditLinks = init.setupSectionLinks;
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
var target = new ve.init.mw.ViewPageTarget();
$( '#content' ).append( target.$element );
return target;
}, function ( e ) {
mw.log.warn( 'VisualEditor failed to load: ' + e );
} );
}
return targetPromise;
}
/**
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
* Load and activate the target.
*
* If you need to call methods on the target before activate is called, call getTarget()
* yourself, chain your work onto that promise, and pass that chained promise in as targetPromise.
* E.g. `activateTarget( getTarget().then( function( target ) { target.doAThing(); } ) );`
*
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
* @private
* @param {jQuery.Promise} [targetPromise] Promise that will be resolved with a ve.init.mw.Target
*/
function activateTarget( targetPromise ) {
// The TargetLoader module is loaded in the bottom queue, so it should have been
// requested already but it might not have finished loading yet
var dataPromise = mw.loader.using( 'ext.visualEditor.targetLoader' )
.then( function () {
return mw.libs.ve.targetLoader.requestPageData(
mw.config.get( 'wgRelevantPageName' ),
uri.query.oldid
);
} );
$( 'html' ).addClass( 've-activated ve-loading' );
showLoading();
setLoadingProgress( 70, 3000 );
targetPromise = targetPromise || getTarget();
targetPromise
.then( function ( target ) {
setLoadingProgress( 100, 1000 );
return target.activate( dataPromise );
} )
.then( function () {
setLoadingProgress( 0 );
ve.track( 'mwedit.ready' );
} )
.always( hideLoading );
}
conf = mw.config.get( 'wgVisualEditorConfig' );
tabMessages = conf.tabMessages;
uri = new mw.Uri();
pageExists = !!mw.config.get( 'wgRelevantArticleId' );
viewUri = new mw.Uri( mw.util.getUrl( mw.config.get( 'wgRelevantPageName' ) ) );
isViewPage = (
mw.config.get( 'wgIsArticle' ) &&
!( 'diff' in uri.query )
);
// On a view page, extend the current URI so parameters like oldid are carried over
// On a non-view page, use viewUri
veEditUri = ( isViewPage ? uri : viewUri ).clone().extend( { veaction: 'edit' } );
support = {
es5: !!(
// 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 &&
Date.now &&
Date.prototype.toJSON &&
Object.create &&
Object.keys &&
String.prototype.trim &&
window.JSON &&
JSON.parse &&
JSON.stringify &&
Function.prototype.bind
),
contentEditable: 'contentEditable' in document.createElement( 'div' ),
svg: !!(
document.createElementNS &&
document.createElementNS( 'http://www.w3.org/2000/svg', 'svg' ).createSVGRect
)
};
init = {
support: support,
blacklist: conf.blacklist,
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
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
* is intialized. The function can optionally return a jQuery.Promise . VisualEditor will
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
* only be initialized once all promises returned by plugin functions have been resolved.
*
* // Register ResourceLoader module
* mw.libs.ve.addPlugin( 'ext.gadget.foobar' );
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
*
* // Register a callback
* mw.libs.ve.addPlugin( function ( target ) {
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
* ve.dm.Foobar = .....
* } );
*
* // Register a callback that loads another script
* mw.libs.ve.addPlugin( function () {
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
* return $.getScript( 'http://example.com/foobar.js' );
* } );
*
* @param {string|Function} plugin Module name or callback that optionally returns a promise
*/
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 );
},
setupSkin: function () {
init.setupTabs();
init.setupSectionLinks();
},
setupTabs: function () {
// HACK: Remove this when the Education Program offers a proper way to detect and disable.
if (
// HACK: Work around jscs.requireCamelCaseOrUpperCaseIdentifiers
mw.config.get( 'wgNamespaceIds' )[ true && 'education_program' ] === mw.config.get( 'wgNamespaceNumber' )
) {
return;
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
var caVeEdit,
action = pageExists ? 'edit' : 'create',
pTabsId = $( '#p-views' ).length ? 'p-views' : 'p-cactions',
$caSource = $( '#ca-viewsource' ),
$caEdit = $( '#ca-edit' ),
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
$caVeEdit = $( '#ca-ve-edit' ),
$caEditLink = $caEdit.find( 'a' ),
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
$caVeEditLink = $caVeEdit.find( 'a' ),
reverseTabOrder = $( 'body' ).hasClass( 'rtl' ) && pTabsId === 'p-views',
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
/*jshint bitwise:false */
caVeEditNextnode = ( reverseTabOrder ^ conf.tabPosition === 'before' ) ? $caEdit.get( 0 ) : $caEdit.next().get( 0 );
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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.
// If there is no edit tab or a view-source tab,
// the user doesn't have permission to edit.
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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' );
}
} else if ( $caEdit.length && $caVeEdit.length ) {
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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] ) );
}
}
// If the edit tab is hidden, remove it.
if ( !( init.isAvailable && userPrefEnabled ) ) {
$caVeEdit.remove();
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
// Alter the edit tab (#ca-edit)
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'] ) );
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
}
if ( conf.tabPosition === 'before' ) {
$caEdit.addClass( 'collapsible' );
} else {
$caVeEdit.addClass( 'collapsible' );
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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'] ) )
);
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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'] ) )
);
}
if ( isViewPage ) {
// Allow instant switching to edit mode, without refresh
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
$caVeEdit.click( init.onEditTabClick );
}
},
setupSectionLinks: function () {
mw.ViewPageTarget: Get rid of FOUC on edit section brackets We don't have a FOUC on the appearing of the 'edit' link. That one is handled quite intelligently: * Via the stylesheet that is also loaded in noscript mode, its (hidden) appearance is already predetermined. So as soon as those elements are seen by the browser they style correctly for users without JavaScript (display: none). * This same stylesheet also hides it for users with JavaScript but where VE is not available (e.g. due to browser support). While ve-not-available is added very early on (before document ready), it could in theory cause a short FOUC, but that's okay. We simply don't know that VE isn't supported until then. We optimise for the common case (JavaScript enabled, VE available), while still ensuring that it is always hidden in noscript, and is hidden as soon as possible when VE turns out not to be available. For some reason, one small detail (the little bit of whitespace added inside the brackets), was left out of this and was implemented by adding the class 'mw-editsection-expanded' to them from a document ready handler. * First step, get rid of the script that adds this class and use ve-available instead. That means they're styled correctly much earlier (we add the class to <html> before document ready). This can still cause a brief FOUC, though in most cases they're correct from the start. * Step two, make brackets expand by default for script users, and let ve-not-available reset it. This way, like with edit tabs, a FOUC will never happen for ve-available. And even for ve-not-available, a FOUC is rare since we add it before document ready via <html> look-ahead styling. There was still a brief reflow jump because of negative margins between two paint events. One was undoing the other at a later time. These negative margins are a remnant of when we were doing animations (follows-up I4b9c47fd65a70). They were added to reduce reflows and content shift, but were now actually causing them. Removed "padding-right" from mw-editsection, and negative margin from the brackets. Also: * Don't add inline 'style="direction: ltr;"' on every single editsection throughout the DOM. This was the only operation we were doing unconditionally. While I doubt the need of it in general, we can at least allow MediaWiki to do it right, and only add the override if needed. This saves quite a few DOM operations. Change-Id: I7a729edc2cd4a66ebc0ad6935ffd02cb9b948bff
2014-05-07 00:08:53 +00:00
var $editsections = $( '#mw-content-text .mw-editsection' ),
bodyDir = $( 'body' ).css( 'direction' );
// Match direction of the user interface
// TODO: Why is this needed? It seems to work fine without.
if ( $editsections.css( 'direction' ) !== bodyDir ) {
// Avoid creating inline style attributes if the inherited value is already correct
$editsections.css( 'direction', bodyDir );
}
// 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.
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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 ) );
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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 );
// 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 );
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
}
} );
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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 ) )
);
}
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
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
.find( '.mw-editsection-visualeditor' )
.click( init.onEditSectionLinkClick )
;
}
},
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;
}
ve.track( 'trace.activate.enter' );
ve.track( 'mwedit.init', { type: 'page', mechanism: 'click' } );
if ( history.pushState && uri.query.veaction !== 'edit' ) {
// Replace the current state with one that is tagged as ours, to prevent the
// back button from breaking when used to exit VE. FIXME: there should be a better
// way to do this. See also similar code in the ViewPageTarget constructor.
history.replaceState( { tag: 'visualeditor' }, document.title, uri );
// Set veaction to edit
history.pushState( { tag: 'visualeditor' }, document.title, veEditUri );
// Update mw.Uri instance
uri = veEditUri;
}
e.preventDefault();
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
activateTarget();
},
onEditSectionLinkClick: function ( e ) {
var targetPromise;
if ( ( e.which && e.which !== 1 ) || e.shiftKey || e.altKey || e.ctrlKey || e.metaKey ) {
return;
}
ve.track( 'trace.activate.enter' );
ve.track( 'mwedit.init', { type: 'section', mechanism: 'click' } );
if ( history.pushState && uri.query.veaction !== 'edit' ) {
// Replace the current state with one that is tagged as ours, to prevent the
// back button from breaking when used to exit VE. FIXME: there should be a better
// way to do this. See also similar code in the ViewPageTarget constructor.
history.replaceState( { tag: 'visualeditor' }, document.title, uri );
// Change the state to the href of the section link that was clicked. This saves
// us from having to figure out the section number again.
history.pushState( { tag: 'visualeditor' }, document.title, this.href );
}
e.preventDefault();
targetPromise = getTarget().then( function ( target ) {
target.saveEditSection( $( e.target ).closest( 'h1, h2, h3, h4, h5, h6' ).get( 0 ) );
return target;
} );
activateTarget( targetPromise );
}
};
support.visualEditor = support.es5 &&
support.contentEditable &&
support.svg &&
( ( 'vewhitelist' in uri.query ) || !$.client.test( init.blacklist, null, true ) );
// Cast "0" (T89513)
enable = Number( mw.user.options.get( 'visualeditor-enable' ) );
tempdisable = Number( mw.user.options.get( 'visualeditor-betatempdisable' ) );
userPrefEnabled = (
// Allow disabling for anonymous users separately from changing the
// default preference (bug 50000)
!( conf.disableForAnons && mw.config.get( 'wgUserName' ) === null ) &&
// User has 'visualeditor-enable' preference enabled (for alpha opt-in)
// User has 'visualeditor-betatempdisable' preference disabled
enable && !tempdisable
);
// Whether VisualEditor should be available for the current user, page, wiki, mediawiki skin,
// browser etc.
init.isAvailable = (
support.visualEditor &&
// Only in supported skins
$.inArray( mw.config.get( 'skin' ), conf.skins ) !== -1 &&
// Only in enabled namespaces
$.inArray(
new mw.Title( mw.config.get( 'wgRelevantPageName' ) ).getNamespaceId(),
conf.namespaces
) !== -1 &&
// Not on pages which are outputs of the Page Translation feature
mw.config.get( 'wgTranslatePageTranslation' ) !== 'translation' &&
// Only for pages with a wikitext content model
mw.config.get( 'wgPageContentModel' ) === 'wikitext'
);
// 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
// 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.
mw.libs.ve = init;
if ( init.isAvailable && userPrefEnabled ) {
$( 'html' ).addClass( 've-available' );
} else {
Move edit tab generation into PHP and make it more configurable * Generate the edit tabs and the section edit links in PHP, with a fallback in JS for cases where we don't have them yet due to caching. But only change things if VE is enabled, and have the JS correct the state if the wrong cached HTML comes through. * Make the order of the tabs/links and the messages to use as captions configurable * Make the edit tabs and section edit links always be present in the page (regardless of namespace, user prefs, etc.) but be hidden and have JS unhide them (using html.ve-available) if appropriate * Add appendix messages so we can do a superscript "beta" even in places where we can't use HTML in the message VisualEditor.php: * Add new hook registrations * Remove edit link caption messages from the init init module because they're now added dynamically in VisualEditor.hooks.php * Add a noscript CSS module so we can hide some things in JS-less environments * Remove $wgVisualEditorTabLayout and replace it with $wgVisualEditorPosition * Add config vars for link captions, with null causing us to use the default caption * Add config vars for link caption appendices. Too many config vars but we'll clean that up later VisualEditor.hooks.php: * Dynamically add tab messages to the init init module * Remove unused globals in onBeforePageDisplay() * Add noscript CSS module * Add a SkinTemplateNavigation hook that changes and reorders the edit tabs as appropriate * Add a DoEditSectionLink hook that overwrites the edit section links * Export the new config variables to JS VisualEditor.i18n.php: * Add beta appendix message * Add a message for the default VE edit section link ve.init.mw.ViewPageTarget.init.css: * Remove the animation on the edit section links * Darken the color of the brackets and the pipe from #ccc to #555 * Style the beta message to be superscript-like (but not real <sup> to avoid moving the baseline) ve.init.mw.ViewPageTarget.noscript.css: * Hide the VE edit tab, the pipe and the VE edit section link initally unless and until JS unhides ve.init.mw.ViewPageTarget.init.js: * Toggle .ve-not-available / .ve-available * Edit tabs ** Only generate the the edit tabs if they're not already there from PHP ** Rewrite the edit tab generation to mirror what's being done in PHP * Section edit links ** Same as for edit tabs ** Also add mw-visualeditor-expanded to pad the brackets ve.init.mw.ViewPageTarget.js: * #ca-ve-edit is now always the VE tab (and #ca-edit always the edit source tab) so update the .selected behavior accordingly Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
2013-08-01 19:14:41 +00:00
$( 'html' ).addClass( 've-not-available' );
// 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.
}
$( function () {
var currentUri = new mw.Uri( location.href ),
isSection;
if ( init.isAvailable ) {
if ( isViewPage && uri.query.veaction === 'edit' ) {
isSection = uri.query.vesection !== undefined;
ve.track( 'trace.activate.enter' );
ve.track( 'mwedit.init', { type: isSection ? 'section' : 'page', mechanism: 'url' } );
Load RL modules in one load.php request, rather than in two stages This introduces TargetLoader, which manages plugins and RL modules in a slightly more generic fashion so that Targets themselves don't have to. This allows us to load all RL modules in one load.php request, rather than first loading ViewPageTarget which then loads the other modules. TargetLoader loads in the bottom queue, so it will be loaded as part of the main load.php request, but in VPT.init.js we still have to wait for it with using() because it might not have arrived yet. This also degrades gracefully on cached pages where TargetLoader isn't in the bottom queue: it'll be loaded as a separate request instead, which is suboptimal but no worse that what we were doing before. Right now TargetLoader is small enough that it could also be in the top queue, but in the future we want to add things like the action=visualeditor API request to it, and mw.Api is relatively big. Note: this also makes a breaking change to the plugin API: plugin callbacks no longer receive the target instance as a parameter, as they're now executed before the target has been constructed rather than after. In the long term, if we want to give plugins access to the target instance, we could give them the target promise somehow. For now, I've killed this feature because nothing used it and the change from a direct object reference to a promise would have been a breaking change anyway. Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init. Bug: T53569 Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-02-26 01:22:44 +00:00
activateTarget();
}
}
if ( userPrefEnabled ) {
init.setupSkin();
}
if ( currentUri.query.venotify ) {
// The following messages can be used here:
// postedit-confirmation-saved
// postedit-confirmation-created
// postedit-confirmation-restored
mw.hook( 'postEdit' ).fire( {
message: mw.msg( 'postedit-confirmation-' + currentUri.query.venotify, mw.user )
} );
delete currentUri.query.venotify;
}
} );
}() );