MediaWiki talk:Common.js/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

Archive 20

Archive 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 (H₃O⁺) 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 Template:Bugzilla 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)

AddPortletLink

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 en.wikipedia.org, 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 en.wikipedia.org).
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 en.wikipedia.org 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 en.wikipedia.org Krinkle (talk) 15:03, 13 June 2011 (UTC)

I should note that the two scripts aren't the same tho. The one on en.wikipedia.org 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)