MediaWiki talk:Gadget-oldeditor.js

Save ressources on loading

May I suggest to prepend the following statements:

mw.loader.state( "ext.visualEditor", "missing" );
mw.loader.state( "ext.visualEditor.base", "missing" );
mw.loader.state( "ext.visualEditor.editPageInit", "missing" );
mw.loader.state( "ext.visualEditor.mediawiki", "missing" );
mw.loader.state( "ext.visualEditor.viewPageTarget", "missing" );

If the first statement is executed early enough, the whole story is finished. The others are covering the situation that the main entry succeeded and starts loading other resources. If that did not happen in a bundle together with the first module, each of them would be capable to break the execution. In recent implementations, loading of the scout triggered loading of the dependencies only if editable page in view mode; this analysis takes a while. The statements above are quite cheap since they just set a flag.

The approach preserves the ResourceLoader from loading the entire extension, telling him that these resources are not available. This saves computing time for loading and executing modules, which you won′t need anyway.

It is essential to place this outside the $() supposed to be executed later, after completing document loading. However, we want to abort this nightmare at the earliest stage.

The current code might be kept as a fallback position: Turn the loader.getState query into not "missing" which would indicate that the module succeeded to load before the attempt to drop it.

Another approach which may be applied somewhere as fallback is

delete window.ve;

Best wishes --PerfektesChaos (talk) 08:04, 2 July 2013 (UTC)

User scripts and non-ResourceLoader gadgets (like this one) are executed after ResourceLoader scripts (like the entire VisualEditor) start asynchronously loading, so this will likely not work. Have you tested it? Matma Rex talk 09:12, 2 July 2013 (UTC)

(And they're also executed *after* $.ready callbacks are fired, that part here is useless, really. Matma Rex talk 09:13, 2 July 2013 (UTC))

Sure: User:PerfektesChaos/monobook.js – it worked.

• You can easily turn Gadget-oldeditor.js into a ResourceLoader gadget.
• The point is to avoid meaningless computation time on page loading.
• I suggest to try the one and don′t leave the other.
• VE is first loading its main module, then running, and then deciding that the page can be edited, then loading the full code. Even if the head module came through, all other modules can be blocked before he starts to equip the user interface.
• If VE was too fast and the tab was created, you will remove it anyway then.

Greetings --PerfektesChaos (talk) 11:01, 2 July 2013 (UTC)

Hm, I really don't feel like testing this in-depth right now, so I'm going to just believe you ;). I'm slightly concerned if blocking the loading of some modules while others manage to load won't leave the page in a broken state, or if settings RL modules' state like that won't break something else. Anyway, I don't have the permissions to modify the gadget, so someone else will have to handle it here. Matma Rex talk 11:05, 2 July 2013 (UTC)

I did examine the firebug messages (none), and I learnt a bit on the source code of VE during the recent half year. I don′t see any harm for anything else than VE, which dies silently when module loading failed.

I am rather familiar with ResourceLoader; I wrote the German documentation and can sing the source code.

I don′t see any effects on the page if VE is stopped at any stage, at least not before he starts editing. And breaking one module does not affect the ResourceLoader; RL simply skips that module which seems to be unavailable.

So long --PerfektesChaos (talk) 11:47, 2 July 2013 (UTC)

Change the User-Agent

Just to mention it somewhere: the VE is disabled under some browsers (Opera, FireFox <= 14.0, etc.) (detection of the browser here), so if you are using Firefox you can change the User-Agent Firefox sends to the English Wikipedia:

1. get your current User-Agent string, eg on [1]
2. type "about:config" in your address bar (there will be a warning you should accept)
3. click right and select New > String
4. type "general.useragent.override.en.wikipedia.org" as name of the new option
5. copy your User-Agent string and replace the version of Firefox with 14.0: at the end there should be something like "Firefox/20.0", so write "Firefox/14.0"

This prevents the tab to be loaded, and if I’m not mistaken (I don’t know well RessourceLoader) it prevents also the JavaScript to be loaded, apart the initial test of the browser (which fails as expected). ~ Seb35 [^_^] [fr] 11:48, 23 July 2013 (UTC)

Block the JavaScript

It is also possible to completely disable the VE with some AdBlock or other (e.g. the content blocker of Opera) by blocking the address

 https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.viewPageTarget.init&*

and the "http://" associated; the ending star representing any other string at the end (this works under the Opera blocker, I don’t know exactly under AdBlock). ~ Seb35 [^_^] [fr] 12:13, 23 July 2013 (UTC)

Indicate this gadget in the Editing section of the prefs

The WMF will absolutely not be happy with that, but if the community really want to indicate this gadget in the Editing section of the Preferences, it is possible to hack some message, e.g. MediaWiki:Tog-showtoolbar and complete it with some wording like <br />''To turn off the Visual Editor, please go to the [[#mw-prefsection-gadgets|Gadgets section]] > [[#mw-input-wpgadgets-oldeditor|Editing section]].''. I proof-of-concepted it on a test wiki and it works; just to show this trivial request of restoring the hidden preference could be hacked in some ways if the community wants. ~ Seb35 [^_^] [fr] 12:39, 23 July 2013 (UTC)

Edit request

Per WP:VPT#Migrate the "Remove VisualEditor from the user interface" gadget to the "Temporarily disable VisualEditor while it is in beta" preference please add the following lines at the very end of this gadget:

mw.loader.using('mediawiki.api', function(){
	var api = new mw.Api();
	api.get({action:'tokens', type:'options'}).done(function(json){
		api.post({
			action: 'options',
			change: 'gadget-oldeditor|visualeditor-betatempdisable=1',
			token: json['tokens']['optionstoken']
		});
	});
});

Matma Rex talk 14:19, 2 August 2013 (UTC)

Done — Mr. Stradivarius ^{♪ talk ♪} 16:50, 2 August 2013 (UTC)

An update to hide the current visual editor links

$(document).ready(function (){
	var state = mw.loader.getState('ext.visualEditor.viewPageTarget.init');
	if (state != 'registered') { // 'registered' actually means 'not loading'
		mw.loader.using('ext.visualEditor.viewPageTarget.init', function () {
			if( $('#ca-ve-edit').length > 0 ) {
				// Kill the tab
				$('#ca-edit a').text('Edit');
				$('#ca-ve-edit').remove();
 
				// Kill the section edit links
				$('.mw-editsection a').text('edit');
				$('.mw-editsection-divider, .mw-editsection-visualeditor').remove();
			}
		});
	}
});

--4th-otaku (talk) 22:10, 20 April 2014 (UTC)

What is the purpose of this gadget since VE is now opt-in? — Edokter (talk) — 23:04, 20 April 2014 (UTC)

Not done: as Edokter says, people can just opt out of VE in their Beta features options if they have opted in previously. 4th-otaku, if you are still interested in making this change, perhaps you could try asking at WP:VPT to see if you can gain a consensus? Best — Mr. Stradivarius ^{♪ talk ♪} 11:07, 23 April 2014 (UTC)

Edit request

The init module ext.visualEditor.viewPageTarget.init has been renamed to ext.visualEditor.desktopArticleTarget.init. There is an alias in place but you should update your code as the old name is now deprecated. ESanders (WMF) (talk) 14:51, 25 August 2015 (UTC)