Jump to content

MediaWiki talk:Common.js/Archive 20

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< MediaWiki talk:Common.js
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 00:48, 14 December 2013 (Archiving 2 discussion(s) from MediaWiki talk:Common.js) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 15←Archive 18Archive 19Archive 20Archive 21Archive 22Archive 23

Do not create NavFrame buttons if the new class "mw-collapsible" is used

Currently, the code which provides the Wikipedia:NavFrame functionality has a test like this 

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame")) {
        // Create the buttons...
    }
}

But this causes a conflict (example) if we try to migrate to the (not so new) MediaWiki plugin which uses the class "mw-collapsible" (see previous discussion). Since it was not good idea to just copy the styles of NavFrames to the classes of this new plugin, I think a good way to help in the migration would be to improve the test above like this: 

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame") && !hasClass(NavFrame, "mw-collapsible")) {
        // Create the buttons...
    }
}

This way, we could still use the old classes for formatting and the new ones to make things "collapsible". The same idea would apply to the old "collapsible tables" system, where 

if ( hasClass( Tables[i], "collapsible" ) ) {

would be replaced by 

if ( hasClass( Tables[i], "collapsible" ) && !hasClass(NavFrame, "mw-collapsible") ) {

What do you think? Would that work? Helder 14:04, 5 March 2012 (UTC)

By the way, we could also replace the deprecated hasClass(NavFrame, "NavFrame") by $(NavFrame).hasClass( 'NavFrame' ) (since this is the last script in MediaWiki namespace using this function). Helder 14:14, 5 March 2012 (UTC)

Split MediaWiki:Common.js/edit.js into (default) gadgets

Wouldn't be better to move the individual parts of MediaWiki:Common.js/edit.js to gadgets enabled by default, and restrict it to users with the 'edit' right?

Besides, instead of checking for $.wikiEditor and $.wikiEditor.modules.dialogs, what about using the values of 

mw.user.options.get('showtoolbar')
mw.user.options.get('usebetatoolbar')
mw.user.options.get('usebetatoolbar-cgd')

to determine which version of the RefToolbar to load? Helder 10:37, 21 January 2012 (UTC)

I wouldn't split everything into gadgets but mwCustomEditButtons has to go to a separate page because it's useless with default settings (!) and WP:RefToolbar 2.0 definitely has to be a default gadget. With MW 1.19 it doesn't work in IE8 and possibly causes problems for other edit buttons. — AlexSm 18:38, 1 March 2012 (UTC)
mwCustomEditButtons is protected by an if so it doesn't really matter. But I do agree about the default gadget. --Locos epraix 03:03, 5 March 2012 (UTC)
It does matter because it's 3+ KB of code. And it's actually not "protected" and the statement if(mwCustomEditButtons) doesn't make any sense: right now it's always true and the code always runs; if devs remove the object then this code will cause JS error. — AlexSm 04:13, 5 March 2012 (UTC)
Yup I didn't realize that var was always defined. It should be changed to something like if(!mw.user.options.get('usebetatoolbar')). --Locos epraix 23:09, 6 March 2012 (UTC)

I've asked the migration of the edittools into a (default) gadget on its talk page. Helder 20:37, 29 June 2012 (UTC)

MediaWiki:Common.js/edit.js: Opt-out

Hey all,

edit.js claims to have an opt-out method by "adding mwCustomEditButtons = []; to Special:Mypage/common.js". However this is in my opinion not a very wise nor reliable way to opt out.

For one, it will redefine the entire array. So any aliases to it are no longer correct and will be pointing to the old array. And if users have other scripts enabled that add buttons, those would be lost as well.

I'd recommend instead turning the button-part of the script into a Gadget and enable it by default (*[ResourceLoader|default]). Then users can simply opt-out but unchecking in the preferences. That makes it load faster (as it will not be loaded at all (instead of undone after the fact) for those opting out. And also more reliable and user friendly. Krinkle (talk) 00:55, 7 March 2012 (UTC)

Bug 32795 fixed

Tracked in Phabricator
Task T34795

The bug affecting line-height printable mode CSS rule, was recently fixed in Mediawiki 1.19. Please check if the following lines are still required. – Fuzzy – 19:57, 6 March 2012 (UTC) 

    // In print IE (7?) does not like line-height
    mw.util.addCSS('@media print { sup, sub, p, .documentDescription { line-height: normal; } }');
Actually, only the margin issue was fixed, the line-height issue is still open i believe. —TheDJ (talk • contribs) 22:51, 6 March 2012 (UTC)
This bugfix enabled the top/bottom margin to be set in print mode (by removing the !important specifier). The line-height fix is a workaround for this issue. – Fuzzy – 09:18, 12 March 2012 (UTC)

MediaWiki:Common.js/edit.js: mw.toolbar.addButton

Hey all,

As some of you may know, using the global mwCustomEditButtons has a down side. If you add an item to it too late (that is, after the toolbar is already initialized), then they are ignored. And there is no way to fix this from here because it's just an array, there is no event taking place that can be hooked into to.

This can be fixed by using mw.toolbar.addButton instead. Which will add it to the queue if it's still early, and add it to the toolbar directly if it's after the initialization. Krinkle (talk) 00:51, 7 March 2012 (UTC)

Arial Unicode MS for IPA

mw.util.addCSS('.IPA, .Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; }');

Arial Unicode MS has known rendering problems for IPA characters. This font shouldn't be included in the list for .IPA. Having it here can make IPA text display incorrectly, or encourage editors to to work around the display problems in their own browser by entering text incorrectly, thus making the display break for readers whose browsers work right. —Michael Z. 2012-03-14 18:16 z

Any suggestions for a better font? Preferably one that is installed by default? — Edokter (talk) — 18:34, 15 March 2012 (UTC)

Arial Unicode MS is the default Windows font that include the biggest range of unicode chars. We should leave it, but change the order. And about Tahoma? --Locos epraix 18:54, 15 March 2012 (UTC)

But it botches the display of IPA, and for some number of users with good IPA fonts installed, it will break IPA which would otherwise display correctly. The requirement is having the IPA characters, not having “the biggest range.” Does including this font actually improve IPA display at all, for anyone?
It looks like Windows has some real IPA fonts.[1] The SIL fonts are free and support a broad or full range of IPA, but many are serif fonts.[2] [updated] —Michael Z. 2012-03-18 19:34 z
See also Wikipedia:IPA#Affricates_and_double_articulation. —Michael Z. 2012-03-16 15:10 z
I'll see if I can filter on Windows version, as basically only XP needs it. — Edokter (talk) — 19:47, 18 March 2012 (UTC)
Thank you. Please let me know how it goes, because we have some catching up to do on this front in en.Wiktionary. —Michael Z. 2012-03-19 04:36 z
Specifying these fonts is only needed for Windows XP using Internet Explorer and specifically Internet Explorer 6 (older than Internet Explorer 7). If you used other browsers on Windows XP, there would be no problem in displaying IPA. I suggest using Lucida Sans Unicode, then Arial, then Segoe UI, then Microsoft Sans Serif, then specify the "inherit" case. Please, use anything but Arial Unicode MS. I remember it appeared very illegible on Windows XP, not to mention its big issue with the tie-bar   ͡   . Segoe UI, DejaVu Sans and Arial Unicode MS aren't installed by default in Windows XP and they appear blurred on Window XP because they were designed to be rendered using technologies like ClearType which are hardly found on Windows XP. It's very weird that Lucida Sans Unicode doesn't render the tie bar properly on Windows 7 (and probably all Windows versions after Windows XP), yet it renders the tie-bar properly on Windows XP. Would the following be able to specify a specific Windows version as it's used for ⟨if ($.client.profile().versionBase == '6') { importScript('MediaWiki:Common.js/IE60Fixes.js'); }⟩?
if ($.client.profile().platform == 'win'().versionBase == 'XP') {
}
--Mahmudmasri (talk) 01:50, 6 July 2012 (UTC)
jQuery.client() does not (yet) have the means to retreive the OS version number. versionBase returns the browser's base version. — Edokter (talk) — 11:37, 30 August 2012 (UTC)
OK, I changed the target for the font to XP only, but still target all browser, as IE8 also benefits, and Chrome still has the Unicode bug under XP. I also prefered Lucida Sans Unicode for IPA while preferring Arial Unicode MS for Unicode. I hope this remedies any issue. Please report any breakage under Windows version newer than XP. — Edokter (talk) — 13:02, 30 August 2012 (UTC)

Uncaught TypeError: Object [object Object] has no method 'wikiEditor'

When I accessed https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&oldid=482403942 I got 

Uncaught TypeError: Object [object Object] has no method 'wikiEditor'

from line 

$target.wikiEditor('addDialog', dialogobj);

of mediawiki:RefToolbar.js. Helder 19:04, 17 March 2012 (UTC)

adjustments to secure.js and secure_new.js

Hey guys,

I adjusted secure.js and secure_new.js to add an exemption for the new shop links. Both of them were added to the same line as the full exemption for www and mail because shop.*.org urls exist for all projects and redirect to shop.wikimedia.org.

  • For the new secure server this should be temporary. We only have SSL on the checkout pages right now because of limitations with the provider but are working on getting that changed. When it exists I'll just revert this out.
  • For the old secure server the link just fails miserably over on incubator because the shop doesn't exist. This one will just stay.

I'll keep an eye here for a couple days but feel free to poke me by email or talk page if you have questions as well. Jalexander--WMF 23:35, 30 March 2012 (UTC)

Changes for /watchlist.js

Hi. I have made some improvements in spanish Wikipedia copy of this code (es:MediaWiki:Common.js/seguimiento.js). I replaced deprecated functions getElementsByClassName() and addOnloadHook. And also changed that javascript URL for a proper onclick attributte. --Locos epraix 09:04, 28 March 2012 (UTC)

Hmm... I didn't see this comment before, but I just made some improvements as well, possbly duplicating part of your effort.
Could you (or someone else) test/review it so a sysop can update enwiki's copy of this? Helder 03:57, 6 October 2012 (UTC)
The addCSS call is rather 'expensive' I believe (DOM update), do we really need it ? Also it targets all spans, though there might be inline ones. I fixed this. The fontsize of the dismiss might be too small to my liking, and I'm not sure of the purpose of the right floating. The right float will require me to count when there are multiple notices, to match content with button, because they are not boxes like centralnotices usually are. —TheDJ (talk • contribs) 11:20, 6 October 2012 (UTC)
Also, i was considering this, to prevent one of the two flash of content stylings. It has both advantages and disadvantages, because for most people it will make the notice invisible (dismissed or not) until the entire script is loaded. —TheDJ (talk • contribs) 11:36, 6 October 2012 (UTC)
I agree the size of the dismiss link is too small. I didn't want to change the existing formatting when I updated it on ptwiki. Now I see this CSS is used on ptwiki and dewiki version but this is not necessarily true for all the zillions of forks... (gadgets 2.0, where are you?)
I think, ideally, instead of using the addCSS, this code and the necessary CSS (if it is kept) should be in a Resource Loader module in a default gadget (e.g. ext.gadget.WatchlistMessages), to get minification and proper caching and allow people to hide these notifications more easily. Helder 13:30, 6 October 2012 (UTC)
I have some reservations about this. Gadgets specific to one page make bad candidates for default gadgets in my opinion. —TheDJ (talk • contribs) 17:00, 6 October 2012 (UTC)
I don't see any problem with this, teahouse.js or DRN-wizard-loader.js either. How can a default gadget be worse than having its code mixed with other unrelated code on common.js (with less modularity and more difficult to use in other wikis) without an option to disable it? Helder 17:31, 6 October 2012 (UTC)

Mobile.js/Mobile.css

Soon we will have a new MediaWiki:Mobile.css and MediaWiki:Mobile.js. These are added only to renderings from the *.m.wikipedia.org domains. One of the first suggested uses is to make amboxes less annoying :D —TheDJ (talk • contribs) 11:49, 23 July 2012 (UTC)

cookies

Sorry about that guys, 2 copy paste errors in a row.... /me now likes to hide —TheDJ (talk • contribs) 20:25, 16 August 2012 (UTC)

Open search result list or search suggestion in new tab

Please see this discussion:

--Timeshifter (talk) 21:29, 18 September 2012 (UTC)

window.hasClass; does it even WORK?

Because it returns false on anything I throw at it in my console. Being deprecated, why not map it to $().hasClass() instead? The following code responds OK in my console: 

window.hasClass = function( element, className ) {
    return $( element ).hasClass( className );
}

It does return the correct results in my cosole. Or better yet, if the current code is in fact defunct, why not just remove it? — Edokter (talk) — 17:51, 20 October 2012 (UTC)

As Hoo man pointed out in June 2011, sco:MediaWiki:Common.js has an updated version of the function createCollapseButtons which do not use the deprecated hasClass anymore. Besides, I also mentioned in March 2012 that this is the only script on MediaWiki namespace which uses window.hasClass. So, unless we want to give some users more time to fix their personal scripts, this should really be removed. If they should be notified, we could add something like
if ( console !== undefined && $.isFunction( console.warn ) ) {
    console.warn( 'The function hasClass was deprecated in 2011 and will be removed soon. Please update your scripts!' );
}
after updating the functions in common.js which are using it.
FYI: hasClass( document.getElementById('firstHeading'), 'firstHeading') works fine here. Besides, there was some talk about how the function works at MediaWiki talk:Common.js/Archive 18#hasClass. Helder 18:45, 20 October 2012 (UTC)
Right, it only seems to accepts single objects (hasClass(document.getElementsByTagName('body')[0], 'mediawiki') returns true). I suspect replacing it with my jQuery version will have no impact; $( document.getElementsByTagName('body')[0] ).hasClass( 'mediawiki') works equally well. I propose we replace it for the time being, so we could at least get rid of this super-advanced-hackery that looks like badly formatted code to us common JavaScript coders. — Edokter (talk) — 19:20, 20 October 2012 (UTC)

Please review

Sanitized version of Common.js in MediaWiki:Common.js/sandbox. Please review before I make it live. Key changes:

  • Now uses MediaWiki code style convention
  • Added importStylesheet and inportScript mappings to mw.loader.load (from Commons)
  • Replaced window.hasClass function with jQuery implementation and marked @deprecated
  • Replaced all instances of window.hasClass in Collapsible Tables code with jQuery

This should have zero impact. Complete diff is here. — Edokter (talk) — 14:09, 21 October 2012 (UTC)

If we're cleaning things up, may as well replace all use of wg* globals with mw.config.get( 'wg*' ). I've made the additional edit to the sandbox. Otherwise, looks good; I don't see anything that should break anything in there. Anomie⚔ 22:00, 21 October 2012 (UTC)
It seems my importScript mapping is not working on test.wiki; it returns 'undefined' in IE8. I must be missing something obvoious... — Edokter (talk) — 19:31, 22 October 2012 (UTC)
The Commons versions of importScript and importStylesheet crashes IE8 due to the if (typeof page === 'string') check. Is this check necessary? — Edokter (talk) — 21:05, 22 October 2012 (UTC)
Not sure why IE would crash in that line. But I do note in rawPageLink that an expression of the form a + b === c ? d : e in JavaScript is evaluated as ( ( a + b ) === c ) ? d : e, rather than a + ( ( b === c ) ? d : e ) as whoever wrote that code seems to be expecting. Anomie⚔ 01:47, 23 October 2012 (UTC)
I wrote that... and fixed it. But even without rawPageLink importScript failed. I've already removed the typeof check, as it seemed rather redundant. — Edokter (talk) — 16:15, 23 October 2012 (UTC)
FYI, there is a script which may be useful in case you plan to do this kind of task more often: m:User talk:Krinkle/Le Tour de Wikí/2011 Resource Walker#Automated script updates. Helder 22:25, 22 October 2012 (UTC)
About the need for wgServer, see bugzilla:34036. Helder 23:06, 22 October 2012 (UTC)
I see no obvious problems. I note that ts_alternate_row_colors = false; doesn't actually do anything. Alternating row colors are no longer provided by the tablesorter code right now. Also the IPv6 code can be removed, we are fully dual stacked now, and thus we no longer need statistics over a 'sample' of the users (confirming this with a sysadmin when they wake up). And support converting the other globals to use mw.config.get. If this is tested on test.wp then I'm in favor. —TheDJ (talk • contribs) 08:18, 23 October 2012 (UTC)
(Removal of IPv6 script approved by mark on IRC) —TheDJ (talk • contribs) 08:29, 23 October 2012 (UTC)
Thank you. More fat trimmed. Current testcode on test.wp gives no errors on my end. — Edokter (talk) — 16:15, 23 October 2012 (UTC)

Performance improvements to wikiminiatlas

This gadget provides great functionality and it would be a shame to remove, but it's causing serious load time issues, blocking all scripts which follow it. At the very least, we need to wrap the resourceloader call in an onready callback.

Here is my proposed change, which will conditionally load wikiminiatlas after searching for relevant page elements: 

// <nowiki>
/*
 * Wrapper to conditionally load wikiminiatlas.js
 */
( function ( $, mw ) {
	var require_wikiminiatlas = false;

	var coord_filter = /geohack/;
	var kml_filter = /Attached_KML/;

	$( document ).ready( function() {
		$( 'a.external.text' ).each( function( key, link ) {
			if ( link.href && coord_filter.exec( link.href ) ) {
				require_wikiminiatlas = true;
				// break from loop
				return false;
			}
		} );

		$( 'table.metadata' ).find( 'a' ).each( function( key, link ) {
			if ( link.href && kml_filter.exec( link.href ) ) {
				require_wikiminiatlas = true;
				// break from loop
				return false;
			}
		} );

		if ( require_wikiminiatlas ) {
			mw.loader.load( '//meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );
		}
	} );
} )( jQuery, mediaWiki );
// </nowiki>

Adamw (talk) 01:17, 25 October 2012 (UTC)

My only concern with this is that it only fixes the issue for enwp. This should be done on all wikis that use wikiminiatlas. Pgehres (WMF) (talk) 01:23, 25 October 2012 (UTC)
Let's test it out here and if there are no problems we can migrate the code to other wikis (or integrate it into wikiminiatlas itself on meta). Kaldari (talk) 06:58, 25 October 2012 (UTC)
Small fix added that will drastically improve performance with the second selector. — Edokter (talk) — 21:56, 25 October 2012 (UTC)
Looks good to me. --Dschwen 22:25, 25 October 2012 (UTC) P.S.: The find command rather than the singular selector is used in the code on meta. Although I cannot say it was a conscious performance decision. It actually surprises me a bit... ...well thinking about it, there are zillions of A elements so using find narrows down the set first, a decision the selector engine could not make on its own. --Dschwen 22:29, 25 October 2012 (UTC)

Does anyone know if this is a sudden problem? WMA has been around for ages and there haven't been any complaints. The script should be in the browser cache, and execution times should be low in modern browsers (it used to be an issue a few years back an I added a timeout back then). --Dschwen 22:32, 25 October 2012 (UTC)

Hi Dschwen, thanks for answering my question so quickly.
Yes, we've been looking at early page load performance quite closely, and while load + execution time on your script are no more of a problem than anything else, the resourceloader call in common.js definitely needs to be postponed until onReady, otherwise a lot of more important stuff is delayed. While we are making that change, I thought it would make sense to save the 10k load hit on pages where the gadget isn't being used.
Also, can you confirm that "Attached_KML" is actually being used anywhere? If not, I'll skip that second selector entirely.
Adamw (talk) 23:32, 25 October 2012 (UTC)
Yes, Adam, Attached_KML is being used on quite a few pages. It is a fairly new template, but I count roughly 2000 uses. Check it out at Mojave Desert for example (well, not right now, since the WMA was emergency-disabled until this fix goes into effect). Also the HighwayProject people have been busy adding it (they pushed for it initially). --Dschwen 01:52, 26 October 2012 (UTC)
So... can we go ahead and enable this fix? --Dschwen 20:58, 26 October 2012 (UTC)
I'm just curious why such an extensive check? What determines the availability if the MiniAtlas. Is that done by some specific parameter of a specific template? If so, that template should add a class, then all that is needed here is check for the class. — Edokter (talk) — 08:46, 27 October 2012 (UTC)
It is more than just a template. The WMA gets added to all coordinate type links (geohack). There is plenty of use of such links outside of templates. The check is not that extensive. It runs only on external links, which are a fraction of the links on page and template.metatdata which also is not a frequently appearing element. --Dschwen 17:11, 27 October 2012 (UTC)
 Done. — Edokter (talk) — 19:37, 27 October 2012 (UTC)

I have made some changes in {{Attached KML }} and in the way WMA detects this template. I added a class attribute class="kmldata". This also allowed me to make this feature available on other language wikis (now live on the french wikipedia). The second check starting with $( 'table.metadata' ).find( 'a' ).each( function( key, link ) { could now be changed to require_wikiminiatlas = $('div.kmldata').length>0; I'm sure that's a bit faster. --Dschwen 16:16, 30 October 2012 (UTC)

Done, though with corrected code (otherwise, finding no div.kmldata would reset require_wikiminiatlas to false). — Edokter (talk) — 21:23, 30 October 2012 (UTC)
And thanks to Kaldari for fixing my syntax error. — Edokter (talk) — 21:30, 30 October 2012 (UTC)
Of course, thanks for correcting and updating! :-) --Dschwen 21:44, 30 October 2012 (UTC) P.S.: to make it even more compact you could pull the second check (in the version i posted) into the variable initialization and before the currently first check. But be sure to pull the declaration of require_wikiminiatlas into the document ready function. --Dschwen 21:44, 30 October 2012 (UTC)

Like such: --Dschwen 21:47, 30 October 2012 (UTC) 

// <nowiki>
( function ( $, mw ) {
    $( document ).ready( function() {
      var require_wikiminiatlas = !!$( 'div.kmldata' ).length;
      var coord_filter = /geohack/;
      $( 'a.external.text' ).each( function( key, link ) {
            if ( link.href && coord_filter.test( link.href ) ) {
                require_wikiminiatlas = true;
                // break from loop
                return false;
            }
        } );
        if ( require_wikiminiatlas ) {
            mw.loader.load( '//meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript' );
        }
    } );
} )( jQuery, mediaWiki );
// </nowiki>
Also, at least in chrome test is a bit faster than exec (changed in my version). --Dschwen 21:51, 30 October 2012 (UTC)

Reftoolbar version selection code review / request for change

I request that the Reftoolbar selection code be changed from 

if( mw.user.options.get('usebetatoolbar') && mw.user.options.get('usebetatoolbar-cgd') ) {
	// Enhanced editing toolbar is on with dialogs. Load standard refToolbar.
	mw.loader.using( 'ext.wikiEditor.toolbar', function () {
	importScript('MediaWiki:RefToolbar.js');
	});
} else if( mw.user.options.get('usebetatoolbar') ) {
	// Dialogs are off. Load refToolbar 2.0 without dialogs.
	mw.loader.using( 'ext.wikiEditor.toolbar', function () {
	importScript('MediaWiki:RefToolbarNoDialogs.js');
	});
} else {
	// Enhanced editing toolbar is off. Load legacy refToolbar 1.0.
	importScript('MediaWiki:RefToolbarLegacy.js');
}

to 

//Choose between Reftoolbar 2.0b (enhanced w/dialogs), 2.0a (enhanced w/o dialogs), and 1.0 (legacy) based on user settings
if( mw.user.options.get('usebetatoolbar') ) {
	if( mw.user.options.get('usebetatoolbar-cgd') ) {
		mw.loader.using( 'ext.wikiEditor.toolbar', function () {
		importScript('MediaWiki:RefToolbar.js');
		});
	} else {
		mw.loader.using( 'ext.wikiEditor.toolbar', function () {
		importScript('MediaWiki:RefToolbarNoDialogs.js');
		});
	}
} else {
	importScript('MediaWiki:RefToolbarLegacy.js');
}

The code ought to be logical identical but the new version avoids an unnecessary fetch and comparison. The logical structure just changed from 

if ( X && Y ) {
	s1;
} else if ( X ) {
	s2;
} else {
	s3;
}
to 
if ( X ) {
	if ( Y ) {
		s1;
	} else {
		s2;
	}
} else {
	s3;
}

I'm not normally a Javascript person, so hopefully no nuance of the language got me. Jason Quinn (talk) 07:19, 7 December 2012 (UTC)

MediaWiki:Common.js/secure.js

Per [wikitech] secure.wikimedia.org is no more, pages such as

Do we still need both scripts? See also:

Helder 15:15, 16 November 2012 (UTC)

Thanks for bringing this up. No, they're probably no longer needed. What do you recommend as a course of action? Simply removing the imports from MediaWiki:Common.js? --MZMcBride (talk) 19:15, 16 November 2012 (UTC)
With all links converted to protocol-relative URLs and the disabling of //secure.wikimedia.org, I think both scripts are obsolete. Just to be safe, I'd like TheDJ's opinion. — Edokter (talk) — 09:38, 17 November 2012 (UTC)
Let's just remove them first. Anyone is free to turn it into a gadget. —TheDJ (talk • contribs) 20:03, 27 November 2012 (UTC)
You only removed the old one. Is the new one still required? — Edokter (talk) — 15:09, 23 December 2012 (UTC)
I believe so, because there are lots of pages with "http:" links. Helder 19:57, 23 December 2012 (UTC)

Edit request for Reftoolbar code comments

In the comment section of MediaWiki:Common.js/edit.js for RefToolbar, I have several edit requests.

  • Change "Wikipedia:RefToolbar 2.0" to "Wikipedia:RefToolbar/2.0" to match recent restructuring I have done.
  • Change 
    Maintainers: [[User:Mr.Z-man]], [[User:Kaldari]]
    to 
    Current maintainers: none
    Former maintainers: [[User:Mr.Z-man]], [[User:Kaldari]]
    As per a talk page discussion, Kaldari is no longer interested and Z-man appears not to be very active anymore on Wikipedia.
  • Also, shouldn't the second "code" tag be a close tag in the "how to bypass" note? Or maybe quotes are better than tags, because a person might think the tags are part of what should go in the js file.

Jason Quinn (talk) 04:24, 7 December 2012 (UTC)

Performed the specific changes you requested, but I'm not sure precisely what you mean about a "close tag". Please come back and supply the code needed for this change. Nyttend (talk) 14:03, 18 December 2012 (UTC)
I suspect that </code> is meant; this is that tag that closes the code element. I've not done anything about it because I don't know where this "how to bypass" note is. Presumably there's a <code> in there which is unbalanced. --Redrose64 (talk) 16:05, 18 December 2012 (UTC)
From MediaWiki:Common.js/edit.js:
To disable this script, add <code>refToolbarInstalled = 'bypass';<code> to [[Special:Mypage/vector.js]].
The second <code> should be </code>. But JQ is right in that you would not actually include <code> in your JS, so quotes would be better, or even move it to the next line and indent. --— Gadget850 (Ed) talk 17:10, 18 December 2012 (UTC)
I went with option 2. --Redrose64 (talk) 17:45, 18 December 2012 (UTC)

MediaWiki:Common.js/secure new.js

Hi!

Could you please make these updates to the code above? Helder 01:22, 20 December 2012 (UTC)

 Done. What does the change in the regex fix? Just curious. — Edokter (talk) — 22:00, 23 December 2012 (UTC)
The code [a-z0-9\.\\-] was chaged to [a-z0-9\.\-] because the "\" was scaping the other "\" instead of scaping the "-". Helder 16:37, 26 December 2012 (UTC)

Do not create NavFrame buttons if the new class "mw-collapsible" is used

(Updated from MediaWiki talk:Common.js/Archive 20#Do not create NavFrame buttons if the new class "mw-collapsible" is used)

Currently, the code which provides the Wikipedia:NavFrame functionality has a test like this 

function createNavigationBarToggleButton(){
    // ...
    if ( $( NavFrame ).hasClass( 'NavFrame' ) ) {
        // Create the buttons...
    }
}

But this causes a conflict (example) if we try to migrate to the (not so new) MediaWiki plugin which uses the class "mw-collapsible" (see previous discussion). Since it was not good idea to just copy the styles of NavFrames to the classes of this new plugin, I think a good way to help in the migration would be to improve the test above as I did on ptwiki: 

function createNavigationBarToggleButton(){
    // ...
    if ( $( NavFrame ).hasClass( 'NavFrame' ) && !$( NavFrame ).hasClass( 'mw-collapsible' ) ) {
        // Create the buttons...
    }
}

This way, we could still use the old classes for formatting and the new ones to make things "collapsible". The same idea would apply to the old "collapsible tables" system, where 

if ( $( Tables[i] ).hasClass( 'collapsible' ) ) {

would be replaced by 

if ( $( Tables[i] ).hasClass( 'collapsible' ) && !$( Tables[i] ).hasClass( 'mw-collapsible' ) ) {

What do you think? Helder 17:03, 26 December 2012 (UTC)

First, the second change is unnecessary as the collapsible and mw-collapsible classes are mutually exclusive anyway. I would like to see a valid use of mixing the navframe and mw-collapsible classes; I can't think of any use as navframe has little styling to speak of. — Edokter (talk) — 19:02, 26 December 2012 (UTC)

Template adder to files

I had written a script for a wikia wiki long back to add templates to image pages: 

// <nowiki>
// File Template Adder
// Easy way to add file maintenance template
function FileTemplateAdder() {
	var tempOptions = {
		'{{no rationale}}': 'No rationale',
		'{{no license}}': 'no license',
		'{{Poor quality}}': 'Poor quality',
		'{{Poor filename}}': 'Poor name',
		'{{delete|quick=true}}': 'Quick delete'
	};
	var tempOptStr = '';
	for (i in tempOptions) {
		tempOptStr += '<option value="' + i + '" style="text-align:center;">' + tempOptions[i] + '</option>';
	}
	var html = '<p style="text-align:center;" class="TemplateAdder"><select id="FileTemplateAdder">' + tempOptStr + '</select>&nbsp;<a class="wikia-button" style="margin:0 1em; cursor:pointer;" id="templateSubmit">Add template</a>';
	$('#filetoc').append(html);
	$('#templateSubmit').click(function (event) {
		this.innerHTML = '<img src="http://images2.wikia.nocookie.net/dev/images/8/82/Facebook_throbber.gif" style="vertical-align: baseline;" border="0" />';
		$.getJSON("/api.php", {
			action: "query",
			prop: "info",
			titles: wgPageName,
			intoken: "edit",
			format: "json",
			indexpageids: 1
		}, function (json) {
			var pageIdentification = json.query.pageids[0];
			var pageToken = json.query.pages[pageIdentification].edittoken;
			$.post("/api.php", {
				action: "edit",
				title: wgPageName,
				token: pageToken,
				bot: true,
				prependtext: $('#FileTemplateAdder').val() + "\n"
			}, function (result) {
				$(".TemplateAdder").remove();
			});
		});
	});
}

if (wgCanonicalNamespace == 'File') {
	addOnloadHook(FileTemplateAdder);
}

// </nowiki>

changing the templates, removing the addOnloadHook, it would make a great gadget here. ~ UltimateSupreme 13:25, 4 January 2013 (UTC)

This script is accessing 3rd party servers and eventually compromises private data / allow these servers to track wikipedia users. I do not recommend to anyone to implement it in current form. Petrb (talk) 13:32, 4 January 2013 (UTC)
+ Better formating would be nice :) Petrb (talk) 13:33, 4 January 2013 (UTC)
I applied jsbeautifier to the code above. Helder 17:21, 14 January 2013 (UTC)

Fix href of NavToggle

On this change the href was removed from NavToggle, which caused the mouse cursor to change from "pointer" to "text". Could you please backport this fix? Helder 17:02, 14 January 2013 (UTC)

 Done. — Edokter (talk) — 21:08, 14 January 2013 (UTC)
There have been reports at VPT of users clicking the link finding their browser jumping to the top of the page. Was this caused by the above fix? — Richardguk (talk) 11:05, 16 January 2013 (UTC)
I don't think so. I tested at Lance Armstrong, observed the problem as described at VPT, reverted edit 533092327, purged and tried again - with no change, so I've restored edit 533092327. --Redrose64 (talk) 11:32, 16 January 2013 (UTC)

When using an empty hash link, please prevent the default behaviour (jumping to the top of the page). The issue is at $( NavToggle ).on( 'click', $.proxy( window.toggleNavigationBar, window, indexNavigationBar ) ); where you should .preventDefault() the click event. -- Rillke (talk) 14:54, 16 January 2013 (UTC)

 Question: That probably means something to a programmer familiar with Javascript, but to an average admin like me who's happy with Pascal (as defined by Niklaus Wirth) but gets hopelessly mixed up with anything object-orientated (even C++), it means very little. Exactly which code should be wrapped in this function call (if function call it is)? --Redrose64 (talk) 17:15, 16 January 2013 (UTC)
 Done Anomie⚔ 21:23, 16 January 2013 (UTC)
Thank you. -- Rillke (talk) 13:05, 18 January 2013 (UTC)

Info action-specific JavaScript

Hi. I'm not ready yet, but I'd like to float the idea of having a MediaWiki:Common.js/info.js page (similar to MediaWiki:Common.js/edit.js). This new JavaScript subpage would load only when &action=info is called. For now, the only enhancement it would provide is the ability to measure centijimbos (when &measure=centijimbos is in the URL), but it would likely have practical applications as well in the future. Any thoughts on or objections to this idea? --MZMcBride (talk) 19:42, 22 January 2013 (UTC)

MediaWiki:Common.js/IEFixes.js

The IEFixes.js section is currently misbehaving in Internet Explorer 10 because all the version comparisons are done with strings - and "10" < "8" (for example) is true in JavaScript. If the three comparisons with $.client.profile().versionBase at the end of IEFixes.js could be changed to compare against numbers instead, that would be a good improvement.

(An example of this problem manifests itself in the Template:Navbox's hlist, producing duplicate bullet marks between list items.)

— Twpol (talk) 16:02, 24 January 2013 (UTC)

Done. — Edokter (talk) — 21:30, 24 January 2013 (UTC)
Thanks! — Twpol (talk) 11:17, 25 January 2013 (UTC)

The tooltips for the FA and GA icons next to the language links currently say "This is a featured article in another language" and "This is a good article in another language", respectively. This choice of wording seems wrong and confusing to me since it's intended to refer to the language directly next to the icon. (You can use the old-standby William Shakespeare to see these icons in action.) I suggest these tooltips be changed to "This is a featured article in this language" and "This is a good article in this language". Jason Quinn (talk) 06:59, 24 April 2013 (UTC)

This is associated with templates like {{link FA}} which create an empty <span></span> which has one attribute, dependent upon the language code passed in the only parameter. For example, {{link FA|fr}} generates <span id="interwiki-fr-fa"></span> --Redrose64 (talk) 16:35, 24 April 2013 (UTC)
True but the tooltips themselves are contained here in MediaWiki:Common.js. Do you agree the change is worthwhile? Jason Quinn (talk) 00:41, 25 April 2013 (UTC)
I went ahead and made this change. Jason Quinn (talk) 01:50, 11 May 2013 (UTC)
What would be better still are messages that say "'[ARTICLE NAME]' in [LANGUAGE NAME] is a featured article." and "'[ARTICLE NAME]' in [LANGUAGE NAME] is a good article.". I'm not actually sure off the top of my head how to do that. I'll contact User:Ruud Koot about that. Jason Quinn (talk) 01:58, 11 May 2013 (UTC)

MediaWiki:Common.js/secure new.js

add Wikivoyage, Wikidata to the regex, please πr2 (t • c) 23:44, 15 June 2013 (UTC)

To do that, replace "|imediafoundation" with "|ivoyage|idata|imediafoundation". πr2 (t • c) 00:55, 16 June 2013 (UTC)
Done. Note that this script is only a fallback for links still containing "http[s]://..." instead of protocol-relative links starting with "//...". — Edokter (talk) — 09:31, 16 June 2013 (UTC)
Yes, I know. Wikivoyage seems to work, but not Wikidata. I'm not sure why, but it's not a big deal anyway (nobody links to Wikidata) πr2 (t • c) 15:24, 17 June 2013 (UTC)
@PiRSquared17: fixed. —TheDJ (talk • contribs) 19:34, 17 June 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_20&oldid=585984964"