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)