User:FeRDNYC/Administrative requests

From GodWiki
< User:FeRDNYC
Revision as of 14:17, 17 January 2019 by FeRDNYC (talk | contribs) (Content obscured by infoboxes on mobile: update)
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.

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)]]

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."