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:18, 6 June 2021 (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)

Stop using collapse shim

Should a bot be ran to update all remaining uses of collapse and etc mw-collapse so the shim can be removed from the common.js? — Preceding unsigned comment added by TerraCodes (talk • contribs) 11:11, 21 November 2018 (UTC)

In the mainspace, there are on the order of 50k uses. Those should probably be removed entirely per WP:MOSCOLLAPSE, not converted. --Izno (talk) 13:23, 21 November 2018 (UTC)
TerraCodes, eventually.. maybe.. I don't know. There is no real rush and template usages should probably be fixed before any other usages. But sometimes it can be difficult, as usages of the templates can often override the behavior via a parameter, so that would have to be taken into account. —TheDJ (talk • contribs) 13:54, 21 November 2018 (UTC)

Getting rid of deprecations

So it's very hard finding scripts that break, because we don't know who is using what. There are deprecation warnings in the console these days, but most users never see these of course, causing a particularly long and invisible long tail of failures for users. I've been thinking about this for a while now, esp. in order to get rid of the current getParamValue, hasClass and addPortletLink methods that we still have in our MediaWiki:common.css. So what I was thinking, is to send out popup notifications, with a link to a preloaded edit section on a dedicated noticeboard.

The following code shows an example for doing that for addPortletLink. 

function localDeprecate(obj, key, val, msg, logName) {
	mw.notify( $.parseHTML('Your wiki Javascript will soon stop working because it is using the outdated '
		+ encodeURIComponent( key )
		+ '. You can report at the <a href="/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard/helpme&action=edit&section=new&preload=Wikipedia:Interface_administrators%27_noticeboard/deprecationsTemplate' 
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( mw.config.get('wgUserName') )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( key )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( msg )
			+ '&preloadparams%5b%5d='
			+ encodeURIComponent( mw.config.get('skin') )
			+ '">noticeboard</a> to request assistence.'), {
		autoHide: false,
		type: 'warn'
	} );
    mw.log.deprecate( obj, key, val, msg, logName );
}

mw.loader.using('mediawiki.util', function() {
	localDeprecate( window, 'addPortletLink', mw.util.addPortletLink, 'Use mw.util.addPortletLink instead' );
	addPortletLink();
})

Opinions ? Improvements ? —TheDJ (talk • contribs) 13:28, 6 November 2018 (UTC)

Searching "insource:/[^\.]addPortletLink/ intitle:/\.js/" in userspace seems to work well enough to find uses of addPortletLink. There are quite a few uses, and IMO they should be reduced - at-least the most used scrips (like User:AndyZ/peerreviewer.js used by ore than 500 people) should be fixed - before anything like this is done to not cause a wave of annoyance. Maybe an intadmin can AWB/Bot over the 3000 pages found by the search replacing "addPortletLink" with "mw.util.addPorletLink"... Galobtter (pingó mió) 13:51, 6 November 2018 (UTC)
The problem is that many of these people and scripts aren't active any longer, making much of those pages a waste of effort to go through. The peerreview script you refer to is a prime example, where it's only mentioned in a comment for instance. And it's not a simple replacement either. You need to ensure mediawiki.util is loaded, and that the pageready hook has fired as well. That was the whole point, to reduce the load by focusing on those people actually affected by the problem. —TheDJ (talk • contribs) 16:11, 6 November 2018 (UTC)
Oops on that; but still, there are reasonably widely used scripts (User:Lifebaka/closedrv.js and User:Dr_pda/prosesizebytes.js, used by ~100 people each) that should be fixed first. Also, this code would appear to pop-up on every page that a portlet link is added? That would be pretty irritating if one has a script that adds a portlet link on most pages, and so you'd also have to explain how to remove the script from one's js until the portlet link issue is fixed. Galobtter (pingó mió) 20:14, 6 November 2018 (UTC)
This seems like a reasonable approach. Another approach would be to get a list of the most active users, get a list of those user's Javascript pages, and then scrape those for other scripts being loaded (with whatever calling functions) + direct calls to deprecated functions (and of course, consolidate final data so you have some final list of scripts to change). This is more work but takes care of the 95% of people who log in regularly. --Izno (talk) 23:21, 6 November 2018 (UTC)

According to the mwgrep tool there are 72 occurences in the MediaWiki namespaces (see Phab:P7768), and 9,567 occurences in user namespaces. ESanders (WMF) (talk) 19:39, 6 November 2018 (UTC)

I started some related work at User:TheDragonFire/Removing deprecated functions back in June if someone wants to collaborate. TheDragonFire (talk) 11:04, 22 December 2018 (UTC)

Interface-protected edit request on 21 December 2018

Please add the following code snippet to MediaWiki:Mobile.js. 

$('document').ready(function (){
var pageName = $('#mw-mf-diff-info a').text();
$('#mw-mf-diff-info a').attr('href',mw.util.getUrl(pageName));
});

This code snippet will get rid of an annoying bug which was introduced about a month or two ago into Special:MobileDiff where the link labelled as the page name led to an older version of the article instead of the article itself.  — fr + 08:18, 21 December 2018 (UTC)

Is there a consensus that this behavior is a bug/should be changed? It doesn't seem unreasonable that the link in the diff header takes you to the revision of the page in question; in fact, I wrote a script to do this myself for non-mobile diff pages. Writ Keeper ⚇♔ 22:36, 21 December 2018 (UTC)
WK, there isn't much of a consensus in the sense of the word but there have been two posts at WP:VPT, one by Capankajsmilyo [here] and by User:Ɱ [here] both of whom have asked for it to be changed. Additionally, I am sure that there are a lot of other people who would want this change because the introduction of this "feature" has disrupted certain workflows in the mobile interface. — fr + 10:44, 22 December 2018 (UTC)
I'm inclined to agree with Writ Keeper — I think this behavior is desired, and makes sense to me. It takes you to the full view of the page as of that revision, which seems like expected behavior. This proposal does, however, seem like a reasonable temporary fix for phab:T200969 until that gets fixed. ~ Amory (u • t • c) 10:57, 22 December 2018 (UTC)
As a frequent mobile contributor I find it quite useful to view specific revision of page, which was not possible before without going to desktop view, so I guess it's not a bug. Also latest revision can be visited by clicking page name in history. ‐‐1997kB (talk) 11:32, 22 December 2018 (UTC)
1997kB, whenever I use my phone, the first thing I do is to check my watchlist. When I click on the diff, I sometimes find that I would like to refine an editor's edit. However, I am unable to do that in one step, rather I have to make multiple clicks to get to an editable version of the article, which is not desirable. I agree that having a link to the specific revision is useful, but not in this poorly implemented format  — fr + 12:05, 22 December 2018 (UTC)
@FR30799386: I see, but instead of removing it we should request adding both link in diff viewer. ‐‐1997kB (talk) 12:27, 22 December 2018 (UTC)
 Not done: please establish a consensus for this alteration before using the {{edit interface-protected}} template. Izno (talk) 14:44, 22 December 2018 (UTC)
Izno, will I have to open a discussion at WP:VPT ? — fr + 17:40, 23 December 2018 (UTC)
FR30799386, that's one way. You can leave a comment there inviting editors here too. --Izno (talk) 02:09, 24 December 2018 (UTC)

Interface-protected edit request on 15 May 2019

Suggest adding the following: 

// Show diffs of modules and scripts in monospaced font
if( ['javascript', 'css', 'Scribunto'].indexOf(mw.config.get('wgPageContentModel')) !== -1 ) {
    $('td.diff-addedline, td.diff-deletedline, td.diff-context').css('font-family',"Consolas, 'Courier New', monospace");
}

It is easy for the eyes to look at diffs of code pages (CSS/JS/Scribunto) in monospaced font. All code editors use monospaced fonts after all. I've been using this in my common.js for quite some time. Felt that this would be useful for everyone. SD0001 (talk) 10:04, 15 May 2019 (UTC) SD0001 (talk) 10:04, 15 May 2019 (UTC)

not done. Things that are useful for such a small group of users should not require Js on every single page of the wiki. Pure CSS options or a patch to the core software seem much more suitable for this. —TheDJ (talk • contribs) 10:34, 15 May 2019 (UTC)
@TheDJ: Opened phab:T223429. SD0001 (talk) 09:38, 16 May 2019 (UTC)

Interface-protected edit request on 13 July 2019

I suggest importing meta:User:FR30799386/undo.js since mobile version of Wikipedia lacks undo feature. I originally nominated it to be a gadget on WP:VPT#Undo script. All information regarding it can be find on WP:VPT. Thanks. Masum Reza📞 09:16, 13 July 2019 (UTC)

I do not think that discussion indicates consensus to add additional Javascript to every mobile page load for all users. --Izno (talk) 13:20, 13 July 2019 (UTC)
In fact, given the sparse response, I'm pretty sure there's no consensus to add it even as a gadget. --Izno (talk) 13:23, 13 July 2019 (UTC)
 Not done mobile.js is loaded for every reader so adding functionality only useful for editors (and really not just the casual mobile 'fix something small' type editors) is overkill here. Continue your discussion to see if anyone wants it as an opt-in gadget first. — xaosflux Talk 13:38, 13 July 2019 (UTC)

Interface-protected edit request Mobile.js

The code in MediaWiki:Mobile.js relating to purging is outdated and should have been removed a long time ago. Jdlrobson (talk) 03:41, 15 July 2019 (UTC)

 On hold this was only added a few months ago, @Jon (WMF): can you respond to this? — xaosflux Talk 12:58, 15 July 2019 (UTC)
Xaosflux, he's the one requesting it ;) —TheDJ (talk • contribs) 13:21, 15 July 2019 (UTC)
@TheDJ: lol - @Jdlrobson: you added this with your staff account - do you want the entire script removed or only a part of it? If only a part, can you provide a sandbox of the new revision? (Or just revert your staff action with your staff account). — xaosflux Talk 14:19, 15 July 2019 (UTC)
it can be completely blanked. I wasn't at work yesterday so didn't have access to my staff account and this account doesnt have the sufficient permissions. Jdlrobson (talk) 19:37, 15 July 2019 (UTC)
Thank you,  Done — xaosflux Talk 19:39, 15 July 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_22&oldid=1027088084"