This is an archive of past discussions about MediaWiki:Common.js. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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
functioncreateNavigationBarToggleButton(){// ...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:
functioncreateNavigationBarToggleButton(){// ...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
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
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. — AlexSm18: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. --Locosepraix03: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. — AlexSm04: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')). --Locosepraix23:09, 6 March 2012 (UTC)
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)
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-heightmw.util.addCSS('@media print { sup, sub, p, .documentDescription { line-height: normal; } }');
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)
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 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. —MichaelZ. 2012-03-14 18:16 z
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? --Locosepraix18: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] —MichaelZ. 2012-03-18 19:34 z
Thank you. Please let me know how it goes, because we have some catching up to do on this front in en.Wiktionary. —MichaelZ. 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') {
}
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'
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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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. --Locosepraix09: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.
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. Helder13:30, 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? Helder17:31, 6 October 2012 (UTC)
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:
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)
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.
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
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)
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)
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){varrequire_wikiminiatlas=false;varcoord_filter=/geohack/;varkml_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 loopreturnfalse;}});$('table.metadata').find('a').each(function(key,link){if(link.href&&kml_filter.exec(link.href)){require_wikiminiatlas=true;// break from loopreturnfalse;}});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>
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)
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. --Dschwen22: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). --Dschwen22: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.
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). --Dschwen01:52, 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. --Dschwen17:11, 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. --Dschwen16: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)
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. --Dschwen21:44, 30 October 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)
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.
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)
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)talk17:10, 18 December 2012 (UTC)
The code [a-z0-9\.\\-] was chaged to [a-z0-9\.\-] because the "\" was scaping the other "\" instead of scaping the "-". Helder16:37, 26 December 2012 (UTC)
Do not create NavFrame buttons if the new class "mw-collapsible" is used
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Currently, the code which provides the Wikipedia:NavFrame functionality has a test like this
functioncreateNavigationBarToggleButton(){// ...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:
functioncreateNavigationBarToggleButton(){// ...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
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:
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)
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)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)
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.)
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)
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)
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)
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 );
}
}
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)
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)
/** * 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]] */functioninitializeRefTools(){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');});}elseif(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]] */functioninitializeRefTools(){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)
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)
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)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
On that patch, Nikerabbit recommends to instead check for elements where «The[re] is a lang attribute on the link inside». --Nemo13:58, 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. --Nemo16: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)
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
@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 - Talk19: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)
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)
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
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)
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:
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.
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 - Talk04:30, 30 January 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)
@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 - Talk19:34, 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-buttononly? 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)
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)
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)
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)
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)
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)
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 - Talk22: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)
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.
/** * 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"; } ');}
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)
