MediaWiki talk:Common.js/Archive 22

Archive 15

←

Archive 20

Archive 21

Archive 22

Archive 23

Default to moving subpages when moving a page

Tracked in Phabricator
Task T141545

There is consensus that when moving a page with admin or page mover rights, the default action should be to move all subpages. See discussion here: Wikipedia talk:Page mover#Moving subpages should be the default action. The confusion arises for example when moving an article whose Talk page has archives: the talk page itself and subpages of the article, if any, are moved, but subpages of the talk page are not, and this creates lots of work to detect the mistake and correct it after the fact, especially when talk pages have long archives. A personal setting in common.js has been made available, and we would like to apply a similar technique to the global common.js, so that the relevant checkbox is ticked by default. — JFG ^talk 13:33, 28 July 2016 (UTC)

This seems like something that should be solved in the configuration of the software and not in Common.js. Next to that, javascript that is only delivered to a single page, should generally not be part of Common.js, which is for things delivered to ALL pages. Please file a phabricator ticket. —TheDJ (talk • contribs) 15:51, 28 July 2016 (UTC)

Convert watchlist notices into a Resource Loader module

What about moving this script to a (default) gadget, such as MediaWiki:Gadget-watchlist-notices.js, so that its code can be minified and loaded by Resource Loader? This would be similar to what we did with MediaWiki:Gadget-geonotice-core.js. Helder 12:31, 26 June 2016 (UTC)

Sounds like a good idea. Same could be said for MediaWiki:Common.js/edit.js. -- [[User:Edokter]] {{talk}} 12:39, 26 June 2016 (UTC)

Sounds like a good idea (to keep this thread alive), but finding an admin to do it might be a bit tough. Enterprisey (talk!) _{(formerly APerson)} 01:13, 9 July 2016 (UTC)

@Enterprisey and He7d3r: Maybe you can ask on WP:VPT? I have had success at getting JavaScript knowledgeable people there.Jo-Jo Eumerus (talk, contributions) 20:23, 28 July 2016 (UTC)

The procedure would be like this:

1. Remove from MediaWiki:Common.js:

   else if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
/* watchlist scripts */
mw.loader.load( '/w/index.php?title=MediaWiki:Common.js/watchlist.js&action=raw&ctype=text/javascript' );
}

2. Create MediaWiki:Gadget-watchlist-notice.js with

   if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
mw.loader.load( 'ext.gadget.watchlist-notice-core' );
}

3. Move MediaWiki:Common.js/watchlist.js to MediaWiki:Gadget-watchlist-notice-core.js
4. Add to MediaWiki:Gadgets-definition:

   * watchlist-notice[ResourceLoader|default]|watchlist-notice.js
* watchlist-notice-core[ResourceLoader|hidden|rights=hidden]|watchlist-notice-core.js

5. Describe the gadget at MediaWiki:Gadget-watchlist-notice. E.g.:

   Add dismiss buttons to watchlist notices.

Helder 17:59, 7 August 2016 (UTC)

Done I've converted both MediaWiki:Common.js/watchlist.js and MediaWiki:Common.js/edit.js into gadgets. The former is at MediaWiki:Gadget-watchlist-notice.js and MediaWiki:Gadget-watchlist-notice-core.js, and the latter is at MediaWiki:Gadget-extra-toolbar-buttons.js and MediaWiki:Gadget-extra-toolbar-buttons-core.js. — Mr. Stradivarius ^{♪ talk ♪} 07:53, 23 August 2016 (UTC)

Thanks Mr. Stradivarius!

I noticed the MediaWiki:Gadget-extra-toolbar-buttons-core.js contains a small code which is unrelated to toolbar buttons (search for "Fix edit summary prompt for undo", at the end of the file). Was that intended? Helder 17:23, 7 September 2016 (UTC)

@He7d3r: I just moved the page without touching the code, as I assumed that everything in the file should run as it had before. It might be neater to put that snippet into another default gadget, I agree, as it's confusing for something labled as "additional edit buttons" to have unrelated functionality. — Mr. Stradivarius ^{♪ talk ♪} 00:20, 8 September 2016 (UTC)

Add editnotice

Following this unopposed proposal, {{Wikipedia information pages talk page editnotice}} was created and and manually applied to all pages in Category:Wikipedia information pages. However, the notice does not automatically appear on pages that are added to the category, which was my intent. I'm told that requires the addition of this script to common.js. Can someone please do this? Thanks, —swpb^T 20:10, 19 January 2017 (UTC)

 Not done swpb please establish a consensus here first (for using the site wide javascript to implement this). — xaosflux ^Talk 15:37, 20 January 2017 (UTC)

Can't a bot just throw it on those pages, why abuse the master javascript for something that will not impact most people? — xaosflux ^Talk 23:15, 19 January 2017 (UTC)

To editors Xaosflux and Enterprisey: I don't care how it's done, I just want it done. I already got a consensus for the behavior; it's very frustrating that it's this hard to get it implemented. If you think a bot is the best solution, I'll pursue that. —swpb^T 16:07, 20 January 2017 (UTC)

The "unopposed" proposal appears to have been contributed to by 2 editors, that is a bit lacking for updating the configuration that is used for every single reader and editor on every single page. Enterprisey do you have more insight in to this? — xaosflux ^Talk 18:47, 20 January 2017 (UTC)

Uh, sure. I originally thought a gadget would also have worked well for this job, since that automatically makes it configurable by users (if we decide not to make it hidden). Either way (gadget or common.js change), I think we at least need a VPT consensus, since this does impact quite how quite a few pages display. Enterprisey (talk!) 18:57, 20 January 2017 (UTC)

This is just a edit notice right? It can easily be added to the 200 pages as a template, no? — xaosflux ^Talk 19:00, 20 January 2017 (UTC)

The idea was to have it automatically appear, in the style of our existing "magic editnotices". Using a template is fine by me, if a little labor-intensive. Enterprisey (talk!) 22:00, 20 January 2017 (UTC)

Exactly. The existing {{Disambig editintro}} suggested to me that this would not be a problem. I'm perfectly happy to have this implemented by bot, gadget, or whatever. What I'm not happy with is for it to be held up on the basis of insufficient consensus, as I've said on my bot request. —swpb^T 15:32, 23 January 2017 (UTC)

The existing disambig (and blp) intro is there because doing it differently would be rather disruptive considering how many disambiguation pages and blp's we have. They are however also extremely annoying and from a long term technical support point of view, and we should avoiding new ones. Basically they are notices that we probably at some point have to fix inside the core software, and the more of them we have, the more migration cases we would likely end up with. —TheDJ (talk • contribs) 16:14, 23 January 2017 (UTC)

The sub cat Category:Wikipedia how-to shuold also have this.--Moxy (talk) 01:46, 8 March 2017 (UTC)

Protected edit request on 13 March 2017

please add the following code to MediaWiki:Common.js. it will replace <span class="insertusername"></span> with the user's username which can in turn be encorporated into the username template so it can be accessed with {{USERNAME}} this code is in action on The minecraft how-to wiki and loads the username when the page finishes loading Thank you Minion3665

/* Any JavaScript here will be loaded for all users on every page load. */
/* Replaces {{USERNAME}} with the name of the user browsing the page.
   Requires copying Template:USERNAME. */
function UserNameReplace() {
    if(typeof(disableUsernameReplace) != 'undefined' && disableUsernameReplace || wgUserName === null) return;
    $("span.insertusername").html(wgUserName);
 }
 addOnloadHook(UserNameReplace);
 
/* End of the {{USERNAME}} replacement */

Minion3665 (talk) 21:12, 13 March 2017 (UTC)

Not done: Consensus exists against its implementation — Train2104 (t • c) 21:23, 13 March 2017 (UTC)

Adding en.wp inner/outer/autocollapse to mw-collapisble

Please add the following fragment:

/**
 * Add support to mw-collapsible for autocollapse, innercollapse and outercollapse
 *
 * Maintainers: TheDJ
 */
function mwCollapsibleSetup( $collapsibleContent ) {
	var $element,
		autoCollapseThreshold = 2;
	$.each( $collapsibleContent, function (index, element) {
		$element = $( element );
		if ( index > autoCollapseThreshold && $element.hasClass( 'autocollapse' ) ) {
			$element.data( 'mw-collapsible' ).collapse();
		} else if ( $element.hasClass( 'innercollapse' ) ) {
			if ( $element.parents( '.outercollapse' ).length > 0 ) {
				$element.data( 'mw-collapsible' ).collapse();
			}
		}
	} );
}

mw.hook( 'wikipage.collapsibleContent' ).add( mwCollapsibleSetup );

Right below where it says:

mw.hook( 'wikipage.content' ).add( createCollapseButtons );

This will enable the core collapsing code to support the English Wikipedia specific collapsing structures. With this in place, we may at some time in the future begin to finally get rid of all the custom collapsing code we use in English Wikipedia. (long term goal, expect it to take years) —TheDJ (talk • contribs) 21:39, 18 October 2016 (UTC)

@TheDJ: done. Maybe time to request your admin tools back? — Martin (MSGJ · talk) 11:21, 20 October 2016 (UTC)

From what I can tell, this doesn't work. See here for an example. Any idea why? --Porplemontage (talk) 07:54, 25 March 2017 (UTC)

@Porplemontage: You are right, I had made a mistake in my interpretation of the original logic. Should be fixed now. —TheDJ (talk • contribs) 12:43, 25 March 2017 (UTC)

Cool, it works now. Just a heads up, if you want them both to trigger at 2, do $collapsibleContent.length >= autoCollapseThreshold. --Porplemontage (talk) 21:20, 25 March 2017 (UTC)

BTW. I've been looking into this a bit.. I wonder if it's not smarter to get rid of the autocollapse class. Maybe it is better to just have this behavior automatically on navbox'es and maybe of some tables if they are children of infobox or something. The whole autocollapse routine was always really weird in that it basically doesn't care about what you are collapsing. That's bad, because it means that one extra navbox at the bottom of a page, can suddenly collapse something totally unrelated in an infobox if you aren't careful. It's always annoyed me. —TheDJ (talk • contribs) 14:26, 25 March 2017 (UTC)