MediaWiki talk:Common.js/Archive 20

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15 ← Archive 18 Archive 19 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 (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)

Tooltips for FA and GA links in other languages

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)

AFTv5 temp fix for forms appearing for no reason

A change recently deployed for AFTv5 has the unfortunate side-effect of AFTv5 sometimes showing up on pages where it shouldn't. This is caused when the page output still being cached, while the new Javascript is already loaded.

On an per-article basis, an ?action=purge will fix the problem. Or as soon as an article is updated, this problem will no longer occur. Or over time, caches will expire. Until then though, the below code is a temporary fix that will ensure the form is not added to pages where it does not belong. 

/**
 * A recent update for AFTv5 is not behaving properly when
 * cache page output is served & a non-cached JS is loaded.
 * The default value of 'permissionLevel' will now be false,
 * instead of an actual value. Cached pages will still have
 * the default value set though (instead of false), so the
 * new JavaScript will interpret that as that the permission
 * level has been set specifically, instead of falling back
 * to the real (disabled) default value.
 * This code will basically detect if the page output is old,
 * and if so, re-calculate and correct what the values for
 * permissionLevel & defaultPermissionLevel.
 */
 var article = mw.config.get( 'aftv5Article' );
 if (
 	article &&
 	// when this key was introduced, so was the good data we're using now
 	!( 'aft-noone' in mw.config.get( 'wgArticleFeedbackv5Permissions' ) ) &&
 	// make sure no specific protection was set (aft-reader was default)
 	article['permissionLevel'] === 'aft-reader'
 ) {
 	// pretend no permission level is set
 	article['permissionLevel'] = false;
  
 	// now that data is corrected, check if AFT should be enabled;
 	// if not, we should make sure that any form being added is
 	// removed again
 	// if verify function does not exist, we need not worry,
 	// AFT data is corrected now already so nothing wrong
 	// will be added
 	if ( typeof $.aftUtils.verify === 'function' && !$.aftUtils.verify( 'article' ) ) {
 		var remove, interval;
  
 		remove = function() {
 			var $aft = $( '#mw-articlefeedbackv5' );
  
 			if ( $aft.length > 0 ) {
 				$aft.remove();
 				clearInterval( interval );
 			}
 		};
 		interval = setInterval( remove, 100 );
 	}
 }
the above post is by WMF engineer mw:User:Mlitn, the same fix has already been applied on dewiki by him: [3]. --se4598 (talk) 15:50, 7 June 2013 (UTC)
How long is the fix expected to be needed? — Edokter (talk) — 18:37, 7 June 2013 (UTC)
someone says one month. I think also the new reported bug bugzilla:49347 will be fixed by this. Consider wrapping above code in (function(){ /* code */ })(); because of "variable pollution" (don't know exact term) etc. --se4598 (talk) 23:41, 8 June 2013 (UTC)
 Done. LFaraone 15:20, 11 June 2013 (UTC)
I just updated the script: a more robust check has been deployed af part of AFT; if someone could replace the previous code by this new code (old, stale caches still need to be accounted for until they expire), that'd be great. The date the script can then be removed is still July 7. Mlitn (talk) 01:14, 19 June 2013 (UTC)
 Done. Kaldari (talk) 17:29, 19 June 2013 (UTC)

MediaWiki:Common.js/edit.js

In MediaWiki:Common.js/edit.js , I propose that the following 

/**
 * RefToolbar
 *
 *  Description: Adds tools for citing references to the edit toolbar. 
 *  See [[Wikipedia:RefToolbar/2.0]] for further documentation.
 *
 *  To disable this script, add
 *      refToolbarInstalled = 'bypass';
 *  to [[Special:Mypage/vector.js]].
 *
 *  Current maintainers: none
 *  Former maintainers: [[User:Mr.Z-man]], [[User:Kaldari]]
 */
 
function initializeRefTools() {
    if ( window.refToolbarInstalled === undefined ) {
        importScriptURI('//en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbarBase.js&action=raw&ctype=text/javascript');
 
        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');
        }
        window.refToolbarInstalled = true;
    }
}

be changed to 

/**
 * RefToolbar
 *
 *  Description: Adds tools for citing references to the edit toolbar. 
 *  See [[Wikipedia:RefToolbar]] for further documentation. One of
 *  three possible versions will load (Reftoolbar 2.0b, Reftoolbar 2.0a,
 *  or Reftoolbar 1.0) depending on the user preferences (the
 *  usebetatoolbar and usebetatoolbar-cgd parameters).
 *
 *  To disable this script, add
 *      refToolbarInstalled = 'bypass';
 *  to [[Special:Mypage/common.js]].
 *
 *  Current maintainers: none
 *  Former maintainers: [[User:Mr.Z-man]], [[User:Kaldari]]
 */
function initializeRefTools() {
    if ( window.refToolbarInstalled === undefined ) {
        importScript( 'MediaWiki:RefToolbarBase.js' );
 
        if ( mw.user.options.get( 'usebetatoolbar' ) ) {
            // Enhanced editing toolbar is on. Going to load Reftoolbar 2.0a or 2.0b.
            if ( mw.user.options.get( 'usebetatoolbar-cgd' ) ) {
                // Dialogs are on. Loading 2.0b. (standard)
                mw.loader.using( 'ext.wikiEditor.toolbar', function () {
                    importScript( 'MediaWiki:RefToolbar.js' );
                });
            } else {
                // Dialogs are off. Loading 2.0a.
                mw.loader.using( 'ext.wikiEditor.toolbar', function () {
                    importScript( 'MediaWiki:RefToolbarNoDialogs.js' );
                });
            }
        } else {
            // Enhanced editing toolbar is off. Loading Reftoolbar 1.0. (legacy)
            importScript( 'MediaWiki:RefToolbarLegacy.js' );
        }
        
        window.refToolbarInstalled = true;
    }
}

The main change is a tweak to the logic to make the code slighter easier to follow. It should also be slightly faster for some users. There's also improved documentation. Jason Quinn (talk) 07:35, 21 April 2013 (UTC)

I've made two extra tweaks; replaced 'vector.js' with 'common.js' in comment, and replaced importScriptURI call with importScript. Looks good to me. I'll replace it when no one else spots a mistake. — Edokter (talk) — 08:25, 21 April 2013 (UTC)
This looks good to me. Kaldari (talk) 17:58, 7 June 2013 (UTC)
 Done. — Edokter (talk) — 18:32, 7 June 2013 (UTC)

I would like to suggest one more update to MediaWiki:Common.js/edit.js. Could someone please (review it and) apply the changes? Helder 15:52, 22 July 2013 (UTC)

@Jason Quinn, Kaldari, and Edokter: Perhaps one of you could take a look at this? Best — Mr. Stradivarius ♪ talk ♪ 12:09, 24 July 2013 (UTC)
Done. —TheDJ (talk • contribs) 12:41, 24 July 2013 (UTC)

IEFixes and non-wrapping navbox

Unfortunately, because of the corporate environment, I'm forced to try and get a wiki working for IE8. I've loaded common.css, common.js and common.js/IEFixes.js, and have Tidy enabled. The navbox looks fine on compatibility view, but in non-compatibility view the navbox goes off the screen and doesn't wrap properly. Template:Navbox mentions this issue when using images, but I'm not using any images. I'm wondering if this has something to do with hlist and if anyone has any ideas. Thanks! Mentatim (talk) 19:01, 25 July 2013 (UTC)

Have you checked the archives? MediaWiki talk:Common.css/Archive 14#hlist class and infobox wrapping may be relevant. --Redrose64 (talk) 19:55, 25 July 2013 (UTC)
Thanks for a direct reference! I took a look and I had tried updating the parser.php from </li><li> to </li>\n<li> per the bugzilla proposed solution but that seems to have no effect. This isn't on a special page either, so Tidy should be in effect. Sorry if I seem to be rehashing an old issue, I just can't seem to figure out what the solution was. Mentatim (talk) 20:21, 25 July 2013 (UTC)
An added detail, this problem seems to also be present when viewing the site in the latest Chrome and Firefox. Mentatim (talk) 21:56, 25 July 2013 (UTC)
Managed to get the solution to work after all by changing it to '</li>'."\n".'<li>' . Just posting for the reference of people like myself. Thanks again! — Preceding unsigned comment added by Mentatim (talk • contribs) 15:36, 26 July 2013 (UTC)

mw.hooks

In preparation for the new mw.hooks, I tested them on test.wikipedia.org and it seems to work just fine. I'm not sure if there may be some caching on the anonymous pages that might break if we start using this within the 1st 30 days, so i'm not deploying this here just yet. —TheDJ (talk • contribs) 12:39, 28 July 2013 (UTC)

Is there some more documentation, ie. what events are available (outside content)? — Edokter (talk) — 13:21, 28 July 2013 (UTC)
There will be more (for interlanguagelinks, categories and a few others), but for now this is the only one deployed. —TheDJ (talk • contribs) 09:07, 29 July 2013 (UTC)
@TheDJ: could you backport this update from Commons now? Helder 20:40, 24 September 2013 (UTC)
@Helder.wiki: We already added that a while ago link.
Hm, ok. It seems I confused the links I was checking. Thanks anyway! Helder 10:01, 25 September 2013 (UTC)

LinkFA is broken

LinkFA() (which works with {{Link FA}} and {{Link GA}} to place icons next to featured and good interwiki links) broke at some point due to a change in MediaWiki. See the fix at the Vietnamese Wikipedia. – Minh Nguyễn (talk, contribs) 20:40, 13 December 2013 (UTC)

SidebarTranslate gadget is broken too. — Edokter (talk) — 21:39, 13 December 2013 (UTC)
Both issues now fixed. — Edokter (talk) — 22:15, 13 December 2013 (UTC)
For the record, this was caused by gerrit:94899. See also d:Wikidata:Contact the development team#Featured articles. Helder 11:25, 18 December 2013 (UTC)

On that patch, Nikerabbit recommends to instead check for elements where «The[re] is a lang attribute on the link inside». --Nemo 13:58, 18 December 2013 (UTC)

Sorry, I don't quite follow. What is broken and what should be changed here? — Edokter (talk) — 20:24, 18 December 2013 (UTC)
Nothing is broken yet, but Nikerabbit said they broke this feature because it made an "unreliable assumption", while it should instead do the check he described: if you don't, the feature will probably break again in the future. I don't know how to code such a check in JavaScript, sorry. --Nemo 16:05, 20 December 2013 (UTC)
Please use the editprotected template only for exact edits, not for generic discussions or feature requests. If the script breaks again, we'll make sure to implement a permanent solution. — Edokter (talk) — 20:56, 20 December 2013 (UTC)

Updated CodeEditor

I just updated the version of ACE in our CodeEditor. If you use this editor often, take a minute or two to test it out. Most interesting change is most likely the new improved Find and replace. Use ctrl-F or cmd-F to access it. There are options for case sensitivity, regexp etc. You can start typing and it will highlight all the matches as you type. Pressing ctrl-G brings you to the next match, ctrl-shift-G for the previous match. Pressing ctrl-F a second time brings up the replace dialog. cmd-, brings up the settings dialog (non-persistable). I'm in the process of writing a patch to add a 'show invisible characters' persisted toggle button to the CodeEditor. If there are other options in the settings dialog that you think we should offer in the toolbar with persisted settings, then please file a bug report with your idea. —TheDJ (talk • contribs) 07:40, 10 January 2014 (UTC)

Template:InterProject

Would it be possible to add the script for this template to Common.js at en.wiki? Regards, --Brackenheim (talk) 18:05, 14 February 2014 (UTC)

I would prefer this to be just a gadget, to allow people to turn it on/off. And be aware that it allows one to change the contents of the sidebar: wikt:de:Wiktionary:Teestube/Archiv/2010/04#Vorlage:InterProjekt and MediaWiki:Common.js. Helder.wiki 18:26, 14 February 2014 (UTC)

edit.js loading on protected view-only pages

bugzilla:39577 suggests that the toolbar loading on protected view-only pages is an en.wp problem, and it appears that edit.js is loading if action is 'edit', even when the 'edit' action isnt fulfilled because the page is protected from editing. The condition 

if ( mw.config.get( 'wgAction' ) === 'edit' || mw.config.get( 'wgAction' ) === 'submit' || mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload' ) {

should be changed to 

if ( mw.config.get( 'wgIsProbablyEditable' ) === 'true' || mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload' ) {

Or similar.---John Vandenberg (chat) 02:47, 29 July 2013 (UTC)

We might also provide a local fix for bugzilla:24041, by changing edit.js to not load the toolbar if the page title ends in .js or .css John Vandenberg (chat) 02:54, 29 July 2013 (UTC)
@John Vandenberg: wgIsProbablyEditable is a boolean, so the === 'true' will not work (and is not needed). Also, if it's desired to only load on the edit screen, the 'edit'/'submit' check is still needed (wgIsProbablyEditable is just about user-specific permissions, not whether they're currently in edit mode). Superm401 - Talk 19:44, 12 February 2014 (UTC)
Thanks for looking at this. I had a quick peak at the code, and agree on all counts - the edit/submit check is still needed. Do you know if there is a better way of doing any of this? Do you agree with this fix for bugzilla 39577? John Vandenberg (chat) 01:20, 14 February 2014 (UTC)
if ( (mw.config.get( 'wgIsProbablyEditable' ) && (mw.config.get( 'wgAction' ) === 'edit' || mw.config.get( 'wgAction' ) === 'submit')) || mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload' ) {
  • The above should probably work, no? — {{U|Technical 13}} (t • e • c) 01:59, 14 February 2014 (UTC)

Fixing Template:clickable button

Suggest adding the following fragment to fix the usage of {{clickable button}} as being discussed on VPT. —TheDJ (talk • contribs) 13:10, 2 December 2013 (UTC) 

mw.hook( 'wikipage.content' ).add( function() {
    if ( ( mw.loader.getState( 'mediawiki.ui.button' ) === 'registered'  ) && (  $( '.mw-ui-button' ).length ) ) {
        mw.loader.load('mediawiki.ui.button');
    }
} );
Personally, I'd rather see the template fixed to not use jquery.ui.button styles. Anomie⚔ 13:37, 2 December 2013 (UTC)
What should it use then?
  • The module "mediawiki.ui" (which would be the most appropriate alternative) is not automatically loaded either.
  • The styling is not possible directly in the template (e.g. due to missing :hover effects).
  • Adding all the rules to Commons.css doesn't seem right to me.
Any possibility I overlooked? --Patrick87 (talk) 15:58, 2 December 2013 (UTC)
Why not use (and load) CSS that is already there? CSS inline or in Common.css is bloat, so this seems the best solution. I do agree that mediawiki.ui is the best alternative, as it is native to MediaWiki, while jQuery.ui is external code. — Edokter (talk) — 21:42, 2 December 2013 (UTC)
Using JS to load CSS that has no dependency on JS is ugly. Anomie⚔ 22:18, 2 December 2013 (UTC)
It's also slower, and can be broken if the browser has javascript disabled. --Redrose64 (talk) 12:56, 3 December 2013 (UTC)
Hey, Guys! Moaning about the usage of JS in jQuery.ui doesn't solve the Problem. If you don't want to use JS then better come up with an alternative. If you want to use mediawiki.ui, then come up with a solution how to load it without JS, since it is not available by default. Loading it through JavaScript would be no improvement... --Patrick87 (talk) 17:10, 3 December 2013 (UTC)
If you want a CSS module, ask for it in Common.css 
@import url( '//bits.wikimedia.org/en.wikipedia.org/load.php?modules=mediawiki.ui&only=styles&skin=vector&*' );
works AFAICT, even with JS disabled. -- S Page (WMF) (talk) 03:57, 5 December 2013 (UTC)
+1. That is what I suggested when the jQuery UI CSS was removed. Helder 09:18, 5 December 2013 (UTC)
Using @import is bad practice; it loads the CSS unconditionally, adds a http request and bypasses RecourceLoader alltogether. What would really be nice is if RecourceLoader (or some other extension) would load CSS modules on-demand when certain CSS classes are encountered. — Edokter (talk) — 17:55, 5 December 2013 (UTC)
Small correction: load.php doesn't bypass ResourceLoader, it's handled by ResourceLoader. You're right this is a separate request and I believe browsers will make it even if a page references the 'mediawiki.ui' module for other reasons, but RL compiles the LESS files, minimizes the CSS, and caches the result so that it should be a status 304 unchanged on subsequent requests. -- S Page (WMF) (talk) 08:26, 6 December 2013 (UTC)

I have a potential solution here. Kaldari (talk) 19:19, 3 December 2013 (UTC)

I +1 that. Seems like a good idea. — Edokter (talk) — 21:13, 3 December 2013 (UTC)
User:Ragesoss told me this is still a problem. I think we should just pick a solution. The mediawiki.ui.button can now also be loaded (separately from the rest of mediawiki.ui). So I think we should do one of:
  1. Use a snippet like the "jQuery UI loader" section at commons:MediaWiki:Common.js. I recommend this for now, since it won't trigger an unnecessary request (if it's already loaded) or require changing any templates immediately. The only down side is that without JS, it appears as a regular link; however, I think this is acceptable.
  2. Change templates to use mediawiki.ui buttons. See http://tools.wmflabs.org/styleguide/desktop/section-2.html . However, there is a pending change that has not yet made it to either those docs or English Wikipedia. mw-ui-primary is deprecated (and will eventually be removed). The recommended ones will be mw-ui-constructive, mw-ui-progressive, and mw-ui-destructive. This currently requires a similar JS loader. If this option is chosen, I recommend waiting until after the February 6 deployment, when the available mediawiki.ui class names will be updated. In the future, the CSS for this option may be loaded automatically by core.
Using the @import option may seem good; however, the downside is that it will load a separate copy even if JS on the page already loads jquery.ui.button (which has both JS and CSS parts). Superm401 - Talk 04:30, 30 January 2014 (UTC)
@Superm401, Kaldari, and Edokter:: Is it possible to implement the contructive/progressive/destructive styles in a template now that the February 6 deployment has happened?--Sage Ross (WMF) (talk) 15:02, 12 February 2014 (UTC)
Not sure what the deployment did... I still have to lazy-load mediawiki.ui.button. I was hoping it was available by default. The template needs work too as it still relies on jquery.ui.button. So you want to lazy-load mediawiki.ui.button? Also, just a crazy question, how about loading it as a dependency of a dummy, hidden, default gadget? — Edokter (talk) — 16:01, 12 February 2014 (UTC)
@Edokter: I originally implemented it as loaded by default, but this was blocked by Krinkle due to a disagreement on how it should be loaded. In the meantime, the loading code was removed so that the module could be deployed. You can read the whole tortured discussion at https://gerrit.wikimedia.org/r/#/c/98869/. Sorry this is still unresolved. I expect that we will switch it over to be loaded by default at some point, but I'm not sure when. Kaldari (talk) 18:37, 12 February 2014 (UTC)
@Edokter:, If I remember correctly, when I tried to use the current hack to create a hidden gadget and enabled it by default, it was not loaded at all (probably because no one has the "hidden" permission). Helder 18:51, 12 February 2014 (UTC)
The deployment added mw-ui-progressive and changed the appearance. Superm401 - Talk 19:36, 12 February 2014 (UTC)
Also, the docs at http://tools.wmflabs.org/styleguide/desktop/section-2.html are now up to date. Superm401 - Talk 19:39, 12 February 2014 (UTC)
@Sage Ross (WMF): The new progressive/constructive/destructive styles are not yet live on en.wiki, but I think they should be going live tomorrow. Kaldari (talk) 18:43, 12 February 2014 (UTC)
@Kaldari:, @Sage Ross (WMF):, @Edokter:, mediawiki.ui.button is actually here, with all three classes (constructive, destructive, progressive). I'm using the classes right to the left in this comment, so if you run mw.loader.load( 'mediawiki.ui.button' ), you can see them).
It just isn't loaded by default, so the loader script is currently needed. As Kaldari said, we are looking at loading it by default (I plan to discuss this further soon). Superm401 - Talk 19:34, 12 February 2014 (UTC)
 Done. mediawiki-ui-button is now lazy-loaded when .mw-ui-button is found. Template:Clickable button and Template:Clickable button 2 still needs to be modified. — Edokter (talk) — 20:27, 12 February 2014 (UTC)
See Portal:Contents to see it in action. — Edokter (talk) — 23:03, 12 February 2014 (UTC)
  •  Not done There are lots of pages this changed broke the appearance of. So, what I have done is added some backwards compatibility and an administrative category of Category:Pages using old style ui-button-color so those pages using the old styles can be easily found and updated to the new styles. Give it a couple days to run through the job queue and I'll run AWB on the pages in the cat and replace /ui-button-(green|blue|red)/ with mw-ui-{{subst:#switch:{{subst:lc:$1}}|green=constructive|blue=progressive|red=destructive}} and that should bring all of the old codes up to date. Feel free to add that tracking category to any other template that needs this string replaced as well. — {{U|Technical 13}} (t • e • c) 15:23, 13 February 2014 (UTC)
    • Technical 13, Please undo youself! I'm not going into a wheelwar. You made it completely disfuctional again. You cannot build in "backward" compatibility because the old jquery.ui.button module is no longer loaded by default! Yet you keep relying on it as if it does. All I get is plain links. How is that any better??? — Edokter (talk) — 21:03, 13 February 2014 (UTC)
  • Edokter, I'm not sure what you are or are not seeing, but I see that both versions, the old class and the new, are working correctly. I've even received thanks from others through the system for this backwards compatability. So, I'm guessing that it must be providing at least some backwards compatibilty for some users (maybe only the ones that are having the old jquery.ui.button module loaded by some other script or method (Twinkle or AFCH maybe). What I currently have for pages using the new class also seem to be working just fine for me, and either way, I've got a categorization in there so that all of the old uses can be found and updated and then the backwards compatibility can be just stripped out of it. I have no intentions on warring with you, and I agree the new style is the way to go, it is just going to take a little time to do it right and make sure that all of the old uses are updated so that they don't look hacky in the mean time. — {{U|Technical 13}} (t • e • c) 22:14, 13 February 2014 (UTC)
  • Technical 13, if you see any buttons working with the new styling, it is becasue caching has not caught up; you removed mw-ui-button, so you could not even be seeing the new style. In the mean time, the old jQuery style will perhaps be visible to some users either loading the script in their user js, or they happen to hit a page that has jQuery active. But it remains unreliable. Will you please revert the template back to use mw-ui-button only? Then we can work on fixing those issues reported. The current situation is highly unreliable and makes "fixing" impossible. — Edokter (talk) — 22:40, 13 February 2014 (UTC)
File:Clickable button 2 testcases.png
As seen by Technical 13 using both the old and new buttons...
  • Here... Test cases...
  • Old buttons:
  • New buttons:
File:Clickable button 2 testcases without backwards compat.png
As seen by Technical 13 using both the old and new buttons without the backwards compatibility mode that Anne Delong reported on WT:WikiProject Articles for creation/Helper script#Funny colours on the grey Afc draft template
I don't know about you, but they all look like buttons of the right color to me. So far, only 6 uses of the old classes seem to be showing up in the category... So, I'll run them through AWB tomorrow (see how much that number jumps to, guessing it is not all the way through the job queue yet). — {{U|Technical 13}} (t • e • c) 23:06, 13 February 2014 (UTC)
As seen by Edokter using both the old and new buttons...
Yeah... I don't see the old buttons, because, as I said before, jquery.ui.button is no longer loaded by default. It hasn't for months. If you do see them, you are secretly loading it yourself. It is for that reason the old classes should not be used anymore. We cannot rely on code that isn't loaded. So please again, disable the old classes and focus on fixing issues with then new one, which now is loaded by default. — Edokter (talk) — 00:18, 14 February 2014 (UTC)
And here's my screenshot. Just so you know, this is how >90% of readers see it. — Edokter (talk) — 00:24, 14 February 2014 (UTC)
  • To be honest, the raw link is better than what the other 10% see without the backwards compatibility and your new version buttons look fine either way. (screenshot included). — {{U|Technical 13}} (t • e • c) 01:05, 14 February 2014 (UTC)
The buttons were broken for about three months now. I don't really think it matters at this point if there is some sort of backwards compatibility or not. In the worst case of Technical 13's "backward compatibility" version everything looks like it did for the past months. In the best case it looks as it should. If the transclusions of the templates are fixed eventually to correctly use mw-ui-buttons I don't think you should worry how they look in the short migratio period. --Patrick87 (talk) 02:15, 14 February 2014 (UTC)
Let's give it a few weeks (or months) to make sure that is fully through the job queue, and as long as that number is 0, then what the old buttons look like is a moot point I would think and the new buttons seem to be working great for everyone. Post edit conflict response, they've been working fine for me and everyone else at AFC, which probably has the highest usage count of the old buttons for the last three months until they were just changed. No-one has reported any issues with the buttons either, this makes me think that Edoktr's numbers of 90% don't see the practically solid white buttons with no text (or at least that's how it looks unless you do some major straining) is backwards and 90% were still seeing them correctly. Anyways, unless the count of pages in the "using the old style button" class changes from zero, still a moot point. — {{U|Technical 13}} (t • e • c) 02:22, 14 February 2014 (UTC)
  • Update: Cleaned up another 35 pages in the category. I'm going to leave the example on this page alone for now, so the counter should read "1". — {{U|Technical 13}} (t • e • c) 15:40, 15 February 2014 (UTC)
    • It's not. Still contains few TWA templates. I'll clean those up. — Edokter (talk) — 16:49, 15 February 2014 (UTC)
    • And MANY more TWA popups use the old classes. Where are those located? They don't show up as they are not pages. — Edokter (talk) — 16:56, 15 February 2014 (UTC)
  • They'll show up in the category just like the ones you just fixed did that I put in edit requests for (you may want to mark all of those requests as done btw). ;) Patience, if they're not in the category yet, then they are still using the old code which was working fine for more people. — {{U|Technical 13}} (t • e • c) 17:16, 15 February 2014 (UTC)
Also, Edokter, what do you think of adding more color options to the schema as User:EuroCarGT/sandbox#New implies it may be a good idea. I've often thought about adding thosed other colors too. — {{U|Technical 13}} (t • e • c) 17:21, 15 February 2014 (UTC)
Let's take it one step at a time. It hink these buttons (and its colors) are to be regarded as 'official', and more color options would better be served in another template. — Edokter (talk) — 17:44, 15 February 2014 (UTC)
  • Just did another cleanout of the category for 19 edits... — {{U|Technical 13}} (t • e • c) 05:48, 18 February 2014 (UTC)
  • Edokter, the search you linked, and a search for ui-button- brought up no transclusions, so I am unsure what you were trying to get at. The category will find them all as quickly as the job queue processes things... — {{U|Technical 13}} (t • e • c) 15:06, 18 February 2014 (UTC)
    Technical 13, there are 96 results using the old search and only 6 using the beta search. Are you using the beta feature? Helder.wiki 18:02, 18 February 2014 (UTC)
  • Helder, I am using the beta search... I guess it is junk... I'll switch it back. — {{U|Technical 13}} (t • e • c) 18:08, 18 February 2014 (UTC)
  • Update, just did a quick search and replaced most of the ones I could find, there are some that are archives I'm not bothering to change, some that were just instructions on what should be changed and there were some user .css that I can't change (but I left a note on the talk pages so the user can decide if it needs to be changed themself). There may still be others out there, I'm not confident in that search finding them "all". — {{U|Technical 13}} (t • e • c) 18:25, 18 February 2014 (UTC)
    • Technical 13, Edokter, to confirm, jQuery UI is not loaded by default anymore. Try logging out and you will be able to see this. If it's loaded for you when logged in, that's because you're using a script or gadget. I also don't want people to edit war, but please do test viewing the buttons while logged out. As for mediawiki.ui.button, I have proposed a change to load it by default for all users. If that's merged, it will work even if JavaScript is off, and the Common.js loader can be removed. Superm401 - Talk 22:34, 18 February 2014 (UTC)

Fixing IPA template for Windows XP

I propose to make Segoe UI the default IPA-style font for Windows XP, because the default Unicode fonts (Arial Unicode MS and Lucida Sans Unicode) don't have glyphs for special characters such as superscripts/subscripts in the "Phonetic Extensions" block. You can check the availability of these signs for a given font here. Talskubilos (talk) 14:44, 25 December 2013 (UTC)

Segoe UI is not a default Windows XP font, but is only installed with certain software (Office 2007). We cannot rely on XP users having to install extra software. — Edokter (talk) — 18:32, 25 December 2013 (UTC)

But Arial Unicode MS and Lucida Sans Unicode fall into the same category, as they come with Office 2003 and later, not with XP. For example, in Tartessian_language there's a notice advertising the use of IPA symbols which need special font support. A temporary workaround would be changing the default font to Segoe UI in the browser, but this won't work with Chrome, as web code overrides default settings. Talskubilos (talk) 20:53, 25 December 2013 (UTC)

Lucida Sans Unicode is installed by default on XP. Arial Unicode MS is installed with Office and it's viewers since Office 2000, which means everyone with an office version has it. Segoe wasn't installed since Office 2007; that version has negligable install base on XP. — Edokter (talk) — 21:13, 25 December 2013 (UTC)

But aticles such as the one I mentioned, which use special symbols not supported by these fonts, can't be properly displayed unless we switch to Segoe UI. Actually, one *uncooperative* editor reverted my edits on the bases the template works on his Windows 7 system and the problem was in "my computer". Any help? Talskubilos (talk) 21:31, 25 December 2013 (UTC)

A switch to Segoe UI won't help unless the reader has that font installed, and on XP it has very low penetration. — Edokter (talk) — 21:33, 25 December 2013 (UTC)

Then what do you suggest to soklve this problem? Also some articles use a "PIE" template which apparently is synynoym to "Unicode". But neither Arial Unicode MS nor Lucida Sans Unicode support superscript and subscript in XP. Talskubilos (talk) 21:39, 25 December 2013 (UTC)

There is no easy solution. In the long term we may switch to using webfonts for IPA, provided there is a suitable webfont. — Edokter (talk) — 21:43, 25 December 2013 (UTC)
I suggest Gentium Plus. It has the proper license. — kwami (talk) 01:09, 9 February 2014 (UTC)
That font weighs 1.75MB(!) and is not available as a webfont. — Edokter (talk) — 10:45, 9 February 2014 (UTC)

Note that this code does nothing at all for me on Firefox 24: 

/**
 * Fix for Windows XP Unicode font rendering
 */
if ( navigator.appVersion.search(/windows nt 5/i) !== -1 ) {
    mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + 
                '.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );
}

because navigator.appVersion is "5.0 (Windows)". navigator.oscpu is "Windows NT 5.1" right now, but who knows how long that will last, given that the HTML living standard gives this warning:

Any information in this API that varies from user to user can be used to profile the user. In fact, if enough such information is available, a user can actually be uniquely identified. For this reason, user agent implementors are strongly urged to include as little information in this API as possible.

We might want to rethink the our strategy here. —SamB (talk) 02:20, 18 February 2014 (UTC)

  • Shouldn't that code be:
/**
 * Fix for Windows XP Unicode font rendering
 */
if ( navigator.appVersion.indexOf("Win") !== -1 && navigator.oscpu === "Windows NT 5.1" ) {
    mw.util.addCSS( '.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + 
                '.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ' );
}
Or something of that nature? — {{U|Technical 13}} (t • e • c) 02:38, 18 February 2014 (UTC)
No. The current code is intended to catch Windows XP only. But Firefox seems to strip navigator.appVersion of any usefull info, so Firefox skips this code. Luckely, Firefox is just about the only browser that has some decent Unicode support, even on XP, it will use any suitable font available. — Edokter (talk) — 23:47, 18 February 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_20&oldid=1109434504"