Jump to content

MediaWiki talk:Common.js/Archive 19

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

Add new features to show/hide content based on user's groups?

Note: This discussion was moved from here to hopefully receive more input.

What do you guys think of creating CSS classes that can be used by editors to show/hide content based on a user's groups? For instance, I am a member of the "autoreviewer", "reviewer", "rollbacker", "user", and "autoconfirmed" groups. There are some templates, such as {{Invitation to edit}}, that could take advantage of this by only showing the template to anonymous editors. The first discussion that I saw mentioning this was by User:MSGJ, in a discussion that was six months ago, and then it was brought up again today. If you guys want an idea of how this might work, then install this script, and then wrap any code in <div class="for-sysop-only">Text goes here</div>. The class can use any existing group, which are all listed at the top of the script, with "anonymous" and "user" added as well, since they aren't explicitly defined by MediaWiki. You can also use <div class="not-for-sysop">Text goes here</div> as well. Both examples should be self-explanatory by their class names. Thoughts on integrating this or a variant in MediaWiki:Common.js? Wikipedia:Upload already has custom code written for it in Common.js that shows different content for logged-in/out users. Gary King (talk · scripts) 20:28, 2 February 2011 (UTC)

Vandalism that only shows up for non-logged-in users? Anomie⚔ 21:58, 2 February 2011 (UTC)
Perhaps hidden content could be marked with an icon? Or just tag anonymous edits including these classes. It could also be a gadget for those who want to hide templates such as {{Invitation to edit}}, so then by default nothing is changed. Gary King (talk · scripts) 22:26, 2 February 2011 (UTC)

There already is a way to show content just for just sysops and accountcreators. class sysop-show and class accountcreator-show. Just make whatever you want to hide for other users as "display: none". P.S. autoconfirmed is not a 'real' group, it is more like the status of an account. —TheDJ (talk • contribs) 13:43, 6 February 2011 (UTC)

If this were to be implemented, then it's more than likely that those classes would be merged with this script. Also, autoconfirmed is included in wgUserGroups, anyway, so it's treated as just another group. It could perhaps come in handy in some cases. Gary King (talk · scripts) 19:03, 7 February 2011 (UTC)

RfC to change MediaWiki:Common.js for archived citations at Wikiwix

Based on the conversation here, I started an RfC to achive websites at Wikiwix, which requires modifying MediaWiki:Common.js. As this is a major change to Wikipedia, I am posting this information in several places to make certain everybody is notified. Thanks. - Hydroxonium (H3O+) 15:16, 11 February 2011 (UTC)

edit.js

  1. Is the "Turn on spellchecking" code still needed? bugzilla:21604 was patched in 2009.
  2. Is it safe to replace all instances of addOnloadHook with $ without breakage? — Edokter (talk) — 22:21, 23 February 2011 (UTC)
  1. Doesn't look like it. Probably safe to remove now.
  2. Should be. The only potential problem I know of is if a function has to load before or after another function that hasn't been updated yet, i.e. it can affect the load order. Otherwise, shouldn't cause any breakage. Kaldari (talk) 01:23, 24 February 2011 (UTC)
Comment: since runOnloadHook used to be called at the end of HTML page I think the closest behaviour is just to call the scripts directly (no addOnloadHook and no $). At least that's what I do in my scripts now. — AlexSm 00:54, 1 March 2011 (UTC)
runOnloadHook was litterly called at the end of the document. jQuery/$ does the same but without actually having such a call in the document. Currently in 1.17 with the current version of the ResourceLoader most scripts are loaded on the bottom of the page, thus waiting for $(document).ready( myFunc ) or just myFunc() is almost the same, however, to avoid possible future breakage please do not assume or depend on loading order. if you script needs the document to be ready, call it as such. That will save you trouble in the future and also make the code easier to understand/move/update/etc. Krinkle (talk) 07:40, 1 March 2011 (UTC)
I might switch to using .ready just to avoid possible breakage in the future, but on the other hand it looks like this would make my scripts to wait for other external scripts to load which is sometimes annoying due to the (sometimes slow) geonotice script. Looks like this was also discussed in mediazilla:27620. — AlexSm 17:47, 1 March 2011 (UTC)

Hiding subtitle div on editing page

The siteSub div serves no purpose on the editing pages and just adds lots of extra space above the editing box. I would like to add the following to MediaWiki:Common.js/edit.js: 

mw.util.addCSS( '#siteSub { display:none; }' );

I've also created T29669 for removing them at the code level. Kaldari (talk) 23:10, 23 February 2011 (UTC)

This is fixed in MediaWiki code now, although I have no idea when it will get deployed. Kaldari (talk) 18:54, 3 April 2011 (UTC)

Is this only compatible with mediaWiki 1.17? The addPortletLink in the first line seems to be causing some errors for me in 1.16, detectable in Chrome. Basically it has an effect which causes some links to not be created properly. —Preceding unsigned comment added by 69.108.238.135 (talk) 10:12, 7 March 2011 (UTC)

What errors are you getting? This function is compatible with older versions of MediaWiki. It's actually being deprecated in favor of mw.util.addPortletLink I believe. Gary King (talk · scripts) 17:28, 7 March 2011 (UTC)

MediaWiki:Common.js/IE60Fixes.js

This file contains the PngFix script for IE6, and I found out it does not work with the Vector skin. Is there a way to fix this, or shall we retire this script? — Edokter (talk) — 12:11, 26 March 2011 (UTC)

I see no reason why it shouldn't be fixable. Problem is finding people with IE 6 :D —TheDJ (talk • contribs) 13:05, 26 March 2011 (UTC)
You found one :) What do you need to know? — Edokter (talk) — 13:58, 26 March 2011 (UTC)
OK, I tried to find out what's wrong; I get a generic error 'Object expected' on line 25 of an unidentified script. Basically, none of the javascript is working in Vector (monobook is OK). With '?debug=yes' however, the scripts suddenly work again. So it's possibly something in the resource loader that IE6 doesn't like. — Edokter (talk) — 14:32, 26 March 2011 (UTC)
I have IE9 in Windows 7 and IE6, 7 and 8 loaded through Virtual PC. The latest browser report shows MSIE 6.0 at 3.65%. Using IE6, I have looked at a few PNG images, but I don't see the issue. ---— Gadget850 (Ed) talk 02:44, 27 March 2011 (UTC)
May be a local problem then, caused by a user-script. — Edokter (talk) — 10:34, 27 March 2011 (UTC)

edit.js on Special:Upload

Is there any reason that we're loading all of Common.js/edit.js on Special:Upload? I can't see any point to this, as none of the functions in edit.js do anything meaningful within the context of Special:Upload. Unless someone knows the reason behind this, I'd like to remove Special:Upload from the if statement. Kaldari (talk) 18:53, 3 April 2011 (UTC)

It calls MediaWiki:Edittools.js. — AlexSm 17:15, 4 April 2011 (UTC)
Could we just call Edittools.js directly for Special:Upload instead of loading all of Common.js/edit.js? Kaldari (talk) 20:38, 13 April 2011 (UTC)
"We" could, the problem is, nobody else seems to care about these things. Another example is the code "Extra toolbar options" in MediaWiki:Common.js/edit.js which is useless for most editors (who use new toolbar). — AlexSm 16:42, 20 April 2011 (UTC)

Small text custom button

The graphic for the Small Text custom button makes no sense. It's the same as the superscript button just with a bigger 'x'. How is that supposed to represent 'small text'? Kaldari (talk) 21:39, 15 April 2011 (UTC)

Yeah it doesn't represent small at all. Although I suspect most people are using the new toolbar by now, mostly because they are forced to. Personally I'm not using any toolbar at all so I didn't notice this until you mentioned it. I disabled the toolbar a year or two ago, and I don't think there was a small button back then? I assume it was added recently and since it needed an image, someone just modified an existing one. Gary King (talk · scripts) 18:23, 16 April 2011 (UTC)
Is there really even a need for the small text custom button? We don't have a large text custom button, and I can't think of any cases in which it would be useful for editing wikitext. It seems like cruft to me. Kaldari (talk) 19:44, 16 April 2011 (UTC)
Where is the page that controls the buttons? Gary King (talk · scripts) 03:58, 17 April 2011 (UTC)
MediaWiki:Common.js/edit.js Kaldari (talk) 05:37, 17 April 2011 (UTC)
Small was apparently already in the first revision. Gary King (talk · scripts) 07:26, 17 April 2011 (UTC)

Map toggle for geolocation in infobox

I have brought this question here after getting a little advice on VPT, [1]. I will repeat the inquiry and then add additonal questions.

On the French wikipedia page fr:Longford and many others using that infobox, there is a map within the infobox which can be toggled via a link beneath it, administrative to topographique. On the French site, I see that the infobox fr:Modèle:Infobox Ville d'Irlande gets the maps from fr:Modèle:Infobox/Géolocalisation multiple, which uses the custom ".img_toogle ul" CSS class.

It has been explained to me that the script lies in fr:MediaWiki:Common.js as * Script pour alterner entre plusieurs cartes de géolocalisation. To continue the discussion, I would first like to say that I think the feature as enabled for maps is very useful, there are also other "before and after" uses for images that I can envision. It seems there is a CSS class that is also required for it to work on the French site; I am not seeing any advantage to my own hit or miss investigation of this and would like to know what editors of the script here have to say about it. Would it be a major change, major pain, etc. to include this functionality? Is there some advantage to adding it instead to the entire MW suite as an extension, as for example mw:Extension:Imagemap was added by Tim Starling? I would prefer not to wait for a full upgrade of the software so I assume this is the place to propose adding toggle of maps to infoboxes via this French method. Please I would like to hear from a few people if possible regarding such an addition of functionality. Thank you, Sswonk (talk) 22:16, 23 April 2011 (UTC)

This is easy added via js (I doubt an extension is warranted). (As an aside, frwp has some nice custom js/css in general.) I suspect that this js would be quite flexible if adapted for use here—click a link to show something, and click it again to show the original thing. People would go crazy with it on userpages. IMO, it's not a big deal and I wouldn't mind adding this js to enwp if it's not abused, but let's see what the community thinks. /ƒETCHCOMMS/ 19:13, 24 April 2011 (UTC)

Location of Common.js on the file server

Does this file live in the root of the Wiki? AGrobler (talk) 12:09, 13 April 2011 (UTC)

No. Amalthea 13:01, 13 April 2011 (UTC)
To be more precise: it lives in the database. — Edokter (talk) — 14:37, 13 April 2011 (UTC)
Thanks, I'll have a look! AGrobler (talk) 10:55, 12 May 2011 (UTC)

Edit summary dropdown of common summaries, via Javascript

I'm thinking someone watching this page might be able to answer the question I've asked at Wikipedia:Village_pump_(proposals)#Now_what. Anyone? Rd232 talk 23:47, 5 May 2011 (UTC)

secure.js and Etherpad domains

MediaWiki:Common.js/secure.js needs exemptions for the domains etherpad.wikimedia.org and eiximenis.wikimedia.org. Examples of currently broken links are at [2] and [3].

Regards, HaeB (talk) 22:39, 20 May 2011 (UTC)

And another one: static.wikipedia.org. (An example of a currently broken link is at [4].) Regards, HaeB (talk) 15:24, 21 May 2011 (UTC)
done —TheDJ (talk • contribs) 22:16, 3 June 2011 (UTC)

Unacceptable performance impact

It is unacceptable for the perforance impact [5] has on a user's browser let alone our server farm to serving two 404 pages per page. The summaries should be more descript and not just a URL to a discussion without a beginning. In any case the effect can done with {{DISPLAYTITLE:<span style="display:none;">{{FULLPAGENAME}}</span>}} (it's already a template too). — Dispenser 22:18, 3 June 2011 (UTC)

TheDJ already reverted it. — Edokter (talk) — 22:25, 3 June 2011 (UTC)
Yeah, not the best idea indeed. If they just want to hide the title on a limited set of pages, Dispenser's suggestion is probably best. If they need more CSS for a 'set' of pages, they can give those pages the same prefix, and we can add a conditional loader based on pagename prefix, to load something like MediaWiki:Common.css/ACP.css. But above all, discuss the ideas before implementing them, because this page is way to critical to just slam your random ideas into it. —TheDJ (talk • contribs) 22:41, 3 June 2011 (UTC)
Sorry about that. My bad. I shoud have checked for more subpages. But I am glad you had a solution to the problem. I actually looked around on my own and asked around among some of the staff, and they did not know about that template. But it may be the easiest way to solve this.//Hannibal (talk) 22:45, 3 June 2011 (UTC)
If you need something that cannot be done with local CSS on a page, and more so when you need JS, then please come here, explain what you want to do and the guys watching this page can help make it true. This is our biggest wiki, and there is lots of experience here with making 'hacks' as efficient and unobtrusive as possible, but it is also one wiki, where such hacks really do need to be as unobtrusive as possible. Just ask —TheDJ (talk • contribs) 22:51, 3 June 2011 (UTC)
Thank you for the offer. For the moment, this is the only thing that I need help with, but I will definitely come back.//Hannibal (talk) 23:02, 3 June 2011 (UTC)

How to use?

Where do I put this on my own wiki? Anywhere? -B1KWikis (talk) 20:44, 7 June 2011 (UTC)

Nevermind, I checked for the page "MediaWiki:Common.js" and there was a message there that said the changes apply to all users, indicating that I used the right page -B1KWikis (talk) 20:56, 7 June 2011 (UTC)

IE6 seriously broken

I've been playing with my old PC running W2K/IE6, only to notice it refuses to run any javascript, regardless of skin or login status. Only when I do a CTRL-F5 to fully reload a page, do all scripts run. Any other time, the error "mw.util.addPortletLink is null or not defined" is given and all scripts are aborted.

I seriously think the first line in Common.js is to blame: window.addPortletLink = mw.util.addPortletLink;

Is this line really necessary, or can it be removed and let wikibits handle old calls? — Edokter (talk) — 15:11, 11 June 2011 (UTC)

Removing the line only results in the next instance on 'mw.util' throwing an error. If we want to keep IE6 supported, we need to find out a way to guarantee that mw.utils is loaded first. Otherwise, we may as well ditch all IE6 related javascript, because there really is no point in having javascript that keeps crashing. — Edokter (talk) — 16:57, 11 June 2011 (UTC)
Per Wikimedia Analytics - User Agent Breakdown by Browser IE6 use is now under 3%. At what point do we drop support? ---— Gadget850 (Ed) talk 01:19, 12 June 2011 (UTC)
Usually below 1% as I understand it. However, this also blocks user scripts, so investigating this may be warranted. — Edokter (talk) — 01:20, 12 June 2011 (UTC)
Some further investigating reveals the trouble started with this edit by Krinkle. Obviously, no impact analysis was done. I don't know what the core cause is; it could be resourceloader, but Monobook is also affected (which does not use it). Since a hard reload does work, but normal loading does not, it must be a dependency issue, but I have no idea how to trace this. At this point, I am inclined to revert the migration to mw.utils until IE6 really drops below 1%. — Edokter (talk) — 01:29, 12 June 2011 (UTC)
This has worked in the past and if it doesn't, then there is an issue that needs to be solved. Your assessment that no impact analysis was done is false btw. Do you have mwEmbed enabled perhaps ? I've personally had a lot of issues with that thing enabled. —TheDJ (talk • contribs) 14:41, 12 June 2011 (UTC)
No, I don't have mwEmbed enabled. I tend to stay away from beta scripts. — Edokter (talk) — 15:13, 12 June 2011 (UTC)
(edit conflict) Hi,
When 1.17 was first deployed and ResourceLoader 1.0 made it's introduction (for which I didn't develop the loader), it was way beyond testing whether mw.util is correctly loaded on wiki.riteme.site, reason being that this was tested before deployment (as we always do). I also know for sure that the load order was correct at that point (even for IE6, even on wiki.riteme.site).
As you may or may not know, aside from major releases (such as 1.17) there are smaller deloyments almost every week, so it may very well be that due to some change somewhere by someone this somehow broke for IE6. I know I didn't change anything in ResourceLoader's loader structure recently that was deployed.
The edit to Common.js you are referring to does indeed make use of mw.util, I was doing so because both from documentation and personal experience I know the utilities are loaded before the site scripts. There is a certain abstraction point at which things should not require testing in every browser in the planet, simply because it's known to work. The loader order is one of those things.
The first line you are referring to may trigger an issue, but it's certainly not the cause. And there's a fair chance removing that (or even removing mw.util entirely from Common.js) wil not fix but simply move the issue to some other place it's referred to. If in IE6 mw.util is not loaded before the site scripts, please open a bug in bugzilla: and make sure you include steps to reproduce and set priority to High.
Thanks in advance, Krinkle (talk) 14:54, 12 June 2011 (UTC)
The only way to know for sure is to disbale/revert all calls to mw.utils temporarely. Would it be OK to do so? This should not break any functionality. — Edokter (talk) — 15:13, 12 June 2011 (UTC)
I think we should just forget about MSIE6 (and other old browsers). --Locos epraix ~ Beastepraix 20:57, 12 June 2011 (UTC)
Sometimes when I break one of my userscripts and I look in the error console of my browser the reported errors are not from my scripts but, instead, from js included by MediaWiki itself. So I think it is possible that the same think may be happening, and you are getting errors from mw.util. Last time I had to deal with something like this, I looked in the Call stack of Google Chrome Developer Tools and noticed that, although the error was happening when one line of the MW files was executed, the real problem was in one of my function calls to functions in those files and when I fixed my user script the problem stopped.
I'm not sure about what I'm going to say, but isn't the code "window.addPortletLink = mw.util.addPortletLink;" executed as soon as MediaWiki:Common.js is loaded? Would the same happen if the code was changed to something like
window.addPortletLink = function ( params ) { return mw.util.addPortletLink ( params ) };
If I understood correctly this way mw.util would only be used when someone calls "window.addPortletLink", which I think usually happens after "$(document).read()" (and maybe at that time the mw.util will be already loaded, and there will be no errors). Helder 21:04, 12 June 2011 (UTC)
Sounds like a good idea. One thing i don't understand... wasn't addPortletLink a core wikibits function ? I can see why it would be deprecated, but i'm lost on why it would not be defined anymore... —TheDJ (talk • contribs) 21:31, 12 June 2011 (UTC)
It is still defined; wikibits is fully operational. Krinkle just deemed it deprecated and replaced all calls to wikibits with mw.util calls, and remapped what was left. — Edokter (talk) — 21:37, 12 June 2011 (UTC)
It is not 'deemed' deprecated by Krinkle, it IS deprecated. —TheDJ (talk • contribs) 21:39, 12 June 2011 (UTC)
And yet we still need it in the painfull absence of a importScript replacement... — Edokter (talk) — 22:00, 12 June 2011 (UTC)

And IE6 IS deprecated :) →AzaToth 21:43, 12 June 2011 (UTC)

I ment that he deemed wikibits deprecated. While that may be, it is still fully operational. — Edokter (talk) — 21:45, 12 June 2011 (UTC)
Let me explain what "deprecated" means in software development. It means that a certain method is redundant or superseeded and is soon to be removed. It also means that it still works like it did before, else it would be "removed" not "deprecated". Wikibits is deprecated in favour of the mediawiki.js library. Depending on how smooth the transition goes, wikibits will either be removed or quarantined in a future version of MediaWiki. Krinkle (talk) 15:14, 13 June 2011 (UTC)
Edokter, can you test what happens on test wiki ? I replaced the Common.js there with our version minus the addportletlink bit. —TheDJ (talk • contribs) 21:41, 12 June 2011 (UTC)
Booting my old machine... — Edokter (talk) — 21:45, 12 June 2011 (UTC)
First load and CTRL-F5 load OK, normal reload and page clicks give "Object expected" (same as here). — Edokter (talk) — 21:56, 12 June 2011 (UTC)
Same problems on nl.wiki and Commons. — Edokter (talk) — 22:40, 12 June 2011 (UTC)

Kill it?

Personally, I have no interest in IE6 anymore. But it's use is still above 1%, which is the threshold for support (I forgot where I read that; meta? mediawiki?). The browser is now 10 years old, and if support is dropped, it should be official somehow. I am going to disable MediaWiki:Common.js/IE60Fixes.js; it is no longer functional after all. — Edokter (talk) — 22:40, 12 June 2011 (UTC)

Actually, that won't make a difference as fixalpha has been in MediaWiki for for a while (as are other IEFixes). This script was copied from wiki.riteme.site to other wikis, and somehow made it's way back here meanwhile it's been integrated into core. So fixalpha is in MediaWiki core and is loaded for IE6, and should be removed from en.wikipedia's scripts either way.
Aside from that, I think browser support is something the developers team and/or the foundation should decide, not the community of wiki.riteme.site Krinkle (talk) 15:03, 13 June 2011 (UTC)
I should note that the two scripts aren't the same tho. The one on wiki.riteme.site loops through all document images, whereas the core fix is just a simple fix for the logo. Krinkle (talk) 15:09, 13 June 2011 (UTC)
I know, I wrote the script. Note that even fixalpha is broken now. — Edokter (talk) — 15:17, 13 June 2011 (UTC)

Bug filed

I filed a bug, explaining the situation and asking wether IE6 should still be supported under Bugzilla:29384. Trevor promptly changed the title to "mw.util loads too late in IE6", so I believe there may still be a solution. — Edokter (talk) — 21:15, 13 June 2011 (UTC)

Vector Toolbar : "search and replace" gizmo

Hi guys, i need a little help please I'm trying to find the .js of the Search and Replace button in the advanced part of the vector toolbar. Any idea where i could find it ? --Lilyu (talk) 07:10, 16 June 2011 (UTC)

Do you mean this? Helder 18:10, 16 June 2011 (UTC)
Thank you very much :) Lilyu (talk) 05:00, 17 June 2011 (UTC)

Unhiding text

Hello,

In the Account Creation Improvement tests, we have hidden the name of the MediaWiki pages that we are using. However, I have managed to hide too much of the title of the page. If you for instance look at MediaWiki:Customusertemplate-ACP2-welcomecreation it doesn't say that you should pick the subject you are most interested in, since the code says display:none. This makes it harder for newcomers to understand what they are supposed to do. Now, my question is if there is an easy way to write anything you want using that code, or if there is another way of solving that problem.

I have previously asked User:Fetchcomms about this on his talk page and he recommended me asking the same thing here. Any ideas?//Hannibal (talk) 22:43, 20 June 2011 (UTC)

Not sure I understand you. I sure see a blue box, instructing me: "Let us know what you are interested in so we can suggest how you can help make Wikipedia better." See screenshot. What's missing for you? Amalthea 22:54, 20 June 2011 (UTC)
The title of the page. This page, for instance has MediaWiki talk:Common.js right below the tabs for system message and system message talk and above "From Wikipedia". For instance in this image the title is "Main page". Any help is greatly appreciated.//Hannibal (talk) 23:56, 20 June 2011 (UTC)
Well, I don't get what you want done. The text you said was missing initially ("it doesn't say that you should pick the subject you are most interested in") is visible. The title of the page, "MediaWiki:Customusertemplate-ACP2-welcomecreation", is of course missing, you are explicitly hiding it with {{DISPLAYTITLE:<span style="display:none;">{{FULLPAGENAME}}</span>}}. Amalthea 07:37, 21 June 2011 (UTC)
I'll try to be even clearer. Yes, the title is hidden. But I would like to change the title instead of hiding it, so instead of either the full name ("MediaWiki:Customusertemplate-ACP2-welcomecreation") or nothing, it will say "Which topic are you most interested in?" or something like that. The blue box of course contains some additional comments on this, but it's not that visible, and is placed to the side. I have tried a few ways of changing the display:none, but so far I have been unable to make an edit that changes the text. I can remove the code that hides the title, but that's not what I want, since the full name confuses people. Better to change it into a short declarative sentence.//Hannibal (talk) 10:37, 21 June 2011 (UTC)
That is not possible using DISPLAYTITLE; it will let you change the appearance (including hiding parts), but not the content of the page title. What you could do is simply put a H1 header at the top of the page ( =Which topic are you most interested in?= ). — Edokter (talk) — 12:03, 21 June 2011 (UTC)
Okay. Thanks, Edokter. I will go through the pages and edit them shortly.//Hannibal (talk) 16:01, 21 June 2011 (UTC)

Collapsible tables

I've updated the Collapsible tables script to no longer use the deprecated hasClass function (in favor of jQuery().hasClass). My changed version can be found at sco wiki's common.js. Though I technically could I haven't applied this here, it would be fine if an admin could do that or give me the allowance to do it - Hoo man (talk) 18:49, 21 June 2011 (UTC)

I don't know if that is worth it, since the whole collapsing code is soon to be deprecated as well, in favor of jQuery. — Edokter (talk) — 18:56, 21 June 2011 (UTC)
Deprecating the native JavaScript for table-collapsing seems reasonable enough. Is there a copy of the jQuery code that will supersede that old code? I would like to experiment around with some changes to this module. Thanks, Emw (talk) 17:23, 9 July 2011 (UTC)
Take a look at meta:User_talk:Krinkle/1-17-allwikis#Wikis_using_jquery.makeCollapsible. Helder 19:21, 9 July 2011 (UTC)
Thanks for the link. What remains to be done in order to replace the native JavaScript functions for collapsible tables with the new jQuery implementation? If I'm not mistaken, the JS and CSS files needed (MediaWiki:JQuery-makeCollapsible.js and MediaWiki:JQuery-makeCollapsible.css) are deployed live on en-wp. Emw (talk) 16:19, 13 July 2011 (UTC)
Hmm... indeed.
You can try to start testing on the sandboxes of some templates which uses "collapsible things" (examples from Portuguese Wikibooks: here and here). There are some examples on this page on test Wikipedia and also on mw:ResourceLoader/Default_modules#jQuery.makeCollapsible. Helder 20:05, 13 July 2011 (UTC)

Feature request: Live countdown clock

A while back I found a nifty piece of javascript that created a live countdown clock (i.e. as you stared at it, the seconds counted down).

The full code, as I ripped it from Skyrim Wikia, is at User:Sven_Manguard/Sandbox/4. For a view of it in action, it is right above the "About" box at the main page of that Wikia.

Currently there is a non-live countdown clock, which displays how much time is left as of when the page was loaded, and can be refreshed, but it's less useful in my opinion. That code, in case anyone is wondering, is at Template:countdown.

When I floated this at #mediawiki, I was told to mention the failover for this code. The failover, which I tested at the Skyrim Wikia, is that the countdown line just disappears. All of the text below it moves up accordingly as if that line did not exist. Everything else at that site functioned properly.

One more thing. The code may have been updated from when I copied it over to my sandbox a few weeks ago. If that's the case, the new code would be somewhere at the Skyrim Wikia Common.js page. I wouldn't be able to tell if any changes were made.

Thoughts? Sven Manguard Wha? 02:08, 22 July 2011 (UTC)

I don't follow this at all. You want to add a countdown clock for all users? Why? What's the occasion? --MZMcBride (talk) 02:14, 22 July 2011 (UTC)
Well I was told that if I added it to my local .js page it wouldn't show up for anyone else. That defeats the purpose of using it anywhere public. As for the occasion, I didn't have one specifically in mind. When there's something that people are waiting for down to the second, such as the time until the ball drops in Times Square for New Years, or the time until something else momentous is supposed to happen (I remember people counting the seconds, on television, until the rescue capsule was supposed to reach the surface during the Chilean mine collapse), it would be nice to have around. Sven Manguard Wha? 02:28, 22 July 2011 (UTC)
Oh, right, I suppose some more explanation is needed. This would work similarly to Template:countdown in that it could be put into various pages for various events, this would not be a site banner or anything.
And one other potential use, I would like to have the live countdown clock (or if not that, the current refresh only countdown clock) somewhere in messages announcing certain votes. In the 2011 ArbCom election there was a good deal of commentary in various forums that essentially said 'We didn't realize how quickly it was going to end/we thought we had more time'. Hopefully a message saying "Voting closes in 1 day, 3 hours, 7 minutes." will spur people to make it to the polls on time.
I'm not saying this is going to become a major feature, but it does have uses. Sven Manguard Wha? 02:36, 22 July 2011 (UTC)

Right. Pages are cached fairly heavily in order to make views less expensive and much faster. A consequence of this caching is that dynamic content (such as the current time) becomes impossible in native wiki-functions. You have to use JavaScript in order to have dynamic content; that way, the content can be stored (static) and the resulting rendering can be dynamic (if the user has JavaScript enabled and active). If you use native wiki-functions, users must purge the page (?action=purge) in order to ensure that they're seeing the newest content.

In this case, I don't see a big use-case for a countdown function. It's certainly not needed in articles, mostly for principled reasons. It might have some uses in the project-space, but this implementation has problems. If the fallback is simply removing the line entirely, imagine this scenario: a banner that says "Voting for the elections ends in 1 day, 2 hours..." If the line simply disappears, the notice won't read anything at all. A saner implementation would be to have a fallback that either relies on the native functions (and caches the output) or that lists the exact date instead ("Voting for the elections ends at 00:01 January 3, 2011"). Supporting users who don't have or can't have or won't have JavaScript enabled and active is important. It's critical in article-space.

Other functions that could be done in JavaScript might be current date/time or a random function. These suffer the same caching problems. I don't have an objection to these features being included, but doing so should be done properly with sane fallbacks. The code should be re-usable for other sites (dozens of people try to replicate Wikipedia each week) and the code should be adaptable to future functions. --MZMcBride (talk) 22:03, 24 July 2011 (UTC)

I'm getting the "this isn't a priority for me" vibe from you here, which is understandable and perfectly acceptable. I would note, however, that I lack the programming knowledge to do any of those things. I merely found this code and brought it over. Heck, I had to have someone explain to me what a failover was before I could test it. Sven Manguard Wha? 00:03, 25 July 2011 (UTC)

secure.js and Toolserver

The Toolserver has HTTPS support now (see tswiki:Web hosting#SSL). Can we add it to the rewrite list? — Dispenser 18:44, 23 July 2011 (UTC)

Questions about mw-customtoggle

After learning from some of the examples of the new mw-collapsible functionality at http://test.wikipedia.org/wiki/User:Krinkle/CollapsingTestpageMw, I partly implemented a table with a custom toggle at http://wiki.riteme.site/w/index.php?title=User_talk:Emw/test&oldid=439920138. Ideally, I would like to use MediaWiki:JQuery-makeCollapsible.js to create a table like the one shown at http://toolserver.org/~emw/mediawiki/innerCollapsible.html#. I have a few questions on how to get there:

  • Is it possible to specify "data-collapsetext" and "data-expandtext" for an mw-customtoggle element?
  • The collapsible rows in my example are collapsed by default. However, they aren't collapsed immediately upon page load: they're visible for a few hundred milliseconds, then fade out. Is there a way to avoid this wait time for the collapsible elements to be hidden upon initial page load?
  • It looks like elements are designated as collapsible only by their ID. And the ID value for each collapsible element has to be included in the class of the custom toggle element. This seems unideal, because either A) the value of the custom toggle's class attribute could get very long for a long list of collapsible elements, assuming each collapsible element has a unique ID; or B) the collapsible elements will need to have the same ID values (as in the example I implemented), which violates the convention that all IDs should be unique. Would it make sense to instead have the collapsible elements designated as such by their class values, and the custom toggle identified by its ID value? This is almost exactly opposite of what's currently done.

Thanks in advance for any help! Emw (talk) 11:55, 6 August 2011 (UTC)

Bug in regular expression

{{editprotected}} The current implementation of withCSS and withJS has the same bug which was corrected on Wikimedia Commons sometime ago: although the current regex matches the desired pages, as in

javascript:alert('MediaWiki:FOO.js'.match("^MediaWiki:[^&<>=%]*\.js$"))

, it is also matching unwanted pages, as in:

javascript:alert('MediaWiki:FOOjs'.match("^MediaWiki:[^&<>=%]*\.js$"))

This can be fixed by changing the code to:

javascript:alert('MediaWiki:FOOjs'.match(/^MediaWiki:[^&<>=%]*\.js$/))

Could someone fix it, please? Helder 19:08, 8 August 2011 (UTC)

Done I fixed them both. Reaper Eternal (talk) 19:46, 8 August 2011 (UTC)

"Snakes"

I've removed the whole "interested in snakes" boilerplate text, which was being left unaltered by new editors, leading to exactly the same text being inserted into hundreds of user pages, clearly unread by those users, or anyone else. See WP:AN/I for the discussion leading to this change. -- The Anome (talk) 18:06, 17 September 2011 (UTC)

Global JS message for some public tools

I have some "standalone" JavaScript tools that make api requests and then display the results and they are available for everyone on my home wiki using withjs= URL parameter (here: ru:ВП:Скрипты, bad automatic translation).

I would like to "publish" them on English Wikipedia. The first ones would be

Question: would it be possible to create a system message eg. MediaWiki:Tools/user-js.js or MediaWiki-script-user-js.js (or any other name) with 

if( wgPageName == 'User:Js' ) importScript('User:Js/tools.js');

User:js is my secondary account. I have sysop flag in Russian Wikipedia since 2007.

— AlexSm 20:06, 26 September 2011 (UTC)

There should be no possibility to run unrestricted javascript by simply pointing to a url (ie. withJS=MediaWiki:Foo.js including User:Foo/bar.js is just as insecure as withJS=User:Foo/bar.js). English Wikipedia already has support for the withJS parameter. If anything, the script itself (not a link to it) can be copied to a page in the MediaWiki:-namespace. If you would like that to happen, please say which script should be copied where. Krinkle (talk) 21:51, 27 September 2011 (UTC)
What I requested is not the same as running any user script. Could you please elaborate what makes my script "unrestricted" compared to Gadget-wikEd.js or Gadget-GoogleTrans.js or the old Gadget-refToolbar.js? Would it still be "unrestricted" if it was located in MediaWiki namespace on my home wiki like Gadget-HotCat.js or Gadget-modrollback.js or Gadget-revisionjumper.js? — AlexSm 04:23, 28 September 2011 (UTC)

Hi,

The MediaWiki:Common.js/secure.js aim is to stay in HTTPS for all links of wikimedia sites.

But there is a problem with international inter-site links like b:fr:User:DavidL because the generated link is https://secure.wikimedia.org/wikibooks/en/wiki/fr:User:DavidL which is a HTTP (not HTTPS) redirection to http://secure.wikimedia.org/wikibooks/fr/wiki/User:DavidL.

I have created a similar script (which is currently a gadget) b:fr:MediaWiki:Gadget-FixLinks.js which doesn't have the problem.

I propose the following correction:

  • Insert the following lines:
// Avoid unsecure redirection
//   /YY/wiki/XX:page -> /XX/wiki/page
var m = page.indexOf(':');
if (page.substring(0,6)=='/wiki/' && m==8)  //  /wiki/XX:page
{
    sub = pagepath.substring(6,m);                   //  XX
    page = page.substring(0,6)+page.substring(m+1);  //  /wiki/page
}
  • ...just before the line near the end of script:
link.href = wgServer + '/' + main + '/' + sub + page + query;

--DavidL (talk) 13:28, 17 September 2011 (UTC)

Should I make a sysop rights request to do the correction myself ? --DavidL (talk) 10:41, 19 September 2011 (UTC)
Thanks for testing. We don't have namespace shortcut on French wikibooks, so I haven't tested them.
It would be great if inter-project redirections would preserve the protocol. But we will need to keep the secure.js scripts to translate server name (ex: from (lang).(project).org into secure.wikimedia.org/(project)/(lang)).
--DavidL (talk) 10:53, 20 September 2011 (UTC)
Since the last MediaWiki update, the https equivalent of http server is now the same. So the MediaWiki:Common.js/secure.js seems useless. I already have deleted the equivalent script on French wikibooks.
--DavidL (talk) 10:31, 2 October 2011 (UTC)
It's not useless just yet. If you are still using the old server, the script still does it's job. I already added a new script that helps you stay on secure if you are using the new server. —TheDJ (talk • contribs) 10:42, 2 October 2011 (UTC)
That's true for the old secure.wikimedia.org
But as it may disappear, we should not use it anymore and use the new one. So to stay on secure, we only have to use the new https servers.
--DavidL (talk) 13:23, 2 October 2011 (UTC)

Fix of BLP edit notice technical problem

At Wikipedia:Village pump (technical)#Edit notice on BLP articles I requested help with an issue that I believe is important, and I'm sure other regular editors of Biographies of Living Persons would agree. There is an edit notice currently applied automatically to all pages that are categorized as living people, and possibly living people, with the notice informing editors of our BLP policy. The BLP problem is a big one, garnering a lot of bad publicity for Wikipedia, and harming many innocent people who are being attacked in their Wikipedia biography. There are also many instances of editors who have unknowingly added incorrect and hurtful material, without references.

Unfortunately, the edit notice only appears when users click on "edit this page" at the top of the article, and never when they click on the "edit" link to edit a section of an article. Since most users probably edit sections, rather than the entire article, the edit notice is not nearly as effective as it could be.

Below, I've copied the suggestion of one expert, who doesn't have the time to implement it. Thank you for your help. First Light (talk) 23:50, 1 October 2011 (UTC)

Well, I see two ways we can fix this:
1: We could use a for-loop: Currently the code in MediaWiki:Common.js looks for Category:Living people and Category:Possibly living people and if they exist then adds "&editintro=Template:BLP_editintro" to the edit link at the top of the page. This happens when we view the page, before we click the edit link. As far as I can see we can add a for-loop that locates all the section edit links since they are clearly marked with <span class="editsection">, and then add the same "&editintro=Template:BLP_editintro" to all those section edit links.
2: We could use a hidden category and an ajax call: I have noticed that hidden categories are visible on the edit page even if we edit another section than the one that adds the category. So we could add a hidden BLP category to all BLP pages (perhaps automatically by using the infoboxes). Then we can use javascript that runs when we edit the page (not before we edit the page) and checks for that category and then uses an ajax call to render {{BLP editintro}} and inserts it.
I prefer method one above (for-loop) since it is simpler to implement, it costs less server resources, and I am sure it will work. While I don't know enough about ajax coding to even be sure that method two would work. However, my javascript skills are too rusty and I am semi-retired from Wikipedia so you guys need to ask the experts over at MediaWiki talk:Common.js to implement it.
--David Göthberg (talk) 23:21, 1 October 2011 (UTC)
#1 is pretty simple to do with the new jQuery code. Just replace addEditIntro with this:
function addEditIntro( name ) {
  $( '.editsection, #ca-edit' ).find( 'a' ).each( function( i, el ) {
    el.href += '&editintro=' + name;
  });
}
Any objections? Anomie⚔ 01:46, 2 October 2011 (UTC)
I made some performance improvements to the code. — Edokter (talk) — 08:04, 2 October 2011 (UTC)
Done, slightly different, due to relative vs. absolute hrefs, which would cause the https lock to show up on edit section links with these rewriter hrefs otherwise. —TheDJ (talk • contribs) 12:36, 2 October 2011 (UTC)
Thank you, everyone! First Light (talk) 14:54, 2 October 2011 (UTC)
I guess vector never picked up the fix from rev:51457 (to use div#content a.external[href ^="https://"] instead of div#content a[href ^="https://"]), which is why I didn't see the icons when testing in monobook. While the odd spacing reported in T20207 isn't occurring in vector, I see it does have the "disappearing icon" problem when clicking on links like #wikipedia-en. Anomie⚔ 15:53, 2 October 2011 (UTC)
Wow ok. that's old but rev:98690. :D —TheDJ (talk • contribs) 16:52, 2 October 2011 (UTC)

"Swap roles" button for Special:Log

The most obvious way to access a user's block log is by opening the user's talk page, clicking "Logs" in the toolbox, and cutting and pasting the username into the "Title" text box, adding "User:" in front. A bit of JavaScript could avoid the cutting and pasting: 

// "Swap roles" button to make Special:Log much less annoying
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) == 'Log' ) {
    $( '<button>Swap roles</button>').insertAfter( '#mw-log-page' ).click( function(event) {
        var $user = $( '#mw-log-user' ), $page = $( '#mw-log-page' ),
            oldUser = $.trim( $user.val() ), oldPage = /^user:(.+)$/i.exec( $.trim( $page.val() ) );
        $page.val( oldUser ? ( 'User:' + oldUser ) : '' );
        $user.val( oldPage ? oldPage[1] : '' ); 
        event.preventDefault();
    } );
}

It seems so obvious that I am surprised it is not already in MediaWiki or on Wikipedia. PleaseStand (talk) 03:33, 12 October 2011 (UTC)

Have you reported this on bugzilla:? Helder 12:44, 12 October 2011 (UTC)
User block log is available from contribution page as "block log" link under H1. — AlexSm 14:30, 12 October 2011 (UTC)
This seems pretty handy. Maybe could go in a gadget, but I wouldn't be opposed to having it enabled for everyone. It'd be nice if it could be a bit abstracted to not use the English prefix "User:", though. Code re-use is rampant and a million versions of this code (each with a localized version of the prefix) would be less preferable than one. --MZMcBride (talk) 16:17, 12 October 2011 (UTC)
No comment on the code, but I like the idea. Sven Manguard Wha? 17:05, 12 October 2011 (UTC)

MediaWiki:Common.js/IPv6.js

[18:50] <Myra> mark: Is https://wiki.riteme.site/w/index.php?title=MediaWiki:Common.js/IPv6.js still being used? (Can the images be loaded from https?)
[18:54] <mark> we should probably disable that for at least a while
[18:54] <mark> as it hasn't been checked or anything

Please disable the IPv6 code in MediaWiki:Common.js. --MZMcBride (talk) 02:09, 17 October 2011 (UTC)

 Done. — Edokter (talk) — 09:52, 17 October 2011 (UTC)

Execute custom scripts per page

I propose a new feature that would allow running custom scripts depending on the page:

template in wikicode {{ExecuteJS|scriptName}}
would result in HTML <span id="ExecuteJS" class="scriptName" style="display:none" />
and Common.js would call MediaWiki:Script/scriptName.js

To prevent possible abuse only MediaWiki:Script/ * scripts will be allowed and each new script should check if it's called from the correct page(s).

This new feature would actually make Common.js much smaller because it would replace:

  • function uploadwizard_newusers (26 lines of code) for WP:Upload
  • recently added signupuserpagefillmagic (43 lines of code)
  • and possibly the "Main Page layout fixes" as well.

Other possible applications will be mostly limited to "Wikipedia:" namespace where withJS= URL parameter added in February 2010 is not practical to use.

The suggested code is below 

//See [[template:ExecuteJS]]
$(function(){
  var execJS = document.getElementById('executeJS')
  if( ! execJS ) return
  $.each( execJS.className.split(' '), function(i, sc){
    sc = $.trim( sc.replace(/[^\w ]/g,'') );
    if( sc ) importScript('MediaWiki:Script/' + sc + '.js');
  })
})

— AlexSm 17:12, 19 August 2011 (UTC)

Your given examples does not factor in the HTTP overhead and the typically adds 50-200 ms (~2-6 NTSC frames) latency to the compressed and minified code. If implemented, I think that this function should be combined with &withJS= simply to reduce code. Also, something like <span id="runJS" title="MediaWiki:bubbles.js|MediaWiki:Rainbows.js"></span> would be more preferred syntax. — Dispenser 22:57, 29 August 2011 (UTC)
I agree with your points (although space character is used only in 2 out of 90 existing Mediawiki:*.js files). — AlexSm 20:46, 30 August 2011 (UTC)
Notice that 'ação'.replace(/[^\w ]/g,'') == "ao", so the code discards some characters which people may use as a page title. Helder 00:30, 30 August 2011 (UTC)
I don't think anybody really needs these characters to name a script in MediaWiki namespace. In any case, I was trying to be safe. For example, ...&withJS=-@myowndomain/name.js doesn't work but did somebody actually check it before implementing &withJS? — AlexSm 20:46, 30 August 2011 (UTC)
Well, it is very common to have scripts copied from en.wp to wikis in other languages, where such characters are used on MediaWiki namespace. Considering this, it would be better if the script could just work if people happen to copy it for other projects (some wikis doesn't have people which are able to make adaptations on scripts when they try to make some enwp feature to work on their wikis - they just copy and paste!). Helder 12:59, 26 October 2011 (UTC)

Obsolete code

Main Page tab

In the "Main Page layout fixes" section, there are five lines to change the "Article" tab on the main page to say "Main Page": 

       var nstab = document.getElementById('ca-nstab-main');
       if (nstab && wgUserLanguage=='en') {
           while (nstab.firstChild) { nstab = nstab.firstChild; }
           nstab.nodeValue = 'Main Page';
       }

If MediaWiki:Mainpage-nstab (new for mw1.18) were changed to "Main Page", these lines could be removed. --Yair rand (talk) 05:37, 5 October 2011 (UTC)

Testing... — Edokter (talk) — 09:48, 5 October 2011 (UTC)
 Done. — Edokter (talk) — 09:57, 5 October 2011 (UTC)

makeCollapsible

Could someone remove the following code? It is already available at /wmf/1.18wmf1/resources/jquery/jquery.makeCollapsible.js. 

// makeCollapsible (remove when deployed)
importStylesheet('MediaWiki:JQuery-makeCollapsible.css');
importScript('MediaWiki:JQuery-makeCollapsible.js');

Helder 14:11, 5 October 2011 (UTC)

 Done. Please yell if things break. — Edokter (talk) — 14:22, 5 October 2011 (UTC)
Great!
It seems to have fixed an error reported on Village pump which I was noticing on Special:Watchlist?debug=1:
Uncaught TypeError: Cannot call method 'indexOf' of undefined
on line
if ( $that.attr( 'id' ).indexOf( 'mw-customcollapsible-' ) === 0 ) {
Thanks! Helder 14:30, 5 October 2011 (UTC)

Group-specific JS and CSS

Since rev:r82285 and its followup revisions introduced resource loader modules for each group, I think we can now:

  1. Move the code from MediaWiki:Sysop.js to MediaWiki:Group-sysop.js
  2. Move the code from MediaWiki:Sysop.css to MediaWiki:Group-sysop.css
  3. Move the code from MediaWiki:Accountcreator.css to MediaWiki:Group-accountcreator.css
  4. Remove the lines which used to import MediaWiki:Sysop.js, MediaWiki:Sysop.css and MediaWiki:Accountcreator.css

PS: I think MediaWiki:Group-accountcreator.css is shown as a redlink because it is not a default user group, but inspecting the source code I think it will should work anyway. Helder 15:05, 5 October 2011 (UTC)

No rush here, there are some dependancies that need to be checked, as well as 'porting' DisableSysopJS = yes functionality. — Edokter (talk) — 15:28, 5 October 2011 (UTC)
Ok. One option would be to use a "gadget enabled by default" (this is possible because bug #13742 was fixed) and add the appropriated rights to its line on MediaWiki:Gadgets-definition so it is hidden for normal users (see documentation).
For now, could you remove the code in the following section from MediaWiki:Sysop.js?
/** Creates a button to invert checkboxes on Special:Undelete */
...
See MediaWiki_talk:Sysop.js#Special:Undelete_was_fixed_on_MW_code. Helder 15:57, 5 October 2011 (UTC)
 Done. — Edokter (talk) — 16:47, 5 October 2011 (UTC)
So, could we move the code to a admin-only enabled by default gadget (e.g., using rights=block,delete on its definition)? This way, we could remove window.disableSysopJS from global namespace replacing it by the ability to use a button in preferences, which is a lot better. Helder 12:44, 12 October 2011 (UTC)
Another reason to move the code from MediaWiki:Sysop.css to MediaWiki:Group-sysop.css (or a default gadget) is that it will make it to work even if JavaScript is not available. Helder 13:53, 19 October 2011 (UTC)

I have migrated the CSS, which was all loaded unconditionally, but in doing so discovered a bug: the default messages are at MediaWiki:Group-sysop.css etc, but the messages actually loaded are MediaWiki:Group-Sysop.css. I have committed a fix (r100239) which can hopefully be deployed fairly quickly; when it is deployed we'll need to move the CSS back from Group-Sysop.css to Group-sysop.css. Happy‑melon 17:11, 19 October 2011 (UTC)

Merged in r100759, pushing to site now. Reedy (talk) 22:56, 25 October 2011 (UTC)
Thanks Reedy; I've moved the pages back to their correct locations. All is well with the world once again :D Happy‑melon 23:15, 25 October 2011 (UTC)

Fix RefToolbarLegacy.js

Please fix MediaWiki:RefToolbarLegacy.js for IE as described at Wikipedia:Village pump (technical)/Archive 140#Buttons on editing toolbar (my message). — AlexSm 16:41, 20 October 2011 (UTC)

Update MediaWiki:Common.js/file.js

Hi!

Could someone (review and) apply these changes to MediaWiki:Common.js/file.js? This makes the script localizable, replaces addOnloadHook by jQuery, uses mw.config to access the wg** variables and fix some issues detected by JSHint (which is recommended by MW developers). Helder 14:29, 26 October 2011 (UTC)

 Done. — Edokter (talk) — 19:44, 26 October 2011 (UTC)
Could use jQuery all the way and have something like this
  // ... same i18n part ...

  var url = $('#file img').attr('src');
  if( !url) return;
 
  var htm = mw.msg( 'svg-thumbs-desc' );
  var sizes = [200, 500, 1000, 2000];
  for( var i=0; i < sizes.length; i++ ){
    htm += (i > 0 ? ',' : '')
      + ' <a href="' + url.replace(/\/\d+(px-[^\/]+$)/, '/' + sizes[i] + '$1') 
      +  '">' + sizes[i] + 'px</a>';
  }
 
  $('<p class=SVGThumbs>' + htm + '.</p>').appendTo('div.fullMedia');
in 12 lines instead of 27 (the code is from ru:MediaWiki:Filepage.js). And why use mw.messages to store something that won't be used anywere else? — AlexSm 20:26, 26 October 2011 (UTC)
Thanks for pointing out this jQuery version.
Answering your question, I used mw.messages for two reasons (none really relevant, I confess...):
BTW: It seems to be more efficient to use $('#file').find('img') instead of $('#file img'). See mw:JavaScript performance#Selector performance (jQuery). Helder 00:04, 27 October 2011 (UTC)

Default gadget for secure server

Currently there are two versions of the script for secure server, and they are very similar. What about merging the two scripts into one only page, making it easier to keep updated?

Besides, I think this script could be moved to e.g. MediaWiki:Gadget-always-secure.js, and be loaded by Resource Loader, minified, as a default gadget. This would allow us to remove the globals "disableSecureLinks" and "disableSecureLinks2" (since the user could just toggle a checkbox on Special:Preferences#mw-prefsection-gadgets). Helder 18:21, 27 October 2011 (UTC)

There are two scripts, because the new secure server setup is significantly different from the old setup (universal vs. hack job). Seeing as the old server will be removed at some point, 2 scripts is the better approach, since the old code will no longer be needed as soon as the old server becomes a 'redirect'. No objection to moving it to a gadget, if you can 'auto enable' the gadget on just the secure server. It should not be run, because it's slow and should not by default include all code, because most users won't need all that code. So make the gadget an autoloader for the service, which then lazy loads the script. —TheDJ (talk • contribs) 20:42, 27 October 2011 (UTC)

BLP editnotices script

The BLP script currently isn't very useful, as it only works if one actually presses the "Edit" button, which might not always be the case. There are many "improve this article" links in maintenance templates or the option to edit on double-click, in which cases the editnotice won't appear.

I've created an alternative script that also isn't executed on every pageview, but only if the user might actually edit an article. While in these cases the script makes either one (or if it's a BLP) two connections to the API, I think it could greatly improve performance. Some time soon, the BLP blurb should probably be cached, possibly in a cookie, to avoid unnecessary connection, but at the moment I'm still feeling too unsure with jQuery to try that (in fact, I took me two (!) months to find that one syntax error).

The script is located at User:The Evil IP address/blp.js and at the moment, it will only add the notice to articles in Category:All orphaned articles; while this might seem silly, I've done this to avoid any possible interference between the existing BLP script and mine, it can easily be changed to show the notice in an article from the BLP cat. Another easily implementable feature may be an opt-out for experienced users, who know the message already (even though of course CSS may be used for that, but one would still have to make those two connections).

Please let me know what you think and if you see any room for improvements. --The Evil IP address (talk) 17:53, 12 November 2011 (UTC)

In the previous discussion in October David suggested using hidden category which would eliminate the need for the 1st API call in your script. And some minor notes: (1) API has clcategories parameter; (2) $('div#jump-to-nav') is actually removable in user preferences; on a related note, it would be nice if someone added "(outdated option)" to Tog-showjumplinks message. — AlexSm 22:35, 14 November 2011 (UTC)
clcategories looks like a good idea. I've used #jump-to-nav, because that's where MediaWiki natively adds the editnotices after. I thought it could only be hidden from view via the preferences, not from the DOM. --The Evil IP address (talk) 15:19, 16 November 2011 (UTC)

Border="1" and tables

{| class="wikitable" border="1"

See the links below. border="1" is now allowed in HTML 5. No one has found a way otherwise to share tables with borders while copying and pasting, in syndication, via RSS readers, etc..

My experience with the CSS and JS talk pages on Wikipedia has been fairly negative mostly due to a sort of religious reverence for future HTML 5 nirvana. Well, HTML 5 now allows border="1". See also:

A more recent discussion is here:

I suggest adding back the JS code that enabled the addition of border="1" to wikitables. See this diff of its removal. The edit comment refers to this discussion. The initial discussion that added border="1" is here. --Timeshifter (talk) 15:15, 14 November 2011 (UTC)

default
Like this?
I have to ask, but without CSS, are tables not displayed with default (albeit prehistoric-looking) borders as shown? — Edokter (talk) — 15:36, 14 November 2011 (UTC)
No, the default for <table> is no borders. For HTML concerning tables and table borders see:
http://www.w3schools.com/html/html_tables.asp
And there is no single inline CSS code, I believe, that will add borders to all the cells of a table. See:
http://www.w3schools.com/css/css_table.asp --Timeshifter (talk) 15:46, 14 November 2011 (UTC)
default
Likethis
It varies between browsers. My example at right uses raw HTML, no CSS, few attributes (just two: <table align=right> and <th colspan=2>), but some browsers will show borders where most don't. --Redrose64 (talk) 15:55, 14 November 2011 (UTC)
I do not know of any browser that will show borders for your table. From:
http://www.w3schools.com/html/html_tables.asp - is this:
"If you do not specify a border attribute, the table will be displayed without borders. Sometimes this can be useful, but most of the time, we want the borders to show." --Timeshifter (talk) 16:42, 14 November 2011 (UTC)

Below is the most basic wikitext for a table (no styling at all). Currently border="1" is inserted by the table button if you disable vector's dialog boxes on the editing tab of preferences as I do. "Enable dialogs for inserting links, tables and more." Try it out. The wikitext for the table below came from this method. I removed the styling info at the top:

{| class="wikitable" border="1"
{| 
|-
! header 1
! header 2
! header 3
|-
| row 1, cell 1
| row 1, cell 2
| row 1, cell 3
|-
| row 2, cell 1
| row 2, cell 2
| row 2, cell 3
|}

It produces this:

header 1 header 2 header 3
row 1, cell 1 row 1, cell 2 row 1, cell 3
row 2, cell 1 row 2, cell 2 row 2, cell 3

Doing without easily-sharable tables, charts, and lists (those that use tables) makes for less useful info. It is liking trying to share text without paragraphs. Can you imagine that? There are probably hundreds of thousands of tables on Wikipedia pages. I could give many examples of why sharing many of them without borders is almost impossible. At some point Wikimedia may block the hot-linking of images, and thus image charts. See commons:Category:Statistics. Then the many wikitext-based data and text charts without borders will be what is easily shared by people in email, etc..

I suggest putting border="1" in the other table button inserts when using the table button on the rest of the edit toolbars. For example when dialogs are enabled and "Style with borders" is selected, this table wikitext below is what is produced: 

{| class="wikitable"  
|-
! Header text !! Header text !! Header text
|-
| Example || Example || Example
|-
| Example || Example || Example
|-
| Example || Example || Example
|}

I suggest border="1" be added to the top line.

From this page (emphasis added):

The border attribute on the table element can be used to provide basic fallback styling for the purpose of making tables legible in browsing environments where CSS support is limited or absent, such as text-based browsers, WYSIWYG editors, and in situations where CSS support is disabled or the style sheet is lost. Only the empty string and the value "1" may be used as border values for this purpose. Other values are considered obsolete. To regulate the thickness of such borders, authors should instead use CSS.

From this page (emphasis added):

The border attribute may be specified on a table element to explicitly indicate that the table element is not being used for layout purposes. If specified, the attribute's value must either be the empty string or the value "1". The attribute is used by certain user agents as an indication that borders should be drawn around cells of the table. Tables can be complicated to understand and navigate. To help users with this, user agents should clearly delineate cells in a table from each other, unless the user agent has classified the table as a (non-conforming) layout table.

So border="1" is conforming and not obsolete in HTML 5. --Timeshifter (talk) 08:20, 24 November 2011 (UTC)

Here is a page that explains things more simply:
  • HTML5 TABLE Element Attributes - "In HTML5 the TABLE element uses the global attributes and one other attribute: border. And it has changed to only have the value of 1 or empty (i.e. border=""). If you want to change the width of the border, you should use the border-width CSS property."
This is very clear too: HTML5 table Tag. --Timeshifter (talk) 16:30, 10 January 2012 (UTC)

.hlist

This edit is causing trouble for people using IE7. The last line may raise an exception, which IE7 reports to the user. The .before('( ') fails because the string to be inserted is mis-interpreted as an invalid selector. A possible fix might be to change that to .before('<span>( </span>'). The .after() call would have to be fixed similarly. Lupo 10:48, 17 November 2011 (UTC)

I saw that too, but the problem went away for me. The wikibits server did have some hickups yesterday, perhaps that was the cause. Do you still see the problem? — Edokter (talk) — 11:00, 17 November 2011 (UTC)
Yes, consistently. If the selector before the .before() doesn't match anything, this will fail. It's not a loading/server hiccup issue, it's a question of whether the page does contain anything that matches $('.hlist dl dl, .hlist ol ol, .hlist ul ul'). If not: boom. Lupo 11:26, 17 November 2011 (UTC)
That is one big fat jQuery bug. Putting in <span>...</span> won't help in that case. — Edokter (talk) — 11:41, 17 November 2011 (UTC)
Not sure if it's a jQuery bug. Note that the documentation says the argument must be a HTML string, DOM element, or jQuery object, or a function returning one of these. In particular, see the second example: they do not do $("p").before("Hello"); but explicitly $("p").before( document.createTextNode("Hello") );. Lupo 11:53, 17 November 2011 (UTC)
Passing null should not throw an exception, but just do nothing. I've filed a bug anyway. Meanwhile, the exception should be cleared. — Edokter (talk) — 12:09, 17 November 2011 (UTC)
Yeah. In any case, I can confirm that your fix (checking for an empty list) does avoid the exception being raised. Thanks!Lupo 12:35, 17 November 2011 (UTC)
Bug in jQuery has been fixed. — Edokter (talk) — 21:35, 17 November 2011 (UTC)

Updates needed for 1.19

See these changes that were needed on the 1.19 test site and this report

Wouldn't it be better to only ionclude the code that uses mw.util within that section? -- WOSlinker (talk) 09:29, 14 January 2012 (UTC)
No, mw.util should be global. Wrapping common.js in it a horrible kludge. See also bugzilla:33669; this apparently causes revesal of the load order of site and user JS. — Edokter (talk) — 10:23, 14 January 2012 (UTC)
Bugzilla:33711 states that all modules are now loaded asynchonously. I still think wrapping the entire file in ml.loader.using() is a kludge. Is the wrapping required, or would simply starting with mw.loader.using('mediawikiw.util'); on the top be enough? — Edokter (talk) — 10:51, 14 January 2012 (UTC)
I read the documentaion again. It must be wrapped. It somehow still doesn't sit right with me. Surely, it should be possible to have mw.util as a core dependancy when the site JS module loads? — Edokter (talk) — 11:09, 14 January 2012 (UTC)
It's possible in principle, but MediaWiki currently exposes no interface for defining such dependencies; the mw.loader.using(...) declaration is just the inline equivalent. Happy‑melon 17:12, 14 January 2012 (UTC)
It seems to me this could be done in ResourceLoader itself. — Edokter (talk) — 17:33, 14 January 2012 (UTC)
Also, would simply having mw.loader.using( 'mediawiki.util', mediwiki.util.init ); (or even mw.loader.load( 'mediawiki.util' )) at the top have the same effect? I feel have closing parens at the bottom is an invitation to errors when adding code. — Edokter (talk) — 17:39, 14 January 2012 (UTC)
That's pretty much what I said: the backend to support Common.js having a dependency on any given module is very much in place, but there is currently no mechanism for specifying such dependencies for a given installation of MediaWiki. I'm not a JS expert, but I believe that the asynchronous loading mechanism means that when the JavaScript is sent to the browser to be executed, it would see a using() statement and queue the code within it to be executed when the module had been loaded, but would then merrily continue parsing subsequent lines, almost certainly (unless you had a blisteringly fast connection) before the mw.util module had necessarily loaded. Happy‑melon 18:23, 14 January 2012 (UTC)
How about including private copies of wikiGetlink, getParamValue & addCSS and then there would only be two small bits of code that depend on mw.util.addPortletLink which could be wrapped on their own? -- WOSlinker (talk) 20:11, 14 January 2012 (UTC)
What's so inherently bad about wrapping code? That's all the dependency framework does, it just wraps whole files rather than individual code blocks. The only downside to wrapping is the small chance of someone damaging the closing bracket with a careless edit, something easily countered with a judicious comment. Happy‑melon 21:51, 14 January 2012 (UTC)
Without knowing the internals of javascript engines, this construct seems incredibly inefficient. I may be wrong here. However, it is very counter-intuitive having to require a wrapper on what is now a simple linear construct. Every JS file depending on some functionality is going to require it. That alone should be enough reason to build the dependency tree into ResourceLoader. — Edokter (talk) — 22:13, 14 January 2012 (UTC)
(←) If I seem a bit upset, it is becasue I know this is going to be a potential major breaking change. Requiring all JS files to be wrapped in .using is going to make a lot of wiki operators unhappy. What would be nice is that mw.loader.using( 'someModule' ); without a callback would make a synchronous call to that module's init. That would at least lose the wrapping requirement. — Edokter (talk) — 22:29, 14 January 2012 (UTC)
I agree with Edokter that mw.util should be executed before everything else. You could wrap Common.js but what is going to happen to all existing user .js files? — AlexSm 17:42, 17 January 2012 (UTC)
Wrapping common.js obviously has it's flaws (see below). Wrapping userscripts is less problematic, because they don't need to be global. Scrap that. Any evet that points to some function will also break when wrapped. — Edokter (talk) — 17:49, 17 January 2012 (UTC)

Revert global wrapping

{{sudo}}

Hi. Please revert this edit immediately. It's breaking collapse-related code. I've just confirmed this on test.wikipedia.org. --MZMcBride (talk) 15:36, 17 January 2012 (UTC)

Example messages from the browser error console: 

Error: toggleNavigationBar is not defined
Source File: javascript:toggleNavigationBar(1);
Line: 1

Error: collapseTable is not defined
Source File: https://bits.wikimedia.org/wiki.riteme.site/load.php?debug=false&lang=en&modules=site&only=scripts&skin=monobook&*
Line: 6
Done. Thanks, PeterSymonds (talk) 15:43, 17 January 2012 (UTC)
Thank you! The collapse functionality is working again. --MZMcBride (talk) 15:45, 17 January 2012 (UTC)
Please give exact details (URL) of any failures. This will eventually needs to be reinstated. — Edokter (talk) — 16:46, 17 January 2012 (UTC)
All functions inside your wrapper became private and not accessible through javascript: links. — AlexSm 16:51, 17 January 2012 (UTC)
Then we have a massive dilemma... Break common.js because of the missing dependency declaration, or break common.js because it is no longer global. — Edokter (talk) — 16:59, 17 January 2012 (UTC)
Sorry, I don't know have much more information than what I provided. The code you added broke NavFrame and the other type of collapsing code. The error messages above came from my browser console. The collapsing functionality was broken in Chrome/Windows 7 and Firefox/Windows 7.
I didn't realize that JavaScript had private functions. I'm also not really clear on why the additional code is necessary. I'd strongly encourage testing at test.wikipedia.org if possible first before any additional code changes, though. Breaking collapse code site-wide is kinda nasty. :-) --MZMcBride (talk) 17:10, 17 January 2012 (UTC)
You said you confirmed the error on the test site. Do you have a link to a page there that produces the error? For why it is necessary, see mw:ResourceLoader/Migration guide (users)#Dependencies. — Edokter (talk) — 17:17, 17 January 2012 (UTC)
Edokter: we can either move those function outside the wrapper or replace javascript: URLs with click() events. — AlexSm 17:16, 17 January 2012 (UTC)
collapseTable as a click event also seems broken. The old collapsible code should prpbably go alltogether anyway, but we still may have code that uses mw.util and must be global. This can only be solved by preloading mw.util in core. — Edokter (talk) — 17:25, 17 January 2012 (UTC)
I was testing with testwiki:Collapse. That's a copy of User:MZMcBride/Archive index, which is where I noticed the issue initially. I copied wiki.riteme.site's Common.js to testwiki:MediaWiki:Common.js. Right now, testwiki:Collapse is still broken as test.wikipedia.org's Common.js is using the wrapper code. --MZMcBride (talk) 18:21, 17 January 2012 (UTC)
As a stop-gap you could use:
function(){ /* local scope*/ window.iAmGlobal = function(){ .. } ; ...
Of course global functions like this should be inexistent eventually. Use proper event binding instead. Krinkle (talk) 04:34, 18 January 2012 (UTC)
Thanks Krinkle. We now have a working Common.js on the beta site, and I will make it live here momentarely. Two function need to remain global for now, collapseTable and toggleNavigationBar, which serve the old collapsible table code and NavFrame respectively. These are essentially deprecated in favor of mw-collapsible, and we should make an effort to discourage their use. Two other functions, addPortletLink and getURLParamValue can be safely removed, as they still live in wikibits.js, which is not going anywhere soon. (These mappings were added in a mistaken fear that wikibits would be removed sooner then later.) — Edokter (talk) — 12:20, 19 January 2012 (UTC)

Please do not make any significant changes here before the blackout

Once the blackout goes into effect, editing will locked (although stewards and staff will be able to circumvent this if necessary). Thus if any bad changes are made, it may be difficult to get them reverted until after the blackout. There will be some CentralNotice-related code going into Common.js immediately before the black-out, but otherwise, we should probably leave things as is until after the black-out is over. If you have any questions or comments, please ping me on my talk page or email me. Thanks! Kaldari (talk) 21:16, 17 January 2012 (UTC)

Wait, the blackout is working by CentralNotice? Isn't that Javascript-dependent? --Yair rand (talk) 21:53, 17 January 2012 (UTC)
Yes. Some site-wide CSS will also be deployed concurrently to make the blackout more effective/obnoxious. --MZMcBride (talk) 22:08, 17 January 2012 (UTC)
Just a chance for me to test my hacking skillz. — Edokter (talk) — 22:42, 17 January 2012 (UTC)
Will I still be able to use the readability extension or View > Page Style > No Style in Firefox. — Dispenser 23:07, 17 January 2012 (UTC)
Disabling CSS and javascript will probably get you in. Not sure if editing is disabled. — Edokter (talk) — 23:10, 17 January 2012 (UTC)
Editing will be disabled via $wgGroupPermissions. We're drafting a technical FAQ on Meta, BTW. Steven Walling (WMF) • talk 00:39, 18 January 2012 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=MediaWiki_talk:Common.js/Archive_19&oldid=1087568604"