RuneScape:Administrative requests

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Shortcuts:
If you are reporting vandalism in progress, use this page.

What this page is for[edit source]

    • Protecting and unprotecting pages.
      Highly visible pages or content that may have links from outside websites are encouraged to have some level of protection. This should be done according to the RuneScape:Protection policy.
    • Moving protected pages and files.
      Due to misuse of the page move tool, some pages are protected from being renamed except by an administrator. If you can make a case for a page move, requests for the page move can happen here.
    • Minor edits to protected pages.
      This commonly applies to protected templates that can have a substantial impact on thousands of pages if they are changed, so caution is urged when they are modified.
    • Importing pages from another wiki.
      While seldom used for content on this wiki, this is an option that is available for bringing in content from another wiki and preserving its edit history, which requires administrator rights.
    • Hiding revisions and edit summaries.
      In the case of copyright violations, privacy violations, offensive material, etc., revisions may be hidden using Special:RevisionDelete.
    • General questions for the administrators.
      You will get a faster reply by joining our Discord server and asking there; however, you can still post here and the administrators will answer to the best of their abilities.

What this page is not for[edit source]

    • Requests for deletion.
      If you believe an article does not meet the wiki's standards, post on Requests for deletion. Spam, accidental page creations, and other similar issues should be tagged with {{D|Reason}}.
    • Issues that do not require administrator tools to resolve.
      Visit the user help page instead. If you're not sure if your problem requires an administrator, post it here.
    • Users who may be vandalising pages.
      Instead, please report the user on the Counter-Vandalism Unit.
    • Requests to become an administrator.
      If you are interested in learning what administrators do and how to become one, please visit Administrators for information on the role and Requests for adminship for the process of becoming an administrator.
    • Account deletion requests.
      This is not possible.
    • Account renaming requests.
      This is currently not possible.

Request Content Security Policy addition[edit source]

Please add https://platform.twitter.com to the content security policy to support embedded twitter histories. I have one on my User: page (and the js to load the history in my common.js). I believe this is a web server thing, not a MediaWiki thing, since the CSP is sent in an HTTP header, not as part of the HTML. According to my web console, the current CSP for runescape.wiki is

script-src https://runescape.wiki 'unsafe-inline' 'unsafe-eval' https://static.cloudflareinsights.com/beacon.min.js https://en.wikipedia.org https://commons.wikimedia.org https://www.mediawiki.org https://code.highcharts.com https://ajax.cloudflare.com/ https://cdnjs.cloudflare.com/ajax/libs/Chart.js/ https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.google-analytics.com https://www.googletagmanager.com https://*.weirdgloop.org https://*.runescape.wiki https://unpkg.com

Thanks. --Saftzie (talk) 01:04, 1 January 2020 (UTC)

  • Copying from my talk page....
    Is the request on RuneScape:Administrative requests still something necessary? couldn't see anything on your userpages. Seers headband 2 chathead.png Elessar2 (talk) 16:15, 29 February 2020 (UTC)
    Yes. The Twitter JS won't run, because the CSP prohibits it. Also, the widget is still there on my User: page. --Saftzie (talk) 23:34, 3 March 2020 (UTC)
@Saftzie Raised a PR to fix this, I'll update when it's merged. cqm talk 09:32, 7 March 2020 (UTC)
PR has been rejected by sysadmins on the basis that modifying the CSP for user scripts isn't a precedent they want to set. There's an open bug in MediaWiki to allow the CSP to be set on a per-user basis which would fix this. I also raised the question of re-adding the twitter tags we used to have on Wikia - at the time of the fork, no replacement was available. Since then the Wikia extension had been ported, so that's an option to explore. cqm talk 09:10, 8 March 2020 (UTC)
You can just use my JS, too. I doubt the extension does anything differently. Seriously, it just parses a tag, then runs JS from twitter.com. Do we not trust twitter.com? This seems like functionality the wiki could use on, say, the Main Page. --Saftzie (talk) 22:35, 10 March 2020 (UTC)
Just to add on here, even though this is old: we're currently looking to reduce our CSP a bit so don't expect expansions to it for the time being. Quest.png Gaz Lloyd 7:^]Events!99s 01:16, 22 April 2020 (UTC)

AbuseFilter rule 13[edit source]

AbuseFilter rule 13 (the warn-IPs-when-editing-in-userspace rule) currently has some exceptions for a few particular project-like pages. I feel like it would be more elegant (and more convenient for users who can't edit filters themselves) to let users somehow tag such pages themselves instead, and have that stop this filter from triggering - something like a mostly empty Template:NoWarnIP and replacing the filter's individual exceptions with something like | "{{NoWarnIP}}" in old_wikitext perhaps?

Also, as a side note, that filter uses the deprecated variable article_text, which should probably be replaced with page_title. -Hourglass (2011 Hallowe'en event) detail.png I Am Me Talk III The Spark.png- 19:17, 9 February 2020 (UTC)

I took a look in the code with regards to the deprecated variables and it appears that the REL1_31 branch (which I think we use as we're using mw 1.31.*) does not have these deprecations yet. It's harder to tell if the variables exist in that version, but I suspect not. Until we upgrade, I don't think we should update the abusefilters to avoid the deprecated variables. cqm talk 22:13, 4 April 2020 (UTC)
We do not support the new variable names yet (they throw syntax errors if you try). Quest.png Gaz Lloyd 7:^]Events!99s 01:16, 22 April 2020 (UTC)

pengLocations[edit source]

Whatever changes have been made to JS in the past week, pengLocations.js no longer runs. --Saftzie (talk) 00:47, 25 March 2020 (UTC)

@Saftzie I'm not seeing anything obvious that fixed this, but nonetheless it appears to now be working on Distractions and Diversions/Locations/Penguin Hide and Seek. Can you confirm or point to somewhere it's not working? cqm talk 22:01, 4 April 2020 (UTC)
It doesn't work for me. There are also no errors in my web console. Whatever has gone wrong, it appears to affect everything that loads as a gadget. --Saftzie (talk) 00:17, 8 April 2020 (UTC)

Fix switchfo boxes breaking Doogle maps[edit source]

Currently, the interactive maps become broken if you switch any switchfo box. Apparently, the leafletjs code isn't intended to gracefully support having its DOM container being ripped out from under it. However, there's a simple solution: Tell the Kartographer code to re-initialise all kartographer map frames on the page via emitting a wikipage.content event.

One efficient way to do this would be to modify MediaWiki:Gadget-switch-infobox.js's init() function to register a post-switch callback if a Kartographer map is detected at page load. In others, replace line 608 with the following:

608 		window.switchEventManager.applyDefaultVersion();
609 
610 		// reinitialize any kartographer map frames added due to a switch
611 		if ($('.infobox-switch .mw-kartographer-map').length
612 		 || $('.switch-infobox .mw-kartographer-map').length
613 		 || $('.rsw-synced-switch .mw-karographer-map').length) {
614 			window.switchEventManager.addPostSwitchEvent(function() {
615 				mw.hook('wikipage.content').fire($('#mw-content-text'))
616 			});
617 		}
618 }

MrDew (talk) 07:44, 29 May 2020 (UTC)

Edited code snippet to target the entire article contents in the event after realizing the Kartographer extension tears down all maps on the page and then only rebuilds the ones targeted by the event. MrDew (talk) 08:29, 29 May 2020 (UTC)
Done - Habblet (talk) 09:46, 29 May 2020 (UTC)

Fix #2: Electric boogaloo Calcs on article pages double-initing sortable tables[edit source]

MediaWiki:Gadget-calc-core.js's dispResult function is blindly assuming that the only sortable table in the entire DOM will be one that it has created during the course of displaying a calculator's result. For "Calculator:" pages, this is probably always true. For article pages that contain embedded calculators (example: Seren godbow)... this can be not true.

The jquery.tablesorter plugin from MediaWiki is rather dumb. If called multiple times on a given table, it will attach multiple click handlers to that same table. Proposed solution is to modify the calc code so that it only inits the tablesorter plugin on tables that haven't already been processed.

In MediaWiki:Gadget-calc-core.js, change line 795 to be this:

795                 $('table.sortable:not(.jquery-tablesorter)').tablesorter();

FWIW, there's similar code in MediaWiki:Gadget-perkcalc-core.js / MediaWiki:Gadget-perkcalc2-core.js that may or may not cause the same issue if used on other article pages with sortable tables. MrDew (talk) 14:40, 4 June 2020 (UTC)

I wonder if a better fix is to fire the mw content ready hook for the div we load the parsed content into (same as the recent kartographer/switchinfobox fix). cqm talk 15:05, 4 June 2020 (UTC)
As long as the calcs (et al.) are completely wiping the results container and creating new tables each time that hook gets called... that could also work. I say that because even MediaWiki's built-in mediawiki.page.ready resource doesn't do the above safety check of skipping .sortable tables that already have the .jquery-tablesorter class. MrDew (talk) 15:11, 4 June 2020 (UTC)

Make Chart.js work with form calculators[edit source]

Requesting the following JS changes to make form calculators work with Chart.js:

In MediaWiki:Gadget-calc-core.js in function dispResult add these lines

806 if ($('.rsw-chartjs-config').length) {
807     mw.loader.load('ext.gadget.Charts-core');
808 }

In MediaWiki:Gadget-Charts-core.js add

58 function addHook() {
59     mw.hook('rscalc.submit').add(init);
60     if (!window.charts) { 
61         init();
62     }
63 }

and change then(init, function(){console.error("Failed to load chart.js");}); to then(addHook, function(){console.error("Failed to load chart.js");});. Invention.pngCephHunter talkSlayer.png 23:56, 3 July 2020 (UTC)

Done, good stuff Quest.png Gaz Lloyd 7:^]Events!99s 04:09, 4 July 2020 (UTC)

Please add following to MediaWiki:Common.css[edit source]

Hi, I have added Chronotes functionality to Module:Currency upon a users request in the discord. I have already created Template:Chronotes but require the following to be added to MediaWiki:Common.css for the images to work.

.chronotes-10000 {
    background-image: url('filepath://Chronotes_10000.png');
    padding: 1px 0 1px 34px;
}

.chronotes-1000 {
    background-image: url('filepath://Chronotes_1000.png');
    padding: 1px 0 1px 34px;
}

.chronotes-250 {
    background-image: url('filepath://Chronotes_250.png');
    padding: 1px 0 1px 32px;
}

.chronotes-100 {
    background-image: url('filepath://Chronotes_100.png');
    padding: 1px 0px 1px 32px;
}

.chronotes-25 {
    background-image: url('filepath://Chronotes_25.png');
    padding-left: 32px;
}

.chronotes-5 {
    background-image: url('filepath://Chronotes_5.png');
    padding-left: 32px;
}

.chronotes-4 {
    background-image: url('filepath://Chronotes_4.png');
    padding-left: 30px;
}

.chronotes-3 {
    background-image: url('filepath://Chronotes_3.png');
    padding-left: 30px;
}

.chronotes-2 {
    background-image: url('filepath://Chronotes_2.png');
    padding-left: 30px;
}

.chronotes-1 {
    background-image: url('filepath://Chronotes_1.png');
    padding-left: 28px;
}

Thanks, Lava hawk.png BlackHawk (Talk)    13:16, 1 August 2020 (UTC)

Done Seers headband 2 chathead.png Elessar2 (talk) 13:24, 1 August 2020 (UTC)

Ele won't offset her top[edit source]

For those (oh so many) of us who have the "Sticky header" feature enabled in MediaWiki:Gadget-skinTogglesNew.js and use the API page to test API queries, the JS console gets spammed with errors whenever you scroll the page. This is caused by the gadget assuming targetEle found the head nav link container and trying to read its offsetTop during every scroll event. The API preview pages have no such element, hence the spam.

Could someone modify the gadget to correct this? One potential solution with minimal change would be to find this:

136 					  	var targetEle = document.getElementById("mw-head");

and after it add this:

137 					  	if (!targetEle) {
138                         	return;
139                         }

TIA - MrDew (talk) 07:56, 2 September 2020 (UTC)

Done Lava hawk.png BlackHawk (Talk)    08:08, 2 September 2020 (UTC)

Collapsible maps[edit source]

After seeing a recent attempt to make a decent number of interactive maps hidden behind a collapsed-by-default table fail, I thought it'd be nice to offer a solution to make that sort of thing possible. So, here's the code snippet that would enable this:

$( ".mw-collapsible-toggle" ).on( "click keypress", function() {
    const $this = $( this );
    
    if( $this.hasClass( "mw-collapsible-toggle-expanded" ) ) {
        mw.hook( "wikipage.content" ).fire(
            $( "a.mw-kartographer-map", $this.parents( ".mw-collapsible" ).first() ).parent()
        );
    }
} );

Assuming it's even desired at all, I'm not sure where it would best be placed to serve its purpose. It just needs to be run once after page load, and it seems rather wasteful to create an entire new gadget just for that small bit of code. Perhaps MediaWiki:Gadget-autocollapse.js could be abused? ¯\_(ツ)_/¯

MrDew (talk) 17:41, 9 September 2020 (UTC)

Deterministic order of execution for table-related gadgets/plugins[edit source]

I've experienced this problem before, but a recent message in #wiki-rs from another user spurred me to look into the problem that is the order of execution of three gadgets/plugins that deal with tables: the tablesorter jQuery plugin, the autosort gadget, and the lighttables gadget.

With the way the resource loader and/or different browsers behave, this execution order appears to be non-deterministic. This is a problem, because those three things actually have implicit timing dependencies: the autosort gadget can't autosort if the tablesorter plugin hasn't run yet, and the lighttables gadget will happily highlight rows regardless of whether or not the autosort gadget has changed the row orders yet.

The ideal solution would be to use mw.hook() to subscribe to/fire events in each of those three things. Unfortunately, the tablesorter plugin is a core component of MediaWiki, so editing it is more of a PITA that would require getting server techs involved, patching code that could cause merge conflicts with MW upgrades, etc. etc. Instead, I went with a slightly-less-ideal (but still 100% functional) solution where the autosort gadget will use a MutationObserver rather than a hook.

Here are the two changes I'm requesting:

TIA,
MrDew (talk) 16:43, 12 September 2020 (UTC)