This is an archive of past discussions about MediaWiki:Common.js. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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)
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?
@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 Rextalk19:03, 3 March 2014 (UTC)
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)
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:
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)
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)
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.wiki19:13, 30 March 2014 (UTC)
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.wiki19:30, 30 March 2014 (UTC)
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)
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
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.wiki12:55, 8 April 2014 (UTC)
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)
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)
That's what I meant; mw.user is a core module, just like mw.config. But yes, I would love a list of modules that do not need to be listed as dependencies. — Edokter (talk) — 13:50, 8 April 2014 (UTC)
Edokter: That sentence ("mw.user is a core module, just like mw.config") sounds rather wrong and is result of confusion in a few different ways. Let me clarify. There's three things at play:
The mediawiki base module ("mediawiki"). This one can't be declared as dependency (and doesn't have to be) because it is the base module that actually defines mw.loader itself. If memory serves, it currently defines mw.Map, mw.config, mw.messages, mw.Message, mw.loader, mw.html, mw.hook and a few miscellaneous methods. None of these have their own module (it's not that you can't or shouldn't depend on it, they simply don't exist as a module, e.g. there is no such module as mediawiki.config or mediawiki.html, it would throw "Unknown dependency" if you try).
Let me also note that the jquery module behaves in the same way. These two are the only ones you shouldn't (and even mustn't) explicitly specify as dependencies. Matma Rextalk18:22, 9 April 2014 (UTC)
Page modules: There are various modules that are loaded by default on a page (either because the Skin needs it, or because we use it for enhancing page content, or because an extension added it to the load queue etc.). This usually includes mediawiki.user, mediawiki.legacy.wikibits and others. Though these are loaded by default, they absolutely must not be assumed as being available at all times. If you use mw.user, you *have* to declare that dependency. Two reasons for this: 1) The default list can change (either in general or for some pages). There is nothing that says they will always be loaded, they are loaded because some part of the application uses them (just like your preferences panel will add a gadget if you tell it to, and if that gadget is on every page and loads mw.Title then that module will be on every page, but that's just a coincidence). They are not part of the "this is always available, use freely" and never have been. 2) While they are loaded by default, even now things load in parallel (this is by design). If you want your code to execute after "mediawiki.user" has finished loading, you have to indicate this through a dependency or else there will be race conditions where mw.user is still undefined and your code will fail.
Globally embedded page modules. These modules (such as "user.options") are embedded within the page for security and/or performance reasons. Since they execute synchronously and are embedded before any load queue, these not only load by default but also "finish" loading before any module, gadget or otherwise starts loading. Which means technically you can get away with not specifying user.options as a dependency because it's impossible for them not to be there. However, once again, do not rely on the arbitrary implementation detail that this particular module is being embedded right now.
In short: Just declare all your direct module dependencies (either inline with loader.using or with gadget[dependencies=]) and let ResourceLoader do its job. Krinkle (talk) 17:53, 9 April 2014 (UTC)
Krinkle In short... confusion galore. The naming conventions doesn't help. I thought user.options was part of mw.user (confusion nr.1) and mw.user was stated to be part of mw.map, but not anymore (since today, confucion nr.2). Lastly, there are the base module and page modules, both starting with mediawiki. (or .mw?), which creates more confusion. For instance, I do not need to declare mw.config, but I do need to declare mw.util! That is why we want a simple list of which of these mediawiki. modules are part of the base module and should not be declared. Then I can happily declare everything else. — Edokter (talk) — 21:46, 9 April 2014 (UTC)
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).
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)
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.wiki20:25, 7 April 2014 (UTC)
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)
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.wiki21:02, 7 April 2014 (UTC)
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)
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.wiki21:30, 7 April 2014 (UTC)
FYI: These URLs appears in the "Sources" tab of the Google Chrome console when we load a page in debug mode.
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)
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)
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)
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.wiki22:23, 7 April 2014 (UTC)
If Preferences → Editing → 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)
mw.log.warn('[[w:en:MediaWiki:RefToolbarBase.js]] was moved to [[w:en:MediaWiki:Gadget-refToolbarBase.js]].'); mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-refToolbarBase.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400');
for the convenience of other wikis which import this page into their site JS or gadgets
Sure. I edited my previous comment to suggest descriptive summaries for each step. Feel free to improve on that :-) Helder.wiki20:09, 12 April 2014 (UTC)
Note that other wikis are pulling the code from its current location, so this will either need to be coordinated cross-wiki or the current script locations will need to continue to work. Mr.Z-man20:20, 12 April 2014 (UTC)
Helder is correct, the note that it was moved and the redirect is the best way to go about it. There is no need to wait any longer. :) — {{U|Technical 13}}(t • e • c)14:37, 15 April 2014 (UTC)
I left a note in the talk pages of the affected scripts on other wikis, notifying the users who I believe are the maintainers. Helder.wiki21:57, 1 May 2014 (UTC)
@Helder.wiki, Technical 13, Edokter, and Mr.Z-man: is there code in place so that the current script locations will still work after the change, as Mr.Z-man suggested? If not then I should probably mark this edit request as answered until the code is in place, as this request has already been open for 11 days and nothing much seems to be happening with it. — Mr. Stradivarius♪ talk ♪11:16, 23 April 2014 (UTC)
Do I need to make anything else to get thes changes implemented so I can move on to the other parts of the script? Helder.wiki11:58, 30 April 2014 (UTC)
OK, not entirely sure; the headers returned to me (over HTTP and HTTPS) always return zero. But I do notice that raw content is always 'fresh', so it seems to ignore those values. Perhaps someone else can explain the necessity/obsolescence of &smaxage=21600&maxage=86400 for raw content. — Edokter (talk) — 19:11, 30 April 2014 (UTC)
Is RefToolbar being executed on pages where it shouldn't?
// Only execute on edit, unless it is a user JS/CSS page// TODO: Remove tests already done by [[MediaWiki:Gadget-refToolbar.js]]if((mw.config.get('wgAction')==='edit'||mw.config.get('wgAction')==='submit')&&((mw.config.get('wgNamespaceNumber')!==2&&mw.config.get('wgNamespaceNumber')!==4)||(mw.config.get('wgPageName').indexOf('.js')===-1&&mw.config.get('wgPageName').indexOf('.css')===-1))){...}
On the other hand, the highlighted tests are missing on versions 2.0a (no dialogs) and 1.0. (legacy). Is that the desired behavior? Shouldn't all versions be present in the same set of pages/namespaces?
If the answer is yes, we could make all these tests just before calling "$( initializeRefTools )" on MediaWiki:Gadget-refToolbar.js, to avoid loading other parts unnecessarily.
If not, they could still be moved to the loader, but would be inside the if-block which loads the version 2.0b
I wouldn't bother with the old toolbar, but ideally, yes, the tests should be for all versions. — Edokter (talk) — 19:44, 1 May 2014 (UTC)
I don't think it really makes much of a difference whether its loaded on CSS/JS pages or not, but if we're going to do it, doing the checks as early as possible would be best. Mr.Z-man21:17, 1 May 2014 (UTC)
I'm all for, but beware that some wiki's might use different images to indicate this state, different classes in the content and have different types of badges. So it might still need quite a bit of 'configuration' in the setup step. —TheDJ (talk • contribs) 17:31, 26 July 2014 (UTC)
Also, I think I noticed that the wikidata team is working on putting some of this info in wikidata, so you might wanna check if this replace action can be prepared for that step as well. —TheDJ (talk • contribs) 17:33, 26 July 2014 (UTC)
m:Wikidata/Development/Badges, linked by Heldir above, is about that. It would be more logical to host the global gadget at Meta (or Wikidata) IMHO, but doesn't matter that much; it's fine to only use it on wikis which use the default icons. --Nemo17:38, 26 July 2014 (UTC)
I added a few TODOs in the comment above the code, but what we have now should be enough to get the feature working again in most wikis.
The small disadvantage of moving it on Meta is that it is not used on Meta itself, so it would not be editable by any of the wikis where it is needed (and by hosting it on enwiki we would save an HTTP request at least for users of the biggest Wikipedia). Helder.wiki18:07, 26 July 2014 (UTC)
Hi, please note that this JavaScript hack is not needed any more because Wikidata will support badges soon which will make the JavaScript obsolete. I'll contact you later again how you can make your current styling compatible with the new system. Best regards, -- Bene* (talk) 07:44, 31 July 2014 (UTC)
Ok, maybe you can give me the list of wikis then which use the new gadget to make migration to wikidata easier? There will also be titles on the li elements based on the label of the badge's item on wikidata. -- Bene* (talk) 22:11, 3 August 2014 (UTC)
@Edgars2007: if your wiki uses the same classes ("FA", "GA" and "FL"), you can import the CSS from here to get the same icons used on English Wikipedia or keep your previous CSS to use your own custom icons. Helder23:54, 16 August 2014 (UTC)
Add Featured List on interwiki
This edit request to MediaWiki:Common.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Dear sysops. I think something like
if ( document.getElementById( className + '-fl' ) ) {
InterwikiLinks[i].className += ' FL';
InterwikiLinks[i].title = 'This is a featured list in this language.';
should be added there. I don't know whether it's perfectly okay, but something like this. Cause you can't compare a FL with a FA. Also FLs are not FAs. So something kinda this should be added. Thanks. --Pratyya(Hello!)15:02, 2 August 2014 (UTC)
If English Wikipedia community wants to style interwikis to featured lists differently (that should probably be discussed elsewhere, to get consensus), this is what is needed in the technical side:
Announced JavaScript change for badges implementation
Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene* (talk) 10:19, 7 August 2014 (UTC)
There will be a simple check in the if-clause which tests if the badge is already tagged by the new system or we have to apply the old procedure. -- Bene* (talk) 07:24, 8 August 2014 (UTC)
@Edokter: Thank you! Also I just realized that the ieCSS can be updated too. For the first rule, @media print is not supported by IE 8 and below [1]. So if the "line-height" issue doesn't exist in IE 9 and above, I think we can just remove it, since it won't work on old IE anyway. Also do these bugs apply to latest versions of IE? If not, I suggest we change MediaWiki:Common.js Line 119 from
if ( $.client.profile().name === 'msie' )
to
if ( ($.client.profile().name === 'msie') && ($.client.profile().versionNumber < 11) )
The "11" can be replaced with the version number where the three bugs do not exist. In this way, some IE users don't have to load one more file if they don't need it. Chmarkine (talk) 04:03, 21 September 2014 (UTC)
I don't know ie IE 8-11 have the print bug, so I'm leaving it for now; someone more print-knowledgable wil have to test this. IEFixes.js is for all version of IE, But if you are absolutely certain IE11 does not need any fix, we may add the check. -- [[User:Edokter]] {{talk}}07:07, 21 September 2014 (UTC)
@Edokter: IE 8 and above don't have the print bug. The original discussion about this bug is here where Gadget850 said "it does not happen in FireFox, Chrome or Internet Explorer 8rc1". I also tried printing on IE 8 on XP SP3 without IEFixes.js, and there was no issue. So it will cause no problem to remove the line-height CSS rule. I am not very sure about the next two bugs, but I think IE11 is fine. Chmarkine (talk) 23:41, 21 September 2014 (UTC)
I will disable all CSS form IEFixes.js; The print bug is likely IE7 only, the overflow bug is redundant as nothing seems to use these classes, and I can no longer trigger the bug targeted by the zoom fix in IE8. -- [[User:Edokter]] {{talk}}19:35, 14 November 2014 (UTC)
I have disabled secure_new.js. With HTTPS being the default for logged in users, and protocol-relative linking being the standard, I don't see any added value for this script, unless I'm missing something... -- [[User:Edokter]] {{talk}}09:35, 13 November 2014 (UTC)
@Edokter: A lot of users post HTTP "external" links that actually go to Wikipedia pages (like this one). Without this script, users will become insecure as soon as they click on one of them. I think we should re-enable the script ASAP to avoid users dropping out of SSL when they haven't before. Jackmcbarn (talk) 15:42, 13 November 2014 (UTC)
Over the last few months I have noticed a significant increase in the number of cases where a full URL is used when a normal wikilink, interwiki link or interlanguage link would have been better. It is no longer possible to locate and fix these through Special:LinkSearch, see bugzilla:72185. --Redrose64 (talk) 15:52, 13 November 2014 (UTC)
@Jackmcbarn: Then they shouldn't post these links (idea for edit filter?) All projects have HTTPS enabled by default for logged in users now. Is there any common scenario that absolutely requires this script? One of the reasons I'd like to kill it is processing time; every link on every page needs to be enumerated, which has quite an impact on load time. -- [[User:Edokter]] {{talk}}17:32, 13 November 2014 (UTC)
@Edokter: If the filter were set to disallow, it would be seen as too BITEy, and if it weren't, it would be the same as not having it at all, since the links could still get through. (And there'd also be the problems of false negatives and old revisions.) The script needs to stay enabled until WMF turns on HSTS. Jackmcbarn (talk) 03:56, 14 November 2014 (UTC)
The original script was never intended to target external link put in by editors, but to handle all interface- and wikilinks that were still hardcoded to use http before protocol-relative linking was introduced. As it is now, the script hogs CPU during page load enumerating all the links, even for 99.9% of the pages that do not need it. It may also interfere with the "Always use a secure connection when logged in" where editors have disabled that option on ohter projects. Those conscious enough about security already have measures in place like HTTPSAnywhere. Most other projects have disabled it already; the performance hit is simply not worth it. If the WMF is so concerned, why not skip HSTS and disallow HTTP alltogether? -- [[User:Edokter]] {{talk}}09:38, 14 November 2014 (UTC)
Some users are unable to use HTTPS for various reasons, so I don't think we'll ever be able to disable insecure connections. Right now with the script disabled, the only thing keeping me on HTTPS is HTTPS Everywhere, and most users don't have that and will fall out of it now. Jackmcbarn (talk) 13:11, 14 November 2014 (UTC)
That only benefits users that are logged in here, but not on other projects. And then SUL usually kicks in and logs them in, resetting them to a secure connection. Only anonymous users seem to be affected here. -- [[User:Edokter]] {{talk}}15:38, 14 November 2014 (UTC)
If a logged-in user follows an insecure link, their browser will send all of the request data insecurely, then the server may kick them back to SSL, but by then it's too late. Jackmcbarn (talk) 15:56, 14 November 2014 (UTC)
You just need to enable the gadget by default and it will be loaded to anonymous users too, while still being opt-out. Helder18:07, 14 November 2014 (UTC)
I'm still not convinced. ((U|Jackmcbarn}} This is bordering on paranoia. He7d3r A default gadget still incurs a major performance hit. Again, what is the pressing rationale for keeping this script live? Shall we wait until there are some actual complaints? -- [[User:Edokter]] {{talk}}19:10, 14 November 2014 (UTC)
Because of the server's redirecting, users most likely won't notice that some links don't use SSL at first. The only reason nobody's complaining is because they don't realize it's happening. Jackmcbarn (talk) 21:28, 14 November 2014 (UTC)
I have "Always use a secure connection when logged in" disabled and this indeed is suspected of interfering and causing issues with that (if I remember correctly, mostly when editing/reading from a mobile device in desktop mode). — {{U|Technical 13}} (e • t • c)20:16, 14 November 2014 (UTC)
There's an older version here at the English Wikipedia, MediaWiki:Gadget-OSM.js, but it needs to be updated to use WMF Labs instead of the Toolserver. The OSM gadget is currently used in place of WikiMiniAtlas at the German Wikipedia and a few other wikis (more info). Since that gadget uses a tile server that only supports labels in three languages, the Vietnamese Wikipedia has a separate OSM gadget hooked up to yet another tile server that supports all languages. It also uses the Leaflet library instead of OpenLayers, resulting in a smoother UI than Gadget-OSM.js. In defense of WMA, though, it supports 3D buildings, a different projection capable of displaying the poles, and several other planetary bodies. – Minh Nguyễn💬05:30, 14 February 2015 (UTC)
We should avoid adding new things to common.js and create Gadgets instead. Main reasons are: makes debugging easier, allows users to opt-in/out of specific features, better modularization. Helder16:12, 10 October 2014 (UTC)
There's no way to have javascript be always-on, so there is no reason to force scripts on to anyone and a Gadget is more appropriate (even if it is on by default forcing them to opt-out). — {{U|Technical 13}} (e • t • c)16:50, 10 October 2014 (UTC)
I consider it a disadvantage that it could be disabled, since users who don't understand what it does may accidentally turn it off and then wonder why infoboxes look stretched out for them. After all, you can't accidentally turn off autocollapse in core. Jackmcbarn (talk) 04:37, 11 October 2014 (UTC)
@Jackmcbarn: I think the ResourceLoader flag also needs to be set. (Although it often makes sense to set the rights to editinterface so people who know what they're doing can see the gadget.) There's also the hidden flag, which is used by MediaWiki:Gadgets-definition presumably for helper gadgets that are only loaded by other gadgets as dependencies. – Minh Nguyễn (talk, contribs) 09:06, 16 October 2014 (UTC)
@Mxn: I tried that, and it didn't work either. There is no actual hidden flag in Gadgets right now, and if a user doesn't have the right to see a gadget, it's not enabled for them, even if it's otherwise enabled by default. There's currently no way to have a mandatory gadget. Jackmcbarn (talk) 15:31, 16 October 2014 (UTC)
Which would be opposed anyways. Quite simply, people on mobile devices might not care about how infoboxes look (I certainly don't) and won't want additional JavaScript bloat forced upon them costing them extra money for every page they want to view. There has to be an opt out option for this kind of "cosmetic" .js bloat. — {{U|Technical 13}} (e • t • c)17:17, 16 October 2014 (UTC)
Support. We need better ways to provide geographic information (i.e. maps) in infoboxes than we have currently, and this proposal seems to be a step in the right direction. I see this as a basic need, not optional, thus not simply a gadget. --ELEKHHT01:25, 11 October 2014 (UTC)
Support as a default-enabled gadget. We had the exact same functionality added on the Polish Wikipedia as a default gadget some years ago (pl:MediaWiki:Gadget-map-toggler.js; limited by design to two maps only; see e.g. pl:Kraków) and no one had ever complained after accidentally disabling it. We even have the styling of the main page implemented as a default-on gadget (pl:MediaWiki:Gadget-main-page.css) and no one has problems with it either (I'd make it always-enabled if it was possible, though). I have no reasons to suspect the community here is stupider than the one there and I believe they can deal with it. Matma Rextalk08:04, 11 October 2014 (UTC)
Well, sort of. They both provide an interface for looking at maps at different scales. Personally I don't think infoboxes are a great interface for interactive UI elements, as you have limited space and they are already pretty complicated as far as the density of information and UI. Personally, I would want to be able to opt-out of such a feature, so I think I would oppose adding it to Common.js. MoreTomorrow (talk) 19:02, 10 March 2015 (UTC)
Button for collapsible contents added more than once for dynamic content
This edit (@TheDJ:) added the code to insert buttons to collapse content to the wikipage.content-hook, but this hook can be fired multiple times even though only part of the page changes. You can see this behavior on File:Herculano, Alexandre, História da Origem e Estabelecimento da Inquisição em Portugal, Tomo I.pdf. Note that the author entry is collapsed. Now click "next page". You'll find that a second (and when you click more often even more) button to show the author is inserted. The code to add a button to collapse content must only work on the newly added content, not on the whole page. --Schnark (talk) 09:16, 20 January 2015 (UTC)
It suspect worked before, ie. I don't think he added it to make it work. But if the code is essential, there should be some option to prevent the hook being fired ad infinitum. -- [[User:Edokter]] {{talk}}09:22, 10 March 2015 (UTC)
TheDJ: is that change from HeaderRow.getElementsByTagName( 'th' )[0]; to table.getElementsByTagName( 'th' )[0]; intentional? Previously, it would get the first th which is inside the first tr of the table. Now it gets the first th of the table (even if it is not inside the first tr). Helder21:37, 14 March 2015 (UTC)
A header always resides inside a row; the parser makes sure of that. Even if you craft some handy HTML where it doesn't, Tidy will make sure of that. -- [[User:Edokter]] {{talk}}23:04, 14 March 2015 (UTC)
If we don't like the labels (e.g. "480px" instead of "480 x 480 pixels") that's something we can work on.
Unless reason to otherwise, I'd like to remove this redundant script as soon as possible. Or at least work it into something that isn't loaded with importScript from MediaWiki:Common.js. Krinkle (talk) 20:11, 3 July 2015 (UTC)
Removed. Probably just an oversight after the links were implemented in core. In light of this, I'd like to inversigate the possible removal of /edit.js and /watchlist.js as well (or at least move the conditionals to Common.js). -- [[User:Edokter]] {{talk}}08:55, 4 July 2015 (UTC)
I would've preferred to wait to hear from TheDJ, but removing this script seems fine to me. I also agree with re-evaluating all of the other custom JavaScript we have. The less, the better. --MZMcBride (talk) 13:49, 4 July 2015 (UTC)
I want to make a concerted effort to clean up the mutitude of collapsible code here. Due to ever-increasing evolution, we now have three method for collapsing:
.mw-collapsible from core
Collapsible tables (.collapsible)
'box hiding thingy' (.navFrame)
I want to eliminate the latter two as obsolete. This will break certain scenarios, so there are two things to account for:
For tables: make .autocollapsible work with .mw-collapsible (this should be relatively easy)
Make the old classes work as aliases for .mw-collapsible by scanning the page and replacing the classname
Support in principle. I tried to do this a few years ago, but ran into several problems:
Do we want table or div-based collapse? Collapsible tables where intended to be used only with navboxen, for which they worked perfectly. For many other applications div-based collapse seems more appropriate. This is why navFrame is (was?) still in heavy use. One option is to recode navboxen to use divs, another is to have a single (or fourth...) piece of code that can handle both tables and divs. Either would require some significant coding work.
All approaches are still in use, so lots of templates and talk page (archives) will have to be changed, which is tedious work.
I am currently not able to use User:Mr.Z-man/closeAFD2.js due to the "close" tab not appearing on the "more" menu. Since the script was working at the beginning of September 15, and has not recently been modified, I believe that recent edits to this page have caused the difficulty. DavidLeighEllis (talk) 00:59, 16 September 2015 (UTC)
Done. Made some minor modifications, like naming. Does someone know if it is possible to load system messages from JavaScript? -- [[User:Edokter]] {{talk}}19:45, 13 September 2015 (UTC)
I'm not interested in translation (anons can't set UI language anyway, right?), just the existing default messages for the popup hints, and perhaps "Talk" and "Contributions". mw:Manual:Messages API#Using messages in JavaScript suggests it is possible, but needs an API call to pre-load the specific messages. Just wondering if this is at all usefull and desired. -- [[User:Edokter]] {{talk}}16:37, 15 September 2015 (UTC)
@MZMcBride: See also this thread. The contribs/talk links are handy, they save a step or so in accessing the pages. We do need to get rid of the grey 'not logged in' text though. It's annoying, spans 40% of the edit window & redundant with the log-in link there anyway, esp. when we've the MediaWiki edit/preview messages as well. As for the person icon I'm not too bothered, but I guess it doesn't add much being there. –84.92.129.87 (talk) 23:04, 17 September 2015 (UTC)
Thanks to the above piece of code, Wikivoyage is not anymore mirrored by *.wikivoyage.net.ru, but all its link are redirected to en.wikipedia.net.ru/wiki/Main_Page, so en.wikipedia.org should be protected by the same (or similar) code. I don't understand if the lack of comment is because the community is ok on profitable bad mirroring or because of the lack of knowledge to understand what I'm talking of :-)
Basically... yes, we are OK with mirroring. But we cannot possibly and reliably ban bad mirrors this way. In fact, the Wikivoyage code has already been defeated and the mirror now redirects to another mirror, not the real Wikivoyage page as directed by this script. This is basically a whack-a-mole solution that needs constant monitoring. So no... I see no benifit for adding this code. -- [[User:Edokter]] {{talk}}13:20, 27 September 2015 (UTC)
Although I personally don't like that people earn money leveraging for free on the WMF server, but I'm fine if the en:w community are OK with that. By the way, that site has not by-passed this patch, they have stop to access on Wikivoyage, redirecting each link to the English Wikipedia, that's why I've written here. However thank you for the answer; I don't like to have pending conversation ;-) --Andyrom75 (talk) 16:36, 28 September 2015 (UTC)
I'm thinking of the wrong modules... But I think the little use it will have does not quite warrant inclusion. Do you have a use case? And why is it limited to gadgets? -- [[User:Edokter]] {{talk}}19:25, 13 October 2015 (UTC)
Mainly so I can give people a link to demonstrate how a gadget works without requiring them to go into their preferences to enable it, save their preferences, etc. I suspect it'll have similar usage levels to the current withCSS/withJS parameters, which I suspect isn't very much. I'm not sure why it's limited to just gadgets TBH. Legoktm (talk) 21:29, 13 October 2015 (UTC)
Protected edit request on 9 December 2015
This edit request to MediaWiki:Common.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Remove: function addAnonToolbarLinks() and all of it's associated code & comments, as this has now been added to MediaWiki core. Kharkiv07 (T)19:51, 9 December 2015 (UTC)
The guideline for creating tables in articles/lists on Wikipedia is MOS:DTT. That recommends using captions (|+) to annotate tables and provide them with headers, etc. There is a specific exception for collapsible tables, because the code used for collapsing does not support captions. I've been looking at the relevant bit of code in Mediawiki:Common.js and it seems to me that it would be trivial to add it so that this works correctly. It's not a nice little bit of Javascript (it abuses the id property) but it's not complex and this is a fairly simple addition.
It would need to go around line 233.
/* only add button and increment count if the table has content */varHeaderRow=table.getElementsByTagName('tr')[0];if(!HeaderRow){return;}varHeader=table.getElementsByTagName('caption')[0];if(!Header){Header=table.getElementsByTagName('th')[0];if(!Header){return;}}
This adds the content to the caption if it exists and to the first th cell if it doesn't, to support the current functionality. I've tried this out and as far as I can tell this works on caption cells as well as it does on th cells. It would be really good if the MOS-recommended tables worked with captions as well.
If we do this, we would also need to add code to determine whether the first row of the table needs collapsing as well. Perhaps something like:
I'm not familiar with Wikipedia's JS rules/standards or the processes of this page, so I hope I've got it right! Do let me know if I ought to cross-post to WP:VPT or if this is a perennial proposal that I've missed. Relentlessly (talk) 10:48, 9 October 2015 (UTC)
@Relentlessly: What is the id abuse? I don't see it. Maybe I need coffee. If this can work without literally abusing id (i.e. having more than one id with the same value on the same page, or using invalid values of the attribute), then this would be really fantastic to implement. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 12:48, 6 March 2016 (UTC)
I thought the ping would work as long as there was a new sig/timestamp. Why can't they fix this thing? <sigh> — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:38, 7 March 2016 (UTC)
The problem here is (a) that it uses the id attribute to store data, which is semantically wrong (and why isn't it using the id property instead?!) and (b) that it destroys any existing id attribute on the element. Now, this won't be an issue for most tables, but occasionally it might be useful to give a table an id, e.g. if direct linking is useful. Relentlessly (talk) 14:15, 7 March 2016 (UTC)
I've started a documentation snippet at Help:Infobox/user style, transcluded into various relevant pages, on how to hide infoboxes with user CSS. It would be useful for many users who don't like infoboxes (and for WP as a whole, to get those people to give it a rest) to have two alternatives to hiding them: a) be able to have infoboxes be collapsible (including collapsed by default for those users if they want it that way), or b) be able to move them to the bottom. I'm not sure what the most effective way to go about this is with Special:MyPage/common.js. One cannot simply try to shunt the infobox to the bottom with pure CSS. This is notoriously impossible without the moved element overlapping other content [2]. It requires one of several methods of injecting additional HTML and CSS into the document strategically [3], but I'm not sure which of these has the lowest impact, or will even work (given the kinds of "don't do certain things" filtering that MW does).
The most common usage is almost certainly going to be to make them collapsible, and for users who don't like them and to have them collapsed by default. This way, their content would still be available in the frequent cases that MOS:INFOBOX has not been complied with and details are in the infobox but not in the main article body. I myself would like to be able to collapse them after skimming them, especially on mobile. But I'm not sure what the lowest-overhead method is to inject the mw-collapsible class (it doesn't work with either of the other two classes for collapsibility). I have to wonder why infoboxes do not already have this class, uncollapsed by default; I would have thought that would have been implemented immediately. (That said, there is for now a minor display bug with making them collapsible, as I've documented and demoed at Template talk:Infobox#Minor bug.)
I suspect that someone has already worked this out, however, given how many people hate infoboxes. (I'm not among them, but the constant activism by some against infoboxes has led to multiple ArbCom cases, and will lead to more of them, because the anti-infobox warring has not abated. The only solution is to make it easy to move them "out of the way" to remove the inspiration for people's "cleanse" infoboxes from WP or from articles particular wikiprojects where these people have gathered are claiming scope.) — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 13:02, 6 March 2016 (UTC)
Current OS usage is Windows XP 11%, Windows 10 13%, and Windows 7 52%. IE 6+ is listed as "basic" on mw:Compatibility#Browser support matrix, while IE9 is at "modern". Microsoft dropped IE8, IE9, and IE10 support in January 2016 [4].
<rant> Apple's Phil Schiller commented that 600 million people using 5+ year old PCs is "sad". Silicon Valley can shove its glossy plastic up its own ass. There's no way Android 2.3 (supported at "Modern") is more competent than WinXP. — Dispenser16:02, 25 March 2016 (UTC)
@Ruud Koot, Dispenser, and Edokter: Actually, Windows XP is currently about 2.5% of our page views (across all Wikimedia sites); data for the latest week I can grab:
Client OS breakdown for Wikimedia sites by number of page views; week of 2016-03-06
I often hear large parts China still use XP, so that may inflate global XP usage, which may be significantly less for en.wiki-only stats. -- [[User:Edokter]] {{talk}}18:56, 25 March 2016 (UTC)
This currently affects up to 1.1% of users weighted by page views. Shall we wait 2 or 3 more months until Chrome on XP is really dead and this may fall under 1%? —Ruud20:34, 26 March 2016 (UTC)
As I noted above; if countries like China contribute to these numbers (by way of visits to cn.wiki), XP usage be be inflated. That is why I am hoping to see some numbers specific to en.wiki. I suspect it would dive under 1%. -- [[User:Edokter]] {{talk}}11:43, 27 March 2016 (UTC)
It might no longer be supported by Microsoft, but that doesn't mean that people have stopped using it. My hardware is not capable of running anything that is (a) more recent and (b) reliable. --Redrose64 (talk) 20:41, 25 April 2016 (UTC)
Are you referring to Unicode or IPA? Unicode was removed weeks ago. Anyway, MS dropped support two years ago, and browsers that need this (Chrome) have dropped support as well. If you use Firefox, you should be OK. -- [[User:Edokter]] {{talk}}21:35, 25 April 2016 (UTC)
