Jump to content

MediaWiki talk:Common.js

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by He7d3r (talk | contribs) at 13:11, 8 April 2014 (I believe indicating the dependencies explicitly is better than making assumptions on the loading order of the modules, and then having to investigate/fix bugs in the future because of some MW update which changed our assumptions... (but yeh, Krinkle comm). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Protected edit request on 28 February 2014

Hi!

Could someone implement a fix for the problem which causes "Uncaught TypeError: Cannot call method 'addMessages' of undefined"? This was reported in 2012... Helder.wiki 21:50, 28 February 2014 (UTC)[reply]

From jQuery docs for $.getScript(): "The callback is fired once the script has been loaded but not necessarily executed." In other word, it is no different then using importScript. Has this been tested? — Edokter (talk) — 23:12, 28 February 2014 (UTC)[reply]
I'm not sure I understand: if importScript is asynchronous, what guarantee do we have that a line of code put after it will be executed only after the script is loaded?
Anyway, $.getScript() is in use on pt:MediaWiki:Gadget-refToolbar.js since 2012 with no problems so far. Helder.wiki 15:53, 1 March 2014 (UTC)[reply]
Both methods are asynchronous, which is why I would like a code reviews first. — Edokter (talk) — 16:02, 1 March 2014 (UTC)[reply]
@Krinkle, Matma Rex, and TheDJ: ^. Helder.wiki 16:31, 3 March 2014 (UTC)[reply]
@Edokter and Helder.wiki: importScript is definitely always asynchronous and has no callback, so it is definitely a bad choice here. The situation with $.getScript's callback is rather complicated at a glance and I really don't feel like digging through hundreds of lines of code right now to find out what exactly happens (Krinkle knows jQuery internals better than I do), but it is also definitely better here than importScript since it has at least some chance of firing only after the script was executed :)
The proper way to solve this, of course, would be to convert these scripts to default-enabled gadgets which will let you sanely specify dependencies between them and other modules. Matma Rex talk 19:03, 3 March 2014 (UTC)[reply]

Protected edit request on 28 February 2014

Hi again!

Could someone make this update too? Helder.wiki 21:59, 28 February 2014 (UTC)[reply]

Done. — Edokter (talk) — 23:00, 28 February 2014 (UTC)[reply]

Protected edit request on 14 March 2014

Could someone apply some changes to the "Collapsible tables" code to make it more similar to the version which is currently on mediawiki.org? This will make it easier for us to keep these two copies, and the other forks (more or less) synced. I made a related suggestion at mw:MediaWiki talk:Gadget-collapsibleTables.js#Update, to add some updates which were made on English Wikipedia but are not on mw.org yet. This new version deprecates the global window.collapseTable. I tested the code on testwiki:Sandbox, and it works exactly as it does on Help:Collapsing. Helder.wiki 14:49, 14 March 2014 (UTC)[reply]

Needs some cleanup; tabs and spaces for indenting are mixed all over the place. Did you mean "which is on test.wikipedia.org", seeing request on mediawiki.org is still pending? Also, how about throwing the whole thing away and finally start using mw-collapsible instead? — Edokter (talk) — 15:09, 14 March 2014 (UTC)[reply]
I clarified the text above. As for the indentation, I suggest making an edit to MediaWiki:Common.js to replace spaces by tabs, since this is what CodeEditor uses.
About the migration to mw-collapsible, I think we should really do that as soon as possible, and stop sending more this code to our readers, because MW already sends jQuery Collapsible plugin by default and that won't be changed. I suggested something like that before, but so far most templates are still using this old script. Previous topics on this issue:
Helder.wiki 15:33, 14 March 2014 (UTC)[reply]
Question: Couldn't it be set to be an independent script on mediawiki.org or meta and then just loader loaded on all other wikis? This would then allow all of the updates to that code to happen in one place all at once instead of having to bounce around all of the various wikis trying to get forks updated. — {{U|Technical 13}} (t • e • c) 15:29, 14 March 2014 (UTC)[reply]
Yep, at the cost of one (or two, if the CSS is in a separated page) extra HTTP requests. Helder.wiki 15:33, 14 March 2014 (UTC)[reply]
Question: Helder, would the 0.15-0.7 extra second for these one or two extra requests be that big of a deal? Either way Mr. S, I do not oppose this changes as the JavaScript looks sound to me. — {{U|Technical 13}} (t • e • c) 14:41, 30 March 2014 (UTC)[reply]
I'm not sure why I'm being pinged here. I'd prefer to leave this request to someone who can actually check the code. — Mr. Stradivarius ♪ talk ♪ 15:00, 30 March 2014 (UTC)[reply]
Not for me. Helder.wiki 15:56, 30 March 2014 (UTC)[reply]
Code updated, but removed the deprecation log; it would load at every page load. — Edokter (talk) — 16:31, 30 March 2014 (UTC)[reply]
Edokter, actually the warnings would only be loaded in the console if the user's scripts (or gadgets) are calling the deprecated global collapseTable. Otherwise, there will be no warning. This is the expected behavior. Helder.wiki 19:13, 30 March 2014 (UTC)[reply]
Oh well, my bad. Anyway, we all know it's there. — Edokter (talk) — 19:21, 30 March 2014 (UTC)[reply]
The point is to warn anyone who are still relying on this that it will be removed from the window object at some point. This would just remind people to fix their scripts. Helder.wiki 19:30, 30 March 2014 (UTC)[reply]
Meaning it will be removed here? What would be the best way to switch over anyway? Is there a way to map all classes and function to mw-collapsible? — Edokter (talk) — 19:54, 30 March 2014 (UTC)[reply]

Protected edit request on 15 March 2014

Could someone apply these changes to MediaWiki:Common.js/watchlist.js to stop the warnings on Special:Watchlist:

Use of "$j" is deprecated. Use $ or jQuery instead.

Helder.wiki 13:28, 15 March 2014 (UTC)[reply]

Done. — Edokter (talk) — 14:40, 15 March 2014 (UTC)[reply]

CodeEditor Feedback desired

Please read and give your input about what you are looking for in the CodeEditor toolbar —TheDJ (talk • contribs) 00:14, 26 March 2014 (UTC)[reply]

Move initializeRefTools to a default gadget

Hi!

I would like the code of RefToolbar to be moved into a default gadget (as in pt:MediaWiki:Gadget-refToolbar.js), which would be minified and loaded by ResourceLoader. This would also allow users to disable this script, and facilitate debugging (one can easily disable specific gadgets when looking for the cause of a problem).

Is there any reason not to do so? Helder.wiki 18:38, 7 April 2014 (UTC)[reply]

Makes sense, but the pt version loads the core scripts from URLs, bypassing RL. Make those hidden core gadgets so they can be loaded as modules as well. — Edokter (talk) — 20:17, 7 April 2014 (UTC)[reply]
Yep! They are loading those URLs just because the English version is not (yet) made up of small RL modules. I could update them to use English Wikipedia's load.php to get the minified version once the code is migrated to gadgets. Helder.wiki 20:25, 7 April 2014 (UTC)[reply]
I don't think that's proper use of load.php. JS modules are loaded by way of a call to mw.loader.load(). — Edokter (talk) — 20:51, 7 April 2014 (UTC)[reply]
What I meant was that other wikis could use something like
mw.loader.load( '//bits.wikimedia.org/en.wikipedia.org/load.php?modules=ext.gadget.EXAMPLE&only=scripts' )
instead of
mw.loader.load( '//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-EXAMPLE.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' )
to get the minified version of the module ext.gadget.EXAMPLE.
Anyway, that is only for other wikis. The loader on English Wikipedia will use just mw.loader.load( 'ext.gadget.EXAMPLE' ) to load the modules by their names (since they are local). Helder.wiki 21:02, 7 April 2014 (UTC)[reply]
Yes, but what I meant is; does load.php even support this manner of loading js modules? I've never seen it like this. — Edokter (talk) — 21:09, 7 April 2014 (UTC)[reply]
Never mind, should work in theory. Only plus is minification though. Doesn't save http requests. — Edokter (talk) — 21:14, 7 April 2014 (UTC)[reply]
Although I've never used it, it seems the external wiki could save http requests if it uses addSource and has more than one module to load from English Wikipedia. Helder.wiki 21:30, 7 April 2014 (UTC)[reply]
FYI: These URLs appears in the "Sources" tab of the Google Chrome console when we load a page in debug mode.
I've created a beta <gadget-refToolbar> on testwiki:. Could you enable it on your preferences to check if it is working as expected? Helder.wiki 21:41, 7 April 2014 (UTC)[reply]
It seems to load OK, but I don't see any extra buttons. — Edokter (talk) — 22:11, 7 April 2014 (UTC)[reply]
Edokter, which edit toolbar you tested? Which extra buttons were missing? Helder.wiki 22:27, 7 April 2014 (UTC)[reply]
I have the enhanced toolbar. Never mind though, I found it. The gadget works. Now it's time to test the rest being converted to core-gadgets. — Edokter (talk) — 22:36, 7 April 2014 (UTC)[reply]

Shouldn't there be a consensus for this established on some forum such as VPR before it is implemented here? I am requesting that this consensus be reached before implementation. I don't want to have this as a default thing (as IIRC it conflicts with other tools such as wikEd). — {{U|Technical 13}} (t • e • c) 22:04, 7 April 2014 (UTC)[reply]

There shouldn't be any change in functionality. In fact, the goal is to load less code when not needed by splitting of functional code and only loading a stub loader by default. We have done a similair thing with MediaWiki:Gadget-charinsert.js. — Edokter (talk) — 22:16, 7 April 2014 (UTC)[reply]
How so, Technical 13? Currently the script is loaded by default. By moving it to a gadget it will be possible to disable it if you don't use it (and even if you use, you should receive less code as a result of the change). Helder.wiki 22:23, 7 April 2014 (UTC)[reply]
Technical 13, it may not be visible for you, but the the loader code which is at MediaWiki:Common.js/edit.js is still loaded for you anyway, and what is worse: it also requests MediaWiki:RefToolbarBase.js and MediaWiki:RefToolbarLegacy.js (I provided a fix for this specific issue in the section below). Once the code is converted to a gadget, you will be able to avoid loading these three scripts. Helder.wiki 23:03, 7 April 2014 (UTC)[reply]
  • If Preferences → Editing → Empty Show edit toolbar (requires JavaScript) is disabled, then it should automatically detect that and not load that extra code slowing things down. Otherwise, people with that option unchecked will never get to benefit from this change because they will have no clue the change exists. Just my two cents about that. — {{U|Technical 13}} (t • e • c) 23:49, 7 April 2014 (UTC)[reply]
Yes, the script should detect that. This is why I requested a separated fix for that problem below. Helder.wiki 23:53, 7 April 2014 (UTC)[reply]

Protected edit request on 7 April 2014

Could someone apply these changes to MediaWiki:Common.js/edit.js? Whithout it, users who disable the toolbar are still downloading the code of the refToolbar. Helder.wiki 23:14, 7 April 2014 (UTC)[reply]

That diff is a mess! I gather the only change is:
if( !mw.user.options.get( 'showtoolbar' ) || window.refToolbarInstalled || $( '#wpTextbox1[readonly]' ).length ){
	return;
}
Correct? — Edokter (talk) — 23:32, 7 April 2014 (UTC)[reply]
Yes, sorry. The diff was clearer using the gadget wikEdDiff or Meld, but this is what I changed:
  • I replaced the wrapping "if( cond ){ ... }" by an earlier "if( !cond ){ return; } ..." (this caused most of the indentation changes which confuses MW diff engine)
  • I added the test !mw.user.options.get( 'showtoolbar' )
  • window.refToolbarInstalled === undefined was replaced by window.refToolbarInstalled
  • $( '#wpTextbox1[readonly]' ).length === 0 was replaced by $( '#wpTextbox1[readonly]' ).length
Helder.wiki 23:51, 7 April 2014 (UTC)[reply]
Done. — Edokter (talk) — 00:51, 8 April 2014 (UTC)[reply]
Helder.wiki, see Wikipedia:Village pump (technical)#Cite menu on toolbar missing!. If this edit changes the behaviour of the toolbar preferences, it should be reverted. Can you investigate? — Edokter (talk) — 11:43, 8 April 2014 (UTC)[reply]
Edokter, hmm... It seems this loader is using mw.user.options without declaring it depends on module "user.options" (but it was already doing that before my changes). You can try to change

$( initializeRefTools );

to

mw.loader.using( 'user.options', function () { $( initializeRefTools ); } );

to make sure this is loaded (the gadget version will have this dependency declared in its definition). The other alternative would be to create the loader gadget we are discussing in the section above. Helder.wiki 12:55, 8 April 2014 (UTC)[reply]
Never mind. According to TheDJ, it is actually behaving correctly now. Seems the reftoolbar was loading even with Enhanced Toolbar disabled in the preferences, which is now fixed. (PS. I think user.options is loaded by default, so no dependency needed.) — Edokter (talk) — 12:59, 8 April 2014 (UTC)[reply]
I believe indicating the dependencies explicitly is better than making assumptions on the loading order of the modules, and then having to investigate/fix bugs in the future because of some MW update which changed our assumptions... (but yeh, Krinkle commented in a patch sometime ago that this module in particular is loaded before other modules)
If this is not broken now, we could simply postpone this to when we define the new gadget. Helder.wiki 13:11, 8 April 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js&oldid=603298989"