User:FeRDNYC/Administrative requests

From GodWiki
Jump to: navigation, search

A place to compose the text of issues needing administrative support, before pasting into the "Report a bug" box in the game interface. Also serves as a record of requests made, and possibly additional detail/reasoning that's too long to include in the bug-reporting field.

fullurl magic word is generating http URLs

Submitted: 2019-02-22; Completed: on or before 2019-02-25

The MediaWiki magic word fullurl:, which converts article titles into URLs, is outputting http URLs instead of https, despite the fact that GodWiki is an HTTPS everywhere website.

For example, {{fullurl:Godville}} While these links will technically work as they'll be automatically redirected, it makes more sense to generate secure HTTPS URLs right from the start.

This is governed by MediaWiki's $wgServer and $wgCanonicalServer configuration variables, which can be (in the case of $wgCanonicalServer, must be) set with an explicit protocol component to force generation of URLs with that protocol.

Excessive page width in desktop superhero game interface

Submitted: 2019-02-03

Not actually wiki-related, but the overall width of the game's superhero desktop-browser interface is forced by the .page_wrapper class being set to min-width: 995px. This causes horizontal scrollbars to appear when the browser content area is narrower than that width, even though the 3-column interface (as rendered) has a total width of just over 950px, meaning that a wide swath of empty white page area is the only thing accomplished by the .page_wrapper min-width.

Reducing that to .page_wrapper { min-width: 960px; } allows the window to be narrower without horizontal scrolling, while still fitting all of the game content.

(I already put that change into effect for myself via a userstyle, so it doesn't really matter to me whether it gets changed in the game CSS or not. But I submitted the suggestion anyway for the benefit of others.)

Bad viewport meta tag in WPTouch skin

It appears that the WPTouch mobile skin (only) is inserting the following <meta> tag on each page:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;" />

This causes the following error on Google Chrome's console:

Error parsing a meta element's content: ';' is not a valid key-value pair separator. Please use ',' instead.

As the error indicates and the Mozilla developer documentation confirms, the correct syntax is:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />

Diffs don't link to old revisions on mobile

Submitted: 2019-01-21

In the article history view on mobile (e.g. Special:History/Main Page), tapping an individual change will display the diff view for that change using a mobile diff view. For example, one particular previous edit to the Main Page is displayed at Special:MobileDiff/88718.

For editors viewing these previous diffs, for comparison purposes it can be extremely useful to see the full rendering of that specific old version of the page. In the desktop interface, this can be done by clicking a revision timestamp in the History list, or by clicking "Revision as of (time)" in the diff view — though the latter is not strictly necessary, as the desktop diff view automatically displays the old page rendering directly below the diff.

In the mobile view, the same thing would normally be possible from Special:MobileDiff by tapping on the page title — the title link would contain the ?oldid= reference corresponding to the "after" state of the displayed diff. However, while this works on Wikipedia, in the Godwiki Special:MobileDiff view this is not functioning. The Special:MobileDiff title link always goes to the current revision of the page. This leaves mobile editors with no reasonable way to view previous article revisions.

Illustrative comparison

The following comparison links can be viewed in any browser, mobile or desktop, for a practical demonstration of this issue.

Mobile-diff view of an English Wikipedia Help:Diff edit —
Note how tapping/clicking on the page title ("Help:Diff") above the "bytes added" line will link to the corresponding old version of the page:
Mobile-diff view of a Godwiki Main Page edit —
Note how tapping/clicking on the page title ("Main Page") above the "bytes added" line links to the current version of Main Page:

I have searched the MediaWiki documentation for configuration options or other methods by which this functionality would be changed, but come up empty-handed. Without being able to see the server code/configs, I don't know why the diff view is functioning differently on Godwiki. I only know that it is, and that difference is hampering the efforts of mobile editors.

Content obscured by infoboxes on mobile

Not Submitted because I'm tired of screaming into the void.

GodSourceRunner  reported a problem with missing headings in page rendering, on mobile — Punk Panther was used as an example. (In case the page gets modified to work around the issue, specifically this version of Punk Panther is displayed on mobile with the "Appearance" heading completely hidden behind the infobox.)

The issue is that the desktop skin (now also used for mobile) styles all heading levels with overflow:hidden — that makes sense on the desktop when you'd want excessively-long headings to be cut off instead of going on forever, but it's completely broken on mobile because it allows headings to render in negative space.

In my testing, adding a sensible min-width to the headings prevents them from completely obscuring themselves. Something like h1, h2, h3, h4, h5, h6 { min-width: 5em; } works around the obscured-headings problem on mobile, without causing issues on desktop.

Body text rendering into small spaces between the infobox and the page edge has also been a problem, given the lack of adequate responsive CSS on the wiki since the loss of the Minerva mobile skin. Paragraphs that begin with short words like "A" or "The" can also find themselves sneaking partly alongside floated content. See these screenshots from Terezka for an example. Adding a min-width to the general page content, so that paragraphs are prevented from squeezing themselves into small areas like that, may also be prudent.

Update: 14:17, 17 January 2019 (UTC)

My initial thought to solve this was to create the set of heading templates documented at {{Heading}}, to be used in place of the standard wikimarkup for headings when they would fall alongside floated content — because the templates create heading tags styled min-width: 15em;, the headings would be forced below the floated blocks on any display too narrow for them to fit alongside. But that required modifying each page where headings collided with infoboxes or other floated content.

So then I realized that my other creation, {{spacer}}, could unilaterally be used in each template which outputs floated content, so that the <div>...</div> it creates immediately follows the float, and it would have the same effect without having to modify the target page. The only down side will be a small amount of vertical whitespace added where the spacer falls, either immediately alongside the top of the floated block (on wide displays), or immediately beneath the floated block (on narrow displays). So, that's the fix I'm currently pursuing.

Double redirect Godville page

Not Submitted because meh.

Special:DoubleRedirects list, in addition to two User pages, a double redirect from "Godville (Town) → Godville → Godville (Disambiguation)". The confusing thing is, if you click on "Godville (Town)" you'll reach Godville (Town) which is very clearly not a redirect. The secret is in the URL.

The page listed as the start of a double-redirect chain is not Godville (Town), but rather has the title (url-encoded) "Godville_(Town)%C2%A0". This is apparently an invalid page name that MediaWiki automatically corrects to Godville (Town), making the redirect unreachable by normal users (and, therefore, unfixable by normal users). However, it's still there in the system. Ideally the page named "Godville_(Town)%C2%A0" should either be deleted or, failing that, updated to contain

#REDIRECT [[Godville (Disambiguation)]]
Update: 2019-04-16
The Ideabox page also has a clone, as it turns out, which is currently stuck on Special:UncategorizedPages. Fitting what's becoming a pattern, it seems, that phantom page is named "Ideabox%C2%A0".

Hiding of spurious Contents section on mobile

Submitted: 2019-01-09; not addressed

The mobile Vector skin shows a spurious level-2 "Contents" header (see this screenshot courtesy of User:S624) because — for whatever reason — the heading is still generated in the source, unlike the rest of the TOC contents:

<div id="toc" class="toc-mobile"><h2>Contents</h2></div>

However, since the toc-mobile class is only used in the mobile view of the Vector skin (WPTouch uses the toc class, same as desktop Vector), the spurious header can be hidden with this CSS:

div.toc-mobile { display: none; }

/* Or, for real paranoia */
div#toc.toc-mobile h2 { display: none; }

Deletion of unneeded categories

Submitted: 2018-12-15; Completed: 2018-12-17

The wiki had accumulated a number of redirects in the Categories namespace, pointing to other categories. Most of these categories were otherwise empty, the ones that were not I emptied.

It's natural that these would be created: Someone sees a red link in the category list, and thinks, "Oh, someone's trying to use the wrong category name. I'll redirect it to the right category for them." The problem is that category redirects DO NOT WORK the way you'd normally expect.

The only correct solution to a redlink (used-but-not-defined) category is to edit the page(s) attempting to use that category and remove it (or replace it with the correct category).

I have sequestered all of the former category redirects into Category:Marked for deletion, which can be reached from this URL:

Please administratively DELETE the 15 "Subcategories" in Category:Marked for deletion, as well as the page Category talk:Transportational skills ( )

If an administrator wanted to go through and delete the other pages in that category as well, I wouldn't complain. But that's kind of a chore, and their existence does not create technical problems. The existence of redirected- or deletion-marked CATEGORIES, however, does.

See the following Wikipedia help page section for details on the technical issues leading to this request:

"Do NOT create inter-category redirects, by adding a [redirect code] to a category page. Articles added to a 'redirected' category do not show up in the target category, preventing proper categorization. What's worse, since redirected categories do not become 'red links', editors won't be aware even when they add an article to a redirected category."