MediaWiki talk:Common.js

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Nemo bis (talk | contribs) at 16:05, 20 December 2013 (→‎LinkFA is broken: +re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

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)[reply]
This looks good to me. Kaldari (talk) 17:58, 7 June 2013 (UTC)[reply]
 Done. — Edokter (talk) — 18:32, 7 June 2013 (UTC)[reply]

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)[reply]

@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)[reply]
Done. —TheDJ (talk • contribs) 12:41, 24 July 2013 (UTC)[reply]

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: [1]. --se4598 (talk) 15:50, 7 June 2013 (UTC)[reply]
How long is the fix expected to be needed? — Edokter (talk) — 18:37, 7 June 2013 (UTC)[reply]
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)[reply]
 Done. LFaraone 15:20, 11 June 2013 (UTC)[reply]
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)[reply]
 Done. Kaldari (talk) 17:29, 19 June 2013 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

Is there some more documentation, ie. what events are available (outside content)? — Edokter (talk) — 13:21, 28 July 2013 (UTC)[reply]
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)[reply]
@TheDJ: could you backport this update from Commons now? Helder 20:40, 24 September 2013 (UTC)[reply]
@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)[reply]

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)[reply]

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)[reply]

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)[reply] 

mw.hook( 'wikipage.content' ).add( function() {
    if ( ( mw.loader.getState( 'jquery.ui.button' ) === 'registered'  ) && (  $( '.ui-button' ).length ) ) {
        mw.loader.load('jquery.ui.button');
    }
} );
Personally, I'd rather see the template fixed to not use jquery.ui.button styles. Anomie⚔ 13:37, 2 December 2013 (UTC)[reply]
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)[reply]
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)[reply]
Using JS to load CSS that has no dependency on JS is ugly. Anomie⚔ 22:18, 2 December 2013 (UTC)[reply]
It's also slower, and can be broken if the browser has javascript disabled. --Redrose64 (talk) 12:56, 3 December 2013 (UTC)[reply]
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)[reply]
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)[reply]
+1. That is what I suggested when the jQuery UI CSS was removed. Helder 09:18, 5 December 2013 (UTC)[reply]
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)[reply]
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)[reply]

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

I +1 that. Seems like a good idea. — Edokter (talk) — 21:13, 3 December 2013 (UTC)[reply]

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)[reply]

SidebarTranslate gadget is broken too. — Edokter (talk) — 21:39, 13 December 2013 (UTC)[reply]
Both issues now fixed. — Edokter (talk) — 22:15, 13 December 2013 (UTC)[reply]
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)[reply]

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)[reply]

Sorry, I don't quite follow. What is broken and what should be changed here? — Edokter (talk) — 20:24, 18 December 2013 (UTC)[reply]
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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js&oldid=586966577"