Guild Wars 2 Wiki talk:Requests for technical administration

Archive

---

• 2008 - 2013
• 2013 - 2017

Adding the Popups Extension

Heya,

So some of you may know of it, but a while back wikipedia added support for a popup module (https://www.mediawiki.org/wiki/Extension:Popups) which creates a small overlayed box with the first few sentences of that page.

Now I bring this up, because in my opinions one of the most frequent issues I see on this wiki is people coming here, landing on a page, and feeling like they have to click on multiple pages to get whatever information they want for something minor like "Is this a sword or a dagger", "which event is the one I am looking for", etc. Now since we simply can't put all the information for everything everywhere, I think a good solution (or at least partial solution) would be to implement the module I described above.

Currently, one can reproduce the behavior on this wiki by adding a line in their common.js file (as done for example here)

Now at the moment, implementing it this way works pretty well for area pages, generic info pages, events, and some item pages. The extension also works wonderfully for the `hist` and `diff` on the Recent Changes page.

At the moment, it does "fail" (i.e give pointless info) for item pages with no sentences at the start of the page (like most ingredient items). It also really messes up when hovering over a custom user page (say a custom.js page).

I did take a few screenshots which are in this album if you want to see here

From a first glance, it would seem ideal to either take this extension and modify it to show all (most?) pages properly with a few extra conditions, or to build an extra module upon this extension (perhaps a more stable option?)

Now Chieftain Alex tells me that this extension depends also on a 2nd extension which we do not have (https://www.mediawiki.org/wiki/Extension:PageImages). Due to this there may be a need to maintain these extensions if mw updates break things, and misc tweaks may need to happen.

So at this point I've been going on long enough, I'm not 100% sure what the next step is, so I'll end my rambling and leave it at that.

p.s Inc here's another link to the Prezi you forced me to make. -Darqam 08:33, 29 October 2018 (UTC)

I think we should roll this out as an opt-in beta. It'll give us a chance to debug it for our wiki and check for any unforeseen issues. It'll also allow us to break the feature as we try to adapt or expand it, without bothering our larger user base. G R E E N E R 17:26, 6 November 2018 (UTC)

would you have to click or hover for these pop-ups? I feel like it might make certain pages annoying if everywhere you hovered you got a tool-tip pop-up. That said, as long as we can limit the amount of text displayed and what links actually display the tool-tip pop up, I'm game to try a beta of it.--Rain Spell (talk) 01:21, 7 November 2018 (UTC)

If it's similar to what Wikipedia uses, the hover box would only appear over links, which to be honest, I quite love. - Do_odleplex 02:27, 7 November 2018 (UTC)

The pop-ups are on hover, however you do need to be hovering over a link for ~1 second, it doesn't appear instantly so you aren't spammed with them as you move your cursor. They also seem to take between 1-2 seconds (I think it's 1s and my pc is just slow today) for it to go away after you move your cursor off the link or outside the pop-up. You can also click elsewhere on the page for it to vanish right away.

So far I've been running this for a while, and there have been a few cases where it blocked me a little due to not realizing I put my cursor at rest on a link, but in my opinion the benefits of it outweigh the few minor annoyances.

I wouldn't be opposed to increasing the the timeout a tiny bit before the boxes popup, but anything more than 2 seconds would just feel too long. 1.25s or 1.5s still feels acceptable for me. -Darqam 08:49, 7 November 2018 (UTC)

Sorting pages with numbers

The setting $wgCategoryCollation controls the algorithm used for sorting categories and $smwgEntityCollation controls sorting queries. I'm guessing both are still using the default setting uppercase. I propose changing both of them to numeric. The reason for this change is that articles with numbers in their names aren't being sorted appropriately right now. For example, Category: Infusions sorts 10-19 before 2. The nav in Hunter's Journal also sorts like this. Changing the settings would make them sort correctly. --BuffsEverywhere (talk) 10:07, 25 February 2019 (UTC)

I'd like to reopen this discussion and get this changed. --BuffsEverywhere (talk) 09:39, 25 September 2021 (UTC)

Seems reasonable. —Kvothe (talk) 12:24, 25 September 2021 (UTC)

Can't we just set set {{DEFAULTSORT:0N Agony Infusion}} for N = 1..9? --Tolkyria (talk) 09:07, 27 September 2021 (UTC)

As written by BuffsEverywhere it would also fix e.g. Hunter's Journal nav order. Question is: Is there an instance where we would not want numeric sorting. —Kvothe (talk) 10:37, 27 September 2021 (UTC)

Just to say I support this suggestion. Kvothe please add it onto the requests page (Create a subpage, identify the changes required and any pitfalls - use mw docs to inform you). -Chieftain Alex 23:12, 30 September 2021 (UTC)

I wanted to let you all know I've seen this request and I'm reviewing the details. It requires running the maintenance scripts updateCollation.php and updateEntityCollation.php, which should run in the background without any downtime. The first script is also invoked by the update.php script that will be run during the downtime of the upcoming 1.36 upgrade, but I'm not sure if that's the case for the second script. However, in the spirit of not making too many changes at once, I am inclined to wait until after 1.36 is live and any potential immediate concerns have been handled. Justin Lloyd (talk) 15:37, 4 October 2021 (UTC)

I'm writing my procedure documentation for implementing the collation changes for after the 1.36 upgrade and I need a clarification. Should each wiki's collation algorithm be set to the wiki-specific language code or should they all use en? That is, should the German wiki use uca-de-u-kn, French uca-fr-u-kn, and Spanish usa-es-u-kn? Justin Lloyd (talk) 12:10, 6 October 2021 (UTC)

Either check with the other wikis over email or assume they don't want it imo. -Chieftain Alex 21:07, 6 October 2021 (UTC)

By the way, smw:Help:Type Text still sorts alphabetically and not numerically which affects the property Has item value (see this change) in Template:Vendor query table (parameters min cost and max cost). We might want to get rid of these template parameters.

See also Guild Wars 2 Wiki:Requests for technical administration/Collation. --Tolkyria (talk) 17:15, 6 April 2022 (UTC)

Enabling video files

So this topic came up on the Discord a couple weeks ago that I've been meaning to bring up for proper discussion on the wiki. We use animated GIFs in a few places around the wiki where static pictures don't adequately show things, for example cosmetic auras such as File:Transcendence_animation.gif or finishers such as File:Spectre_Finisher.gif. The particular discussion was related to the new Celebratory Birthday Enrichment and getting a decent GIF within the file upload limit (8mb). This is because the GIF file format, while capable of showing animation, wasn't actually designed to and is horrendously inefficient at it (see w:GIF#Animation_formats for further background). This means even short, low-quality videos make for very large filesizes in GIF.

Wikipedia uses WebM and Ogg Theora for their video needs (see w:Wikipedia:Creation_and_usage_of_media_files#Video for details), as these free and open formats are capable of higher quality at much smaller file sizes. Looks like Wikipedia uses Extension:TimedMediaHandler to enable their display in articles. We would also need to add .webm and .ogv to our Manual:$wgFileExtensions to allow uploading those file types.

Thoughts? Do we want this, or is our current situation with animated GIFs 'good enough'? Any of our more technically-minded users see potential problems I don't? Of course there's the possibility of misuse, someone uploading something inappropriate for the wiki, but given that that's already equally possible for currently-available uploads and hasn't been a significant problem to date, I'm not too worried about it. One already needs to be autoconfirmed to upload, and there are generally enough nosy people around RecentChanges to notice if something needs dealing with. - Tanetris (talk) 12:41, 11 September 2020 (UTC)

Gifs are terrible and never impress like the ingame animations do. If the files are smaller too then it seems like a no brainer.

I can't imagine we'll have a flood of video files submitted due to the annoyance of creating them. We might want to consider creating a guide if we do get the extension installed (use windows game bar, then ffmpeg to create .webm?) -Chieftain Alex 21:32, 11 September 2020 (UTC)

Allowing webm definitely makes sense nowadays. I remember “back in the days” we considered something like this before (especially for sound files) but we would have had to use Flash back then for playback. Since there’s now browser support for native videos, we don’t have that issue any more, so the only issue left is content moderation which already applies to images and GIFs anyway.

If we want to show some video content on the wiki, then yes we should prefer e.g. webm/VP9 over GIFs for multiple reasons (size, quality, and ease of creation). poke | talk 23:01, 12 September 2020 (UTC)

Depending on what program they're using to capture (I don't know about windows game bar, don't have Win10), they may be able to save out directly to webm. And if someone already has a fancier video editing program (e.g. for cropping and the like, unless their capture tool has that built-in) that may be able to save to webm too. Else, other video formats can be converted to webm using ffmpeg, yeah. I played around a bit with XMedia Recode (a GUI frontend for ffmpeg) and it seems to do the trick just fine for those not comfortable with commandline, and can even do some simple editing. - Tanetris (talk) 14:30, 14 September 2020 (UTC)

ffmpeg -i whatever-source-file.avi target-filename.webm is really all that’s necessary in its most-basic form. The source file can be pretty much any container/codec combination (e.g. avi, mp4, wmv). poke | talk 21:40, 14 September 2020 (UTC)

Just to note it here, it turns out the extension can be configured to support mp4 as well (which is what Windows Game Bar spits out by default from my googling, and is otherwise an extremely commonly-used format), so no conversion would be necessary. This has been included in the request. - Tanetris (talk) 19:26, 8 December 2020 (UTC)

This will be done when? Just joking, but it would really be nice to have it and I hope it's not forgotten. ~Sime 16:46, 10 May 2021 (UTC)

mw:Extension:MultimediaViewer

Currently the wiki users will experience one of the four following variants when clicking an image:

1. Redirect to the file page
2. Semantic mediawiki format gallery: opening a centered fancybox, with caption and navigation arrows appearing while hovering. E.g. used in the template Weapon set gallery.
3. Widget [[Widget:Gallery|Gallery]]: opening a top-left box without navigation arrows.
4. Widget [[Widget:Fullscreen images|Fullscreen images]]: opening a top-left box with navigation arrows.

In order to provide the wiki users one consistent image viewing experience, I suggest to add the commonly used extension mw:Extension:MultimediaViewer: "The MultimediaViewer extension gives the user of a wiki a different interface for viewing full-size, or nearly full-size, images in their browser without extraneous page loads or confusing interstitial pages." --Tolkyria (talk) 10:20, 2 October 2020 (UTC)

Hi, Tolkyria. I'm certainly amenable to adding this standard extension, though I have a question. The extension's installation notes suggest using the BetaFeatures extension as well to allow users to disable it as a preference, and it also recommends the CommonsMetadata extension. Do you have any preference (no pun intended) one way or the other regarding the use of BetaFeatures? Regardless, I can test this on the dev wikis next week after I deploy the 1.34.4 update, one thing at a time and all that. Let me know what you think. Justin Lloyd (talk) 10:47, 2 October 2020 (UTC)

Thanks for this quick feedback. I would enable this extension on default, because leaving the page (i.e. redirecting to the file namespace) to view the image in full size is nearly always interrupting. E.g. achievement collection guides with several images, one map image and one location screenshot for each collection item; or simply checking a concept art image on a lore page,... That's what the two widgets I stated above have been designed for.

Before adding an official request, I would like to ask the community if there are any remarks or objections. --Tolkyria (talk) 11:49, 2 October 2020 (UTC)

I would welcome a consistent image experience (making the extension default). I can't quite tell, does the extension provide a link to the image for easy editing like it was added to [[Widget:Fullscreen images|Fullscreen images]]? —Kvothe (talk) 15:19, 2 October 2020 (UTC)

Yeah replacing those widgets with an extension makes some sense in providing a consistent presentation... my only concerns would be (1) whether it treats the "icons" that we sprinkle so effortlessly over every page would also be included in the mediaviewer + (2) how it responds to images which already link to pages. Have a look at https://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo for an example.

Responding to Justin's questions:

• Betafeatures - I suppose having the ability to disable the gallery view based on login preferences would be kind of useful. I'd support having this available. (3) I should note I think the extension remembers the preference with your cookies or something too even without this extension. I suggest we could try with betafeatures and see if its ok.
• CommonsMetadata - no this only provides information for images used from mediawiki commons, and as we upload all our images locally is useless to us on gw2w.

I'll have a look at the extension source in the meantime. -Chieftain Alex 16:33, 2 October 2020 (UTC)

Answering (1), "MultimediaViewer\resources\mmv.bootstrap\mmv.bootstrap.js" has a function named MMVB.isAllowedThumb. This checks for a couple of CSS classes, namely .metadata and .noviewer among others. So we can switch the viewer off if we wrap the icon templates in a metadata class for example.

Now got an answer for (2) too - I added a test to that page under https://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo#Behaviour_for_linked_images - if you specify the link parameter then it doesn't bother with the preview gallery box.

(3) preferences are stored ("MultimediaViewer\resources\mmv.bootstrap\mmv.Config.js") with localStorage html5 under the name "wgMediaViewerOnClick" key-value pair, so would be cleared when a user clears their cookies etc. -Chieftain Alex 16:57, 2 October 2020 (UTC)

Kvothe, mw:Help:Extension:Media Viewer#How can I bypass Media Viewer?: No small icon on the top left, but Ctrl + left click opens the image in a new tab.

Icon templates are always linked, hence they shouldn't make any problem, even without css (same behaviour as your widgets); only the infobox icon on the top right would need an exclusion (e.g. by setting the link to the file page, again no css needed). --Tolkyria (talk) 17:34, 2 October 2020 (UTC)

I don't think it's a terrible idea to set the entire infoboxes as metadata anyway. -Chieftain Alex 17:41, 2 October 2020 (UTC)

Removal of the broken mw:extension:TitleKey and replacement with something that works

I'm thinking two separate requests here, the first is to just straight up remove the existing broken search extension. I'd like to check if searching in other namespaces works after doing that.

Then we should consider how best to provide a better search tool for the wiki. Personally I like the idea of copying what wikipedia uses, so to quote Tolkyria on Guild Wars 2 Wiki:Reporting wiki bugs#Autocompletion on search box uses Article (or Special) namespace only: "what about: mw:Extension:Elastica, mw:Extension:CirrusSearch and mw:Extension:AdvancedSearch, used by many wikis, e.g. wikipedia and mediawiki. See here for the provided features: mw:Help:CirrusSearch, but most importantly: we would be able to see namespace previews. Whether we want to browse templates or properties as wiki editor, files or categories as wiki user, right now it's quite tedious to find them without any preview." → i.e. i suggest we install all 3 of the suggested extensions.

I'd like any thoughts or comments before I just bung a technical request in. -Chieftain Alex 21:02, 7 December 2020 (UTC)

I'm kinda biased, but I want to point out once again that especially wiki editing without autocompletion preview outside mainspace is quite tedious. No matter if it's searching files, categories or templates, currently I'm relying on my browser address bar and have to hope that I already visited this wiki page once. For wiki users it's probably not that disturbing, they visit mainspace mostly (probably wiki users are interested in user guides of files), but nevertheless it's not very representative for the wiki if the autocompletion doesn't work.

Also the advanced search options, which are provided by the mentioned extensions, should be handy, right now the fulltext search is limited to "<exact text>".

Support. --Tolkyria (talk) 23:31, 7 December 2020 (UTC)

Yes please. --BuffsEverywhere (talk) 08:56, 8 December 2020 (UTC)

Request raised. -Chieftain Alex 19:29, 8 December 2020 (UTC)

The new search is amazing! Incredibly fast and powerful (see mw:Help:CirrusSearch). Edit: And not to forget, we got autocompletion back outside mainspace. --Tolkyria (talk) 13:58, 1 September 2021 (UTC)

I'm happy to hear you're pleased with the results! This was a significant backend change that I couldn't really test under full load conditions, so it's gratifying to finally see it in action and working well. As for autocompletion outside of Main, that's due to the removal of TitleKey as well. I know that's been problematic, so I'm glad we were able to knock out both problems at the same time. Justin Lloyd (talk) 14:18, 1 September 2021 (UTC)

(serves me right for not looking at the test version) Now that the hard bit is done, could we take a look at enabling mw:Extension:AdvancedSearch? -Chieftain Alex 16:53, 1 September 2021 (UTC)

Enabling Watchlist Expiry

It was requested awhile back that we get optional temporary watchlists like Wikipedia has, but we were a version short at the time. We are now on a sufficient version, but $wgWatchlistExpiry needs to be set True to enable it and comes False by default. Anyone see an issue with requesting this? Looks like Wikipedia and associated have been using it since December. From the help file it doesn't look like it would be obtrusive either. I see no particular downside. - Tanetris (talk) 17:40, 13 May 2021 (UTC)

So long as this doesn't affect people who've had things in their watchlist and don't need to re-set them I don't see a reason not to from a user perspective. -Darqam 14:22, 21 May 2021 (UTC)

Well my understanding is by default pages will stay as "permanent" watchlist items, so I don't have an issue endorsing this request. Submit away...-Chieftain Alex 16:38, 21 May 2021 (UTC)

Seems like a lovely idea to me, I'm all for it. =) - Do_odleplex 02:32, 22 May 2021 (UTC)

No downsides - I agree with the addition. —Kvothe (talk) 14:42, 22 May 2021 (UTC)

A quick update (6/22/2021)

Hi everyone,

Sorry for the lack of response here (and thanks to Tanetris for bumping that request in Discord!)

Watchlist Expiry and MultimediaViewer will be released on Thursday at 5 AM PT!

Our engineer (Justin) has already started investigating changing the Search engine of wikis. This is a ton of work, as he’s looking at current techs and the impact this would have on the rest of the wiki infrastructure, so this won’t happen soon but we hope it’s in the not-too far future.

About Enabling Video Files: we think that this is a bigger project than we can currently handle. There are various things to take into consideration as we enable files that are larger and have to be delivered to many wiki readers. Our priorities are currently the search engine and upgrade MediaWiki, in particular as EN editors reported some noticeable wiki slowness since our last update a few months ago, so we want to be careful about the changes we introduce.

Let me know if you have comments or questions! --Stephane Lo Presti talk 21:03, 22 June 2021 (UTC)

Hi, thanks for the update! I wonder if you could also add Watchlist Expiry to the Guild Wars (1) wiki? Or should I make a separate request for it over there? -- kazerniel (talk | contribs) 10:17, 23 June 2021 (UTC)

Hi, Kazerniel. Yes, I'd already planned on doing that so there's no need for a separate request. Justin Lloyd (talk) 10:28, 23 June 2021 (UTC)

Hi all, the new extension and the watchlist expiry settings have been deployed to the live wikis. Note that people will likely need to clear their cookies on a per-wiki basis for MultimediaViewer to work for them. Let me know here or through the Guild_Wars_2_Wiki:Reporting_wiki_bugs page if there are any issues with these features. Justin Lloyd (talk) 12:09, 24 June 2021 (UTC)

Thanks! Once again, I think the MultimediaViewer heavily improves the wiki user experience in terms of consistent image viewing. There was always a need to view the image in full size but without leaving the current page to the file page; thus we got several ways to do but all were using different formats, mixed with pages where none of these applied and the image redirected file space. Now it's consistently bundled by one extension.

Up to some minor smw issues in connection with the MultimediaViewer, which can be somehow bypassed (see bug reports), I haven't found anything going wrong yet. --Tolkyria (talk) 12:01, 25 June 2021 (UTC)

Increased purge rate limit for patrol (extended editors) group

dJemba made the following request on the discord. Can we discuss it here to see if there's any objections?

"could I ask for increasing the limit of action throttling for extended editors (or not counting null edits)? I run into issues with it often when i null edit stuff with the edit robot due to some smw stuff."

"purge with edit robot. happens after ~30 pages"

It looks like configuration of this would be possible via mw:Manual:$wgRateLimits. The default values for purge operations are:

	// Purging pages
	'purge' => [
		'ip' => [ 30, 60 ],
		'user' => [ 30, 60 ],
	],
	// Purges of link tables
	'linkpurge' => [
		'ip' => [ 30, 60 ],
		'user' => [ 30, 60 ],
	],

I don't know what rate limit would be acceptable to everyone, but I'm thinking maybe bump from 30 purge per minute to 100 purge per minute for extended editors.

		'patrol' => [ 100, 60 ],

-Chieftain Alex 09:56, 11 September 2022 (UTC)

I rarely find myself purging pages, let alone 30; so i can't exactly relate, but i'm wondering what this "smw stuff" is and whether it would make more sense if the bot be limited to only do 30 actions/min. instead? If not, then i'd be for 90 instead of 100, since this seems to be the default used for page edits and it's also the most permissible default limit, save for the thumbnail rendering limits. Nightsky (talk) 21:50, 11 September 2022 (UTC)

Essentially any time I update some bigger template, I would like to see if it works everywhere, but due to SMW i would either have to wait a day for all the pages to update, or null edit/purge them with edit robot; when the template is big enough so that hundreds of pages get affected, I can't easily purge all of them to see if it is working properly. DJemba (talk) 16:07, 12 September 2022 (UTC)

I support this request. —Kvothe (talk) 11:44, 15 September 2022 (UTC)