Jump to content

MediaWiki talk:Common.js/Archive 22

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< MediaWiki talk:Common.js
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 01:13, 23 February 2020 (Archiving 2 discussion(s) from MediaWiki talk:Common.js) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 15←Archive 20Archive 21Archive 22Archive 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, —swpbT 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. —swpbT 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. —swpbT 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)

Broken JavaScript

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)

Remove deprecated functions

There are still three deprecated functions being mapped to their modern versions (addPortletLink, getURLParamValue and hasClass). These have been there for over two years minimum, if not three. Can they finally be removed now? -- [[User:Edokter]] {{talk}} 19:34, 26 March 2016 (UTC)

Im checking with Krinkle if by any chance we have log events collected for these as well.I doubt they are still much in use, but if we do have those log events, it might allow us to confirm this before we disable. —TheDJ (talk • contribs) 18:37, 1 April 2016 (UTC)
I've now removed them. Most stuff got a lookover when we recently dropped all the other old stuff, so might as well bite the bullet. —TheDJ (talk • contribs) 19:42, 11 July 2017 (UTC)

Unused dependency

jquery.client is no longer required--Dixtosa (talk) 07:01, 14 August 2017 (UTC)

@Dixtosa: thx for reporting. —TheDJ (talk • contribs) 13:29, 8 September 2017 (UTC)

Bug or incompatibility between the Monobook skin and the Infobox template

I believe that there is a bug or incompatibility between the Monobook skin and the Infobox template. When I use Monobook, it messes up Template:Infobox. When I switch to another skin, the issue disappears.

— goethean 19:58, 22 November 2017 (UTC)

I'm in monobook and not having any issues with those pages. — xaosflux Talk 20:21, 22 November 2017 (UTC)
Try disabling your custom monobook enahncements at User:Goethean/monobook.js. — xaosflux Talk 20:22, 22 November 2017 (UTC)
Removing my custom monobook.js and then bypassing the cache seems to have fixed the issue. — goethean 21:42, 22 November 2017 (UTC)

WikiMiniAtlas

Tracked in Phabricator
Task T185797
Resolved

I'm disabling meta:WikiMiniAtlas for now as the server is crashed. Feel free to revert when service is restored. — xaosflux Talk 15:33, 27 January 2018 (UTC)

Edit Request

It seems that the JS that was removed in #Remove_deprecated_functions was added back, could it be removed? --Terra (talk) 22:55, 11 June 2018 (UTC)

TheDJ reverted himself because the functions are still widely used, shortly after he made that talk page edit, so it was never really removed. --Izno (talk) 23:21, 11 June 2018 (UTC)
Ah, thanks for explaining it. --Terra (talk) 23:28, 11 June 2018 (UTC)
We should really try that again sometime.. But i'm not sure if I have the time —TheDJ (talk • contribs) 09:10, 12 June 2018 (UTC)

Switching watchlist notices to use web storage instead of cookies

See: MediaWiki talk:Gadgets-definition#Switching_watchlist_notices_to_use_web_storage_instead_of_cookies. —TheDJ (talk • contribs) 09:02, 14 June 2018 (UTC)

Collapsing

So I have now replaced the collapsible code with a shim that transforms the older collapsibles to mw-collapsible code. I've been working on this and testing it out on test.wikipedia.org for quite a while and this should save us quite a bit of code. Replacing NavFrame is still not quite there yet, as I try to figure out the right way to deal with positioning the toggle. I hope to finish that somewhere in the next few weeks. The deprecation warnings I kept disabled for now, as I want to make sure this transition works 100% before encouraging people with such messages to switch the template code. —TheDJ (talk • contribs) 18:40, 2 June 2018 (UTC)

now reverted as there seems to be slight differences. Mw-collapsible positions the toggles in the right most cell of a table row, whereas collapsible seems to use the first th cell. I dont find that particularly logical but it seems that we have a few pages that depend on it and i cant fix that. Guess this will have to wait a couple more months —TheDJ (talk • contribs) 11:02, 3 June 2018 (UTC)
This refers to a discussion at Talk:List of highest-grossing films#Franchise table. PrimeHunter (talk) 12:13, 3 June 2018 (UTC)
I've figured out a workaround. This won't make it possible to use this technique when you convert it to mw-collapsible, but also doesn't break the shim. For now... —TheDJ (talk • contribs) 13:15, 3 June 2018 (UTC)
Thanks TheDJ. For the record, Impru20 made a possibly related report [1] with no example after your first edit and reverted after your second edit with summary "Nevermind, this has seemingly been solved". He edited Opinion polling for the next Spanish general election earlier so maybe it was about that. It seems OK now and looks best with show/hide in the first column as now. A minor issue: Some of the header cells use rowspan to display a color code for parties and this causes the tables to render with no bottom border for me in Firefox when they are collapsed and the second header row with the color codes is hidden. Example:
I don't know whether this behaviour is new. I see a bottom border in the same example when rowspan and second header row is removed:
Other browsers may ignore the issue and display normal borders in both cases. This happens in Microsoft Edge and Internet Explorer. I don't know whether any browser or other software does anything worse than omit the bottom border in a one-row table with rowspans. I guess the issue could be avoided if the collapse code removed rowspans from the remaining row but it may not be worth the effort. PrimeHunter (talk) 14:22, 3 June 2018 (UTC)
I cannot be certain without reverting, but based on interpreting the logic, it shouldn't be new behavior. This is border collapsing at play. Due to the hidden rows, which are part of the 'rowspan' block, an incomplete table is created if you hide those colorcodes and this will trigger undefined behavior of the border collapsing, creating this problem. You shouldn't use collapsible code on rowspans as collapsible only knows about the first row and the subsequent rows. —TheDJ (talk • contribs) 15:34, 3 June 2018 (UTC)

@TheDJ: Is the issue reported at User talk:Hhkohh#Squad templates related to this change? — JJMC89 (T·C) 04:05, 24 June 2018 (UTC)

@JJMC89: I dont know. Do you have a link to a page/revision with a specific template invocation where this occurs ? Because apparently half of the problems were fixed, making it hard for me to look at the problem. —TheDJ (talk • contribs) 06:44, 24 June 2018 (UTC)
@TheDJ: The navboxes at the bottom of Mihai Roman (footballer, born 1992) are both expanded instead of autocollapsed. — JJMC89 (T·C) 06:50, 24 June 2018 (UTC)
@JJMC89: Yes it was related. I previously interpreted the code as autocollapse kicking in at more than 2 collapsible elements, but it is actually 2 or more. Should be fixed now. —TheDJ (talk • contribs) 10:50, 24 June 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_22&oldid=942169478"