Talk:Main Page/Archive

From GodWiki
< Talk:Main Page
Revision as of 08:49, 4 August 2018 by FeRDNYC (talk | contribs) (Decided to archive my original mobile-formatting proposal, now that it's being implemented (w/ updates on talk page). Promoted year headings to (normally-verboten) level 1, so that archived sections can be nested under them without having to be edited.)
Jump to navigation Jump to search


Love the new main page! Thanks Spode


Sorry for the complete lack of wiki experience, but I logged in today and noticed that the main page had been blanked. I reverted to the latest non-blank instance I found, if that is not the proper procedure, please let me know and fix it correctly. My edit doesn't have the random picture set up correctly. Same thing with this edit, I'm brand new at this, any information on the "proper" way to use the talk page would be appreciated. -Function

This wiki needs a lot of work. Most of the articles here are rubbish. There are about 900 articles total, but about 700 are guild pages (most of which are only a few lines long). Another 100 or so have been marked for deletion because they aren't related to the game. That leaves about 100 pages of actual real game content. Moreover, a ton of the articles don't have categories. I've been trying to add categories, but I can't do it alone. Ultimately, we just need people to write articles on game subjects and stop writing guild articles. Wanna see what I've done, click here. I've given up writing summaries of my edits too. -–BlueStapler

The article count on the main page appears to be wrong. Right now, it says there are 961 articles. I think this number is too low. Specifically, there are 874 "Guilds" articles and 164 "Monsters" articles. Those two combined equal 1038 articles (which is obviously more than 961). I also know that articles from those two categories don't overlap because I've looked at nearly all of them. Add in all the other articles that have been categorized and I estimate there are around 2000 articles. -–BlueStapler

What was the purpose of the 2 September 2012 changes? --BlueStapler 11:14, 2 September 2012 (BST)

Why were the "Picture of the Day" and the "You will be logged in automatically . . ." language removed yesterday? Since I didn't see an explanation of why they were removed, I put them back by reverting to the 15 September 2012 version of the page. If they were removed for a purpose, sorry. Feel free to just undo my 29 September 2012 edits. --BlueStapler 03:51, 29 September 2012 (BST)


im requesting a article about this game to wikipedia about this game hopefully editors in wikipedia with the experience to start one will notice --Hanz24 (talk) 18:59, 13 April 2016 (UTC)Hanz24

Sidebar problem

The "Main page" link on the sidebar is actually a link to "INVALID-PAGE," which in turn is a redirect to the appropriate Main_Page link. This seems like it should be fine, but it has the unfortunate side effect of leaving "Redirected from INVALID-TITLE" at the top of the main page after you've used the link. It also causes problems with namespaces, which you can see if you visit a page under a different namespace and then click on "Main page."

I'm not sure how to fix this, so if someone with sufficient rights could check this out, that would be great. Benjamaster1 (talk) 22:48, 18 February 2016 (UTC)

So, it turns out that the redirect through INVALID-TITLE happens because someone set the mainpage System Message to an empty string. This message, which is meant to contain the title of the main wiki page, and which the sidebar _uses_ to create its link to the main page, cannot be blank because that is, in fact, an invalid title.
Why that was done, one can only guess. My suspicion is that it was an attempt to get Main Page to show up without a title at the top of the page — which, you'll notice, didn't work since the title still shows as 'Main Page'. But whatever the reason, it doesn't work as intended due to the fact that the invalid title causes MediaWiki to revert back to its default string, and it should really be reset to clear up these issues. But, only a wiki admin can do that. -- FeRDNYC (talk) 13:14, 31 July 2018 (UTC)
Impressive sleuthing to discover that's the issue without actually having said admin access. Hopefully this will help the Hypothetical Future Admin resolve the issue quickly and easily at some point in future! --Djonni (talk) 08:56, 2 August 2018 (UTC)
I submitted a note about the issue, and a pointer to this discussion, via the Ideabox "fix a bug" option, so hopefully that'll get some attention from Godville admins. -- FeRDNYC (talk) 23:26, 2 August 2018 (UTC)
Well thanks to your investigation and bug report this issue appears to have been fixed! Thank you GodGodville  and GodFeRDNYC !
I'm moving this topic to the archive as it's resolved. --Djonni (talk) 05:41, 4 August 2018 (UTC)


It would be great if the Omnibus List could be returned to drop down boxes instead of this ugly jumbled lists which are not mobile friendly that User:Rizizuns broke. --ICancerous (talk) 03:09, 7 July 2017 (UTC)

Archiving this since the Omnibus layout has since been redone. You will also, in fact, find the Omnibus List talk page has an active discussion of potential future changes to the Omnibus' structure. --Djonni (talk) 09:04, 9 June 2018 (UTC)


Formatting Infoboxes in the mobile view

I'm considering a rather radical change to how the formatting is done to embed Infoboxes in wiki articles. (Infoboxes are the boxes in the upper-right corner of many articles, generated via templates like {{Monster}} or {{Town}}, that present some basic stats common to articles of that type in a structured format.) This change would hopefully be virtually invisible in the desktop view, but it would greatly affect the mobile skin, for reasons I'll explain.

So, because this would be such a big change, I wanted to seek out input and feedback on both the theoretical and practical aspects:

  1. The idea itself
    Do people feel this is actually an improvement, or do they prefer the way it is now?
  2. The implementation
    Any bugs or technical issues that show up for people using different browsers/devices/etc.

Basically, the current mobile skin has a few unusual CSS rules that were thrown into it, no doubt to work around issues with formatting in the app browser. One of them, and IMHO the most problematic, is the one that forces all HTML tables in the article content to fill the entire width of the display. Since Infoboxes are tables, they're all affected by this rule, and the results are IMNSHO extremely poor. But, since it's in the site CSS, there's no way to turn that rule off without admin acces to edit that CSS.

However, I've found that it's possible to work around the rule, by abusing (I'll admit it) the code that handles right-aligned, thumbnail-sized embedded images. Those images are displayed in a very smart bit of code (in contrast to the heavy-handed table overrides) that responds to the width of the display device, formatting them normally (right-aligned, with text flowing to their left) when there's room, and automatically pulling them into the center of the screen with no text on either side if the display is narrower. In my testing I've discovered that the same logic can be activated for Infoboxes, and I feel it looks far better on both wide and narrow devices.

I've put two examples of my proposed formatting change onto a single page, User:FeRDNYC/TestMonster (ignore the name). There you can see copies of the body content for both the Ballpoint Penguin and Herowin articles, but with the Infoboxes updated to leverage the responsive image-alignment code.

If you view that test page on a mobile device, or in the mobile skin on the desktop (by scrolling to the very bottom and clicking "Mobile view"), you'll be able to see how the Infoboxes would be formatted following this change. Both original articles are linked to, so you can compare them to my version.

If anyone has a moment, please do check it out, especially if you have access to any type of mobile device. I've tested it in Google Chrome on my computer, and my Android phone, but I'd love to hear feedback from anyone who looks at it using an iPhone, iPad, or any other tablet device, as I don't have access to any of those devices to test it myself.

My thinking is, if people like this change and it doesn't cause any problems, that all of the Infobox templates across the wiki would be updated to override that width=100% styling and make use of the responsive formatting. Some other templates, like {{Diary}} and {{Diaryquest}} would probably also be included, though they'd default to being left-aligned instead. -- FeRDNYC (talk) 15:09, 1 July 2018 (UTC)

I have noticed problems with infobox formatting on mobile too, and wondered how amenable it would be to improvement. I admire your creative adaptation of existing features into unexpected implementations ;)
I'll have a chance to test it on an android tablet screen and in a handful of desktop browsers in the next day or two, but I've decommissioned all my iOS devices so someone else will need to take up that testing. Meanwhile, I might try to hunt for some of those infoboxes where I found myself cringing on mobile, if I can find them again, and try to view the test examples you've made up in as many various ways as I'm able. --Djonni (talk) 03:14, 2 July 2018 (UTC)
Cool, thanks. For the most part, the ones that have seemed problematic on mobile were probably ones where the forced width causes weird explosions of the table borders. Like, you'll have an infobox that randomly grows a big empty column to the right of its content. There's a bunch of that scattered around the wiki.
If the width is no longer being forcibly expanded (or, if it is, but only within the <div> container that holds it, which is where the width is constrained) that should no longer happen. Honestly that issue is the main impetus for me doing this, as there's no good way to account for a CSS-forced width=100% !important from within the HTML source. -- FeRDNYC (talk) 11:48, 3 July 2018 (UTC)