Jump to content

MediaWiki talk:Common.js/Archive 21

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15←Archive 19Archive 20Archive 21Archive 22Archive 23

Protected edit request on 28 February 2014

Hi again!

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

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

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)

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?
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)
Both methods are asynchronous, which is why I would like a code reviews first. — Edokter (talk) — 16:02, 1 March 2014 (UTC)
@Krinkle, Matma Rex, and TheDJ: ^. Helder.wiki 16:31, 3 March 2014 (UTC)
@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)

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)

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

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)

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)

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:
Helder.wiki 15:33, 14 March 2014 (UTC)
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)
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)
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)
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)
Not for me. Helder.wiki 15:56, 30 March 2014 (UTC)
Code updated, but removed the deprecation log; it would load at every page load. — Edokter (talk) — 16:31, 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.wiki 19:13, 30 March 2014 (UTC)
Oh well, my bad. Anyway, we all know it's there. — Edokter (talk) — 19:21, 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.wiki 19: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)

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)

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)
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)
Done. — Edokter (talk) — 00:51, 8 April 2014 (UTC)
Helder.wiki, see Wikipedia:Village pump (technical)/Archive 125#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)
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)
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)
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)
BTW: I requested more docs about modules loaded by default on bugzilla:63674. Helder.wiki 13:22, 8 April 2014 (UTC)
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 Rex talk 18: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)
I copied this reply to T65674, awesome. Matma Rex talk 18:22, 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).

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

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.wiki 20: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.wiki 21: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)
Never mind, should work in theory. Only plus is minification though. Doesn't save http requests. — Edokter (talk) — 21:14, 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.wiki 21: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'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)
It seems to load OK, but I don't see any extra buttons. — Edokter (talk) — 22:11, 7 April 2014 (UTC)
Edokter, which edit toolbar you tested? Which extra buttons were missing? Helder.wiki 22:27, 7 April 2014 (UTC)
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.wiki 22:23, 7 April 2014 (UTC)
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)
  • 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)
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)

Edit request

So, Edokter, after testing a gadget version for a while on testwiki:, I believe it is safe to do the following steps on English Wikipedia:

Helder.wiki 18:02, 12 April 2014 (UTC)

All that's needed is a nice description. — Edokter (talk) — 18:51, 12 April 2014 (UTC)
Sure. I edited my previous comment to suggest descriptive summaries for each step. Feel free to improve on that :-) Helder.wiki 20:09, 12 April 2014 (UTC)
No... I mean the description for the gadget to go in MediaWiki:Gadget-refToolbar. — Edokter (talk) — 21:46, 12 April 2014 (UTC)
Which is already there... D'oh. — Edokter (talk) — 21:46, 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-man 20:20, 12 April 2014 (UTC)
Mr.Z-man, do you mean MediaWiki:RefToolbarBase.js? It is enough to re-create that page with a "redirect" and a deprecation log as I aded above. Helder.wiki 13:02, 13 April 2014 (UTC)
I will wait until this is settled. — Edokter (talk) — 21:52, 12 April 2014 (UTC)
I opened a request on Bugzilla and Hoo provided a list of pages on WMF wikis using Reftoolbar from enwiki so we can send a message to them about this change. Helder.wiki 18:58, 1 May 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.wiki 21:57, 1 May 2014 (UTC)

So? Helder.wiki 18:43, 19 April 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)
Sorry about that. I haven't gotten around to review and test the code myself just yet. — Edokter (talk) — 11:22, 23 April 2014 (UTC)
@Mr. Stradivarius: Yep. In the request above the only script which is being moved to another place is MediaWiki:RefToolbarBase.js, which would be replaced by a "redirect" based on "mw.loader.load". Helder.wiki 11:32, 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.wiki 11:58, 30 April 2014 (UTC)

 Doing... Expect a few minutes of disruption. — Edokter (talk) — 13:19, 30 April 2014 (UTC)
 Done. WP:REFTOOLS will need updating. — Edokter (talk) — 13:38, 30 April 2014 (UTC)
Thanks Edokter!
Did you remove the cache parameters "&smaxage=21600&maxage=86400" from MediaWiki:RefToolbarBase.js intentionally? Helder.wiki 13:54, 30 April 2014 (UTC)
Yes, they serve no purpose; they are the default cache parameters. — Edokter (talk) — 14:23, 30 April 2014 (UTC)
@Edokter: You sure? Isn't the default 31 days? The examples from mw:RL/MGU#Gadgets uses 6 hours and 1 day as above. Helder.wiki 16:50, 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?

Most of the code of version 2.0b (dialogs) is inside of a test like this: 

// 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

Helder.wiki 21:43, 30 April 2014 (UTC)

What do you think, Mr.Z-man, Edokter? Helder.wiki 19:37, 1 May 2014 (UTC)
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-man 21:17, 1 May 2014 (UTC)
A better check might be mw.config.get('wgPageContentModel') !== 'wikitext'. Legoktm (talk) 23:43, 18 May 2014 (UTC)
Agreed. Kaldari (talk) 00:37, 19 May 2014 (UTC)

Global gadget for LinkFA

See also: MediaWiki talk:Common.js/Archive 20 § LinkFA is broken, and mailarchive:wikitech-ambassadors/2014-July/000827.html

Hi!

In the interest of fixing the linkFA code in 200+ wikis, I would like to move the code to MediaWiki:Gadget-featured-articles-links.js (and its CSS to MediaWiki:Gadget-featured-articles-links.css?), make it translateable, and import that JS file from each other wiki where the feature is used (as happens with HotCat, for example). What do you think? Helder.wiki 13:46, 26 July 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. --Nemo 17: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.wiki 18: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)
@Bene*: Until that is available, I'll import the gadget code from wikis where the feature is still brokenm as I did on bi:MediaWiki:Common.js. Will the Wikidata version set a title attribute too? Helder 13:42, 3 August 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)
Bene* so far that (biwiki) is the only one, but I can indicate this info in the list on meta-wiki. Helder 01:10, 4 August 2014 (UTC)
Thank you, that would be great. -- Bene* (talk) 20:14, 5 August 2014 (UTC)
 Done I just removed the code from MediaWiki:Common.js and enabled the gadget version. Helder 15:35, 8 August 2014 (UTC)

@Helder.wiki: What about the images used here? Will it be possible to use other ones in other Wikipedias? Or the old code from Common/Vector/Monobook.css etc. will work? --Edgars2007 (talk/contribs) 23:36, 16 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. Helder 23:54, 16 August 2014 (UTC)

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)

This will require a change to {{Link FL}} as well, since now it uses -fa instead of -fl. See also the section #Global gadget for LinkFA. Helder 16:04, 2 August 2014 (UTC)
Helder it's not a very big problem changing {{Link FL}}. But can't this be changed? I mean can't fl be added to the mediawiki page?--Pratyya (Hello!) 13:10, 3 August 2014 (UTC)
Helder Do you think that Template:Link FL really works after adding "-fl" there? I believe to do that you need to change the MediaWiki:Commons.js first, then it can be changed. --Pratyya (Hello!) 13:34, 6 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:
  • Use the current version of the gadgetDone
  • Change the "id" in the template
  • Define the style for the class .FL used in the links (similar to what is currently done for .FA and .GA on MediaWiki:Gadget-featured-articles-links.css)
Helder 13:43, 6 August 2014 (UTC)

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)

@Bene*: What will be the change? Helder 20: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)

Protected edit request on 20 September 2014: MediaWiki:Common.js/IEFixes.js

Since JavaScript has already been disabled for IE 7 and below (gerrit:157774), could we remove else if ( profile.versionNumber <= 7 ) branch? Chmarkine (talk) 04:05, 20 September 2014 (UTC)

 Done. -- [[User:Edokter]] {{talk}} 21:32, 20 September 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)
IE11 prints properly at the moment. Disable it and I will see what happens.  Gadget850 talk 00:06, 22 September 2014 (UTC)
The second and third CSS rules were added by TheDJ in this change and this change. A past discussion on the third bug is here. @TheDJ: Are these CSS rules needed for IE11? Chmarkine (talk) 00:12, 22 September 2014 (UTC)
OK, I think the zoom fix can be removed too, since the "has layout" property has been removed in IE8 (source). Chmarkine (talk) 01:40, 22 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)

Protected edit request on 21 September 2014: MediaWiki:Common.js/secure new.js

I want to remove these domains from Line 35:

Chmarkine (talk) 02:48, 22 September 2014 (UTC)

Also the sub === 'shop' on Line 29 can be removed now. See bugzilla:37790#c9. Chmarkine (talk) 03:44, 22 September 2014 (UTC)
 Done, thanks! Legoktm (talk) 06:13, 22 September 2014 (UTC)
Pinging TheDJ to determine if this script can be retired. -- [[User:Edokter]] {{talk}} 06:19, 22 September 2014 (UTC)
TheDJ? Helder 20:20, 4 October 2014 (UTC)
After receiving some unjustified negative feedback, TheDJ has left the building. If you urgently want to attract their attention, try Special:EmailUser/TheDJ; otherwise, post at mw:User talk:TheDJ or m:User talk:TheDJ, possibly: c:User talk:TheDJ; nl:Overleg gebruiker:TheDJ; d:User talk:TheDJ. --Redrose64 (talk) 18:06, 5 October 2014 (UTC)
Pinged him on mw:User talk:TheDJ. -- [[User:Edokter]] {{talk}} 17:37, 16 October 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)
Right. That's why we need this turned back on. Jackmcbarn (talk) 16:14, 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)
I don't think it shoud go back into Common.js, perhaps as an alternative, it could be made into a gadget. -- WOSlinker (talk) 13:14, 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. Helder 18: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)

Passing comment

(for secure new.js)

var m, main, sub, page, query;

if (m = href.match(re1)) {

// could be changed to

var m = href.match(re1), main, sub, page, query;

if (m) {

// if that would be clearer. —PC-XT+ 17:00, 22 September 2014 (UTC)

Replacing Wikiminiatlas.js with OSM.js

Magnus Manske has written a replacement for Wikiminiatlas.js called OSM.js. It is a much nicer map interface as you can see by going to es:Los Barrios and clicking "mapa" in the upper-right corner. Can we switch to it? MoreTomorrow (talk) 01:03, 14 February 2015 (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)

Proposal to add a switcher

I'd like to propose that we add the code from User:Jackmcbarn/switcher.js to MediaWiki:Common.js. You can see a demo of it at User:Jackmcbarn/switcher, and one use case for it is described at Wikipedia talk:WikiProject Architecture#Template:Infobox building maps. There's precedent for this sort of code in the similar createCollapseButtons() function, and other Wikipedias (like frwiki, example) already run similar code. Jackmcbarn (talk) 15:01, 10 October 2014 (UTC)

Jackmcbarn, I have added the linked example to your statement. Note that the proposal is the fruit of a discussion at Wikipedia_talk:WikiProject_Architecture#Template:Infobox_building_maps. The primary discussants there were Jackmcbarn, myself, Frietjes and Denimadept. Elekhh also commented there briefly and the conversation there was the suggestion of Dr. Blofeld and Frietjes following my inquiries on their user talk pages. I SUPPORT this proposal.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 15:30, 10 October 2014 (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. Helder 16:12, 10 October 2014 (UTC)
There's no way to have a gadget be always-on, though. Jackmcbarn (talk) 16:13, 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)
    A gadget can be marked as [default|rights=hidden] at MediaWiki:Gadgets-definition, so that it appears for everyone and no one can disable it using Special:Preferences. That would be one way to modularize this script. – Minh Nguyễn (talk, contribs) 02:38, 16 October 2014 (UTC)
    @Mxn: I tested that in my own wiki and it doesn't work. Jackmcbarn (talk) 02:47, 16 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. --ELEKHHT 01: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 Rex talk 08:04, 11 October 2014 (UTC)
Support as default-enabled gadget, with an appropriate description so users know what it does —PC-XT+ 19:39, 15 October 2014 (UTC)
I think using OSM.js (see below) is a better solution than cluttering up already cluttered infoboxes. MoreTomorrow (talk) 06:35, 20 February 2015 (UTC)
@MoreTomorrow: This does something totally different than OSM.js. Jackmcbarn (talk) 19:29, 1 March 2015 (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)

I undid the edit, so it should work as before. mw.hook() is indeed not mature enough to handle only-once scenarios. -- [[User:Edokter]] {{talk}} 12:30, 20 January 2015 (UTC)

Collapsible buttons broken on ajax preview

@Edokter: TheDJ added that code so that it works for scripts like User:Js/ajaxPreview (now the links do not appear anymore). Helder 00:50, 10 March 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)
It is fired multiple times by design. Helder 18:38, 10 March 2015 (UTC)
The user script was manually redoing the setup before, but that was removed in favor of the hooks. I have made some changes on the test wiki, that should probably fix the behavior that has been observed. —TheDJ (talk • contribs) 19:24, 10 March 2015 (UTC)
ping Edokter or He7d3r —TheDJ (talk • contribs) 18:48, 14 March 2015 (UTC)
 Done. -- [[User:Edokter]] {{talk}} 19:02, 14 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). Helder 21: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)
Yeah, but what if the first th of the table is inside the second tr? In this example the cells c,d,e and f can't be unhidden. Helder 23:41, 14 March 2015 (UTC)
I think that was an accidental change, at least I can't figure out anymore why I would have made it. —TheDJ (talk • contribs) 08:16, 15 March 2015 (UTC)

Proposal to add global JavaScript

There is an ongoing discussion that watchers of this page may be interested in on Proposal to add global JavaScript and add an extra step for new users to get live IRC help. — {{U|Technical 13}} (e • t • c) 19:33, 28 April 2015 (UTC)

Remove MediaWiki:Common.js/file.js

Tracked in Phabricator
Task T8834

Hi (ping TheDJ),

I'd like to know why this script exists? It seems MediaWiki (at least nowadays) provides very similar functionality already.

Here's a screenshot of what File:Example.svg looks like. One line providing links by MediaWiki, and another one produced by MediaWiki:Common.js/file.js: http://i.imgur.com/sU56Czt.png.

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)

I agree, it is completely redundant. -- [[User:Edokter]] {{talk}} 20:44, 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)
btw, this is related to phab:T104486. Thanks Edokter. John Vandenberg (chat) 11:00, 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)
Yup, we simply never got around to removing it after this was implemented in core. —TheDJ (talk • contribs) 12:03, 5 July 2015 (UTC)
For future reference: this was implemented in gerrit:134855, to fix phab:T8834. Helder 18:14, 5 July 2015 (UTC)

Collapsible code cleanup

Tracked in Phabricator
Task T32352
Tracked in Phabricator
Task T71550
Tracked in Phabricator
Task T72762
See also: MediaWiki talk:Common.js/Archive 21 § Protected edit request on 14 March 2014, MediaWiki talk:Common.css/Archive 14 § Add selectors for mediawiki collapsible plugin, MediaWiki talk:Common.js/Archive 20 § Do not create NavFrame buttons if the new class "mw-collapsible" is used, WP:Village pump (technical)/Archive 92 § Deprecation of Collapsible tables and NavFrames, WP:Village pump (technical)/Archive 102 § Flexible collapsing, and Template talk:Navbox § mw-collapsible

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:

  1. .mw-collapsible from core
  2. Collapsible tables (.collapsible)
  3. '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

By slashing a good chuck of Common.js (and some css), we make Wikipedia a good deal faster to load. -- [[User:Edokter]] {{talk}} 10:53, 5 July 2015 (UTC)

I'm in favor. There is also a task for this in Phab. —TheDJ (talk • contribs) 12:05, 5 July 2015 (UTC)
+1. Helder 18:01, 5 July 2015 (UTC)
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.
—Ruud 12:13, 9 July 2015 (UTC)
mw-collapsible works on both, and on lists, and a lot more. —TheDJ (talk • contribs) 13:17, 9 July 2015 (UTC)
Indeed. Helder 22:01, 31 July 2015 (UTC)

AFD closure script is broken

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)

It works fine for me. Kharkiv07 (T) 01:17, 16 September 2015 (UTC)
Thanks. Maybe my computer is at fault. DavidLeighEllis (talk) 01:24, 16 September 2015 (UTC)
@DavidLeighEllis: No, this was Wikipedia:Village pump (technical)/Archive 140#Broken User Scripts, and was temporary. --Redrose64 (talk) 09:44, 16 September 2015 (UTC)

Add toolbar for IPs

In the style of the Dutch Wikipedia (), and as agreed upon here, would somebody implement something along the lines of what I mocked up here (just a translation of the code used on the Dutch Wikipedia). Thanks. Kharkiv07 (T) 18:13, 13 September 2015 (UTC)

 Doing... -- [[User:Edokter]] {{talk}} 19:21, 13 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)
Not possible right now. That is part of phab:T110633. You can list all translations in one JSON blob and use mw.messages.set(). —TheDJ (talk • contribs) 16:17, 15 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)
I filed phabricator:T112724 to track a server-side iteration to this. --MZMcBride (talk) 04:51, 16 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)

Bad mirror protection

What about inserting a piece of code to protect the site against bad mirroring (e.g. like the one in it:voy:MediaWiki:Common.js)? --Andyrom75 (talk) 07:00, 31 August 2015 (UTC)

I renew my suggestion. --Andyrom75 (talk) 06:59, 22 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 :-)
Please let me know, --Andyrom75 (talk) 10:33, 27 September 2015 (UTC)
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)

withModule

Any objections to me adding ?withModule support as in mw:Snippets/Load JS and CSS by URL? Legoktm (talk) 17:38, 13 October 2015 (UTC)

Modules can only be invoked by templates. How would this even work? -- [[User:Edokter]] {{talk}} 19:18, 13 October 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

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)

It is set to deploy tomorrow (december 10). I already made the code conditional. -- [[User:Edokter]] {{talk}} 22:36, 9 December 2015 (UTC)

Collapsing MOS-compliant tables

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 */
var HeaderRow = table.getElementsByTagName( 'tr' )[0];
if ( !HeaderRow ) {
    return;
}
var Header = 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: 

if ( Button.parentNode.parentNode.nodeName.toLowerCase() === 'caption' ) {
    var i = 0;
} else {
    var i = 1;
}

and then change the loop to 

for ( ; i < Rows.length; i++ ) {

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)
@SMcCandlish: This won't work. --Redrose64 (talk) 21:07, 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)
No, you cannot cause a notification by modifying an existing post. It's covered at WP:Echo#Triggering events and see these three edits, individually. --Redrose64 (talk) 13:51, 7 March 2016 (UTC)
Re-ping: Relentlessly  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  00:38, 7 March 2016 (UTC)
Thanks for the ping, SMcCandlish. The abuse is this: 
table.setAttribute( 'id', 'collapsibleTable' + tableIndex );
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)
Such as, for example, the table linked by The Daleks' Master Plan#Doctor Who episode head. --Redrose64 (talk) 00:07, 8 March 2016 (UTC)

Infobox collapsing and moving options

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)

I used to like infoboxes, but their proliferation has gotten a bit absurd ({{Infobox fictional artifact}}, {{Infobox ambulance company}}, {{Infobox Magic: The Gathering player}}). I also hate how no matter how complex and nuanced a subject is, someone will insist that it can be boiled into an infobox. Anyway, thanks for making them easier to hide. Kaldari (talk) 04:44, 8 March 2016 (UTC)

Fix for Windows XP Unicode font rendering

@Edokter and TheDJ: Should we remove the following hack: 

/**
 * Fix for Windows XP Unicode font rendering
 */
if ( navigator.appVersion.search(/windows nt 5/i) !== -1 ) {
    mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' +
                '.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );
}
  • XP + IE6: can't reach Wikipedia because of HTTPS issues.
  • XP + IE7: isn't served Javascript anymore (Help:Internet Explorer).
  • XP + IE8: might still benefit from this, but is an unsupported browser.
  • XP + Chome: Chrome will drop XP support April 2016.
  • XP + Firefox: doesn't need this hack.
  • XP + Opera: see below

Wikimedia traffic statistics from June 2015 OS Browser:

  • XP: 3.88%
  • IE6: 0.25% (today 0%)
  • IE7: 0.63% (XP + Vista)
  • IE8: 1.28% (XP + Vista + Win7)
  • Chrome: 29.20% (all OS'es)
  • Firefox: 10.16% (all OS'es)
  • Opera: 0.47% (all OS'es)

—Ruud 13:01, 25 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. — Dispenser 16:02, 25 March 2016 (UTC)
Let's wait until the TfD is concluded. -- [[User:Edokter]] {{talk}} 16:25, 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
OS family OS Major version View count %age
Windows 7 868756774 23.29%
iOS 9 508433926 13.63%
Other — 417183368 11.18%
Android 4 377281000 10.11%
Android 5 321741918 8.63%
Windows 10 320880388 8.60%
Mac OS X 10 228521486 6.13%
Windows 8.1 211357335 5.67%
Windows XP 94813298 2.54%
iOS 8 82654297 2.22%
Windows 8 41066156 1.10%
iOS 7 35716851 0.96%
Windows Phone 8 32697298 0.88%
Linux — 28230607 0.76%
Windows Vista 25243248 0.68%
Android 6 22777455 0.61%
Android — 21188423 0.57%
Android 2 19362537 0.52%
Windows 98 18204450 0.49%
Chrome OS 7647 12346421 0.33%
Windows CE — 11172571 0.30%
Ubuntu — 9423933 0.25%
iOS 6 6499229 0.17%
iOS 5 4070489 0.11%
BlackBerry OS 10 3454541 0.09%
Mac OS X — 3409944 0.09%
BlackBerry OS 7 2168252 0.06%
Windows — 821651 0.02%
Windows Phone 10 588133 0.02%
Also, note that IE8 doesn't get JavaScript either any more, as of a few months ago. Jdforrester (WMF) (talk) 16:58, 25 March 2016 (UTC)
Is that all sites? Do we also have stats for only en.wiki, to which this issue applies? -- [[User:Edokter]] {{talk}} 17:07, 25 March 2016 (UTC)
@Edokter: Yes, all sites, as I said. I don't have data specific to enwiki, though I'd be very surprised if it was significantly different. Jdforrester (WMF) (talk) 17:46, 25 March 2016 (UTC)
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)
@Jdforrester (WMF): Can you also find out how many people are using (Chrome OR Opera) AND XP (preferably for enwiki)? —Ruud 17:20, 25 March 2016 (UTC)
@Ruud Koot: Sure:
Windows XP client browser breakdown for users of Wikimedia sites by number of page views;
week of 2016-03-06
OS family OS Major version Browser family Browser Major version View count %age
Windows XP Chrome 48 35782447 0.9593%
Windows XP Firefox 44 18254339 0.4894%
Windows XP IE 6 11850466 0.3177%
Windows XP IE 8 7500474 0.2011%
Windows XP IE 7 3946780 0.1058%
Windows XP Chrome 49 3648520 0.0978%
Windows XP Other — 2539410 0.0681%
Windows XP Firefox 45 2395051 0.0642%
Windows XP Opera 35 2322165 0.0623%
Windows XP Firefox 6 2226261 0.0597%
Windows XP Opera 12 2158470 0.0579%
Windows XP Firefox 43 1410874 0.0378%
Windows XP Opera 32 415351 0.0111%
Windows XP Firefox 3 362690 0.0097%
Hope this helps. Jdforrester (WMF) (talk) 17:46, 25 March 2016 (UTC)

Isn't a more future-proof solution to just apply "sans-serif" (or "serif") everywhere? Nemo 10:28, 26 March 2016 (UTC)

That is already the case (in Vector). This is about removing any forced fonts for unicode (and the template). -- [[User:Edokter]] {{talk}} 11:23, 26 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%? —Ruud 20: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)

As Windows XP is no longer supported, I have removed the font declarations. -- [[User:Edokter]] {{talk}} 18:12, 25 April 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)
I'm referring to XP, as in "As Windows XP is no longer supported". I use Firefox mostly, sometimes Opera. --Redrose64 (talk) 22:42, 25 April 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_21&oldid=1109432137"