Replacement filing cabinet

1 2 3

Info information icon
Here you can post updates on what you're working on or a notice to others concerned with the development of the wiki. For general discussion see the Community Portal talk and for minor news see the Development Portal main page.

MediaWiki:Wiki-navigation error

I want to add Blog:The Sim's Pen to the navigation under blog posts button, but the editor doesn't allow me. It says the level 1 menu is too wide. It's odd, because it will say so even if you preview it without making any changes. Sooner or later if we need to edit the navigation, we need to shorten the level 1 menu name as well. I tried to change "Interact" into "aaa" and the editor allowed me. Any ideas which menus to shorten? Nikel Talk Vote! 14:46, September 18, 2014 (UTC)

I'm getting the glitch on my other wiki too, which is strange, because it fits just fine. Looks like Wikia broke something here. Special:Contact it, maybe? --k6ka (talk | contribs) 14:47, September 18, 2014 (UTC)
Well, the error tells us to go to w:c:community:Help:Navigation. The "error" seems intended, meaning it's more like they changed the limit (while keeping the preexisting navigations intact so they won't be broken). Nikel Talk Vote! 15:03, September 18, 2014 (UTC)
Hmm, it seems like the error has been fixed. --k6ka (talk | contribs) 14:03, September 19, 2014 (UTC)
...only to be broken again! What's going on here, Wikia? --k6ka (talk | contribs) 14:28, September 20, 2014 (UTC)
Okay, I have reported the issue at Community Central. --k6ka (talk | contribs) 21:38, September 20, 2014 (UTC)
Alright, there are two solutions to this that I have tried on my test wiki and has worked.
  1. Move the page MediaWiki:Wiki-navigation to another title, make your changes, and then move it back. This, however, will break the navigation bar while the original navigation page is a redirect, but it works.
  2. Copy and paste the following code into your user CSS file:
/* Special thanks to User:452 for this! Original taken from */
/* This thing fixes the broken width check in MediaWiki:Wiki-navigation */
.ArticlePreviewInner .WikiHeader li.nav-item a {
  /* Because the width check is broken. */ 
  margin: 0;
  padding: 0;
This code works by reducing the width of the tabs in the preview window. It looks horribly squished while previewing, but it will fool the check into thinking that it's of the right size and will let you publish the edit. Just be careful! This could potentially allow you to save an invalid layout into the page, which can result in unpredictable results! It's best to test your changes on a test wiki to make sure nothing is out-of-place or broken before you save it on a real wiki.
You can also put this in your global CSS file so it loads on all wikis, which is useful if you're an admin on other wikis. See Help:JavaScript and CSS Cheatsheet for details. --k6ka (talk | contribs) 01:59, September 21, 2014 (UTC)
The issue only appears to occur when using Google Chrome 37... other browsers and older versions seem to work without the fix above. --k6ka (talk | contribs) 11:58, September 21, 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Sorry I was a little late to follow this up. Nice workaround! Thank you for reporting and finding a workaround for this issue, k6ka. :) Nikel Talk Vote! 11:54, September 22, 2014 (UTC)

Introducing {{Edit conflict}}

Sick of running into edit conflicts while editing a talk page? Are people starting to think that you're an ignorant pig for not reading the comments right above yours?

If we could develop a magical extension that automatically resolved talk page edit conflicts, that would be wonderful. But we obviously can't do that -- talk pages are essentially the exact same as any other page. Really.

So here's another solution. If you ran into an edit conflict while editing a talk page, you can defend yourself against "Y U NO READ MY POSTS??!!" comments by adding {{Edit conflict}} in front of your comments. For example:

I'm not sure if this is the correct way to do it... --User 1
:Oh for sure, it is! --User 2

Let's say you were typing a response right underneath User 2's comment. As soon as you click "Publish" you are told that there was an edit conflict. The current page looks like this:

I'm not sure if this is the correct way to do it... --User 1
:Oh for sure, it is! --User 2
::If you read the manuals at, you'll see it's correct. --User 3

You would normally go to the bottom of the page, copy your changes, and then paste them under User 3's comment. With the new template, however, you can now easily tell the world that there was an edit conflict and that there is no need for finger-pointing if your comment is the same as User 3, or if it tries using an argument that User 3 had just knocked down.

I'm not sure if this is the correct way to do it... --User 1
:Oh for sure, it is! --User 2
::If you read the manuals at, you'll see it's correct. --User 3
::{{edit conflict}} According to the manuals, yes, this is how you do it. --You

Which comes out as:

I'm not sure if this is the correct way to do it... --User 1

Oh for sure, it is! --User 2
If you read the manuals at, you'll see it's correct. --User 3
(edit conflict) According to the manuals, yes, this is how you do it. --You

If you have experienced multiple edit conflicts you can also add an optional parameter to the template that indicates how many edit conflicts you endured. For example, if you encountered three edit conflicts, you can add {{edit conflict|3}} to show for it, which comes out as:

(edit conflict × 3)

You can also use the shortcut template - {{Ec}}, which does the exact same thing.

Have fun! --k6ka (talk | contribs) 15:01, September 27, 2014 (UTC)

This is a good concept, although I don't encounter edit conflicts that often. And even if I did, I would change some things in my post. u.u Nikel Talk Vote! 12:19, September 29, 2014 (UTC)

Category:Families / Sims by neighborhood and world

While we've had resolved the issue to distinguish world from neighborhood by terminology, there's one thing I have in mind. Categorization has organizing purposes, and I believe that having two distinct categories, i.e. Category:Sims by neighborhood and Category:Sims by world, is redundant. We know how worlds and neighborhoods work differently, but we also know that these two are essentially the places where lots, in which Sims live, are situated. This means that worlds and (non-TS4-wise) neighborhoods are actually on the same level. Hence, I propose that these categories to be merged just for the sake of simplicity. Nikel Talk Vote! 08:35, October 5, 2014 (UTC)

ETA: Other things that regard worlds and neighborhoods remain unaffected. I only want to discuss about these two (three, with Category:Families by neighborhood) in particular. Categories like Category:Worlds and Category:Neighborhoods should stay that way, I suppose. Nikel Talk Vote! 08:36, October 5, 2014 (UTC)
I'm changing my mind. Now I'm starting to think that distinguishing worlds and neighborhoods in the category seems pointless and convoluted. They're deemed to be distinct in the main content, but I don't think it's very important to do that in categories. Therefore, I propose that we just combine the "Category:X by world" into "Category:X by neighborhood" for simplicity. Nikel Talk Vote! 11:24, October 10, 2014 (UTC)

Fixing a link

Moved from The Sims Wiki:Administrators' noticeboard

I've been struggling to figure out how to fix the career parameter for Tiffany Burb. It's supposed to be categorized under fashion, but instead it's categorized under "Sims who work in the career". Also there is no link to "fashion" in the career parameter. It simply says "[[|Department Store Clerk]]", but without a link.

I've been trying to resolve the issue by myself, but I just can't locate the cause of the issue. And I can't find any template documents that may appear broken. -- C.Syde (talk | contribs) 03:58, October 6, 2014 (UTC)

It appears that this problem has been solved. For some reason, fashion wasn't included on the list of careers in Template:GetCareerCat and Template:GetCareerLink. We're missing an in-game icon for the fashion career from TS1, but if someone can find one and upload it, it should be added to Template:GetCareerImage. -- LostInRiverview talk ~ blog 04:22, October 6, 2014 (UTC)
Additionally, it's worth noting that the Sim/Simbio templates are among the most complex templates on the wiki. All of them ultimately are based off {{Sim}} which in addition to being a massive and complicated template in its own right, has dozens of secondary/auxiliary templates that feed into it. The best course of action in these cases is to determine what the issue is, and to find where in {{Sim}} the problem may originate. Most of the time if there's an issue in the bio template, it's an issue in {{Sim}} itself or one of its auxiliary templates. -- LostInRiverview talk ~ blog 04:25, October 6, 2014 (UTC)
@ LiR:Post1 - Oh, okay. I certainly would never have found that link by myself, without being tipped off first. As for the missing in-game icon, I guess we'll just have to wait until someone who owns The Sims: Unleashed uploads an icon.
@ LiR:Post2 - Well that explains it. While I do know how the Sim/Simbio templates, they are proven to be really massive compared to the other templates I use/edit. -- C.Syde (talk | contribs) 04:29, October 6, 2014 (UTC)
I have The Sims: Complete Collection but I have no idea how to extract the information from the files... not to mention the icons. I've tried several tools with no luck. Nikel Talk Vote! 11:54, October 6, 2014 (UTC)
Same here. -- LostInRiverview talk ~ blog 17:51, October 6, 2014 (UTC)
The only way I can think of extracting the icons is to go in-game, take screenshots of them, and then process it. The game files themselves are not well documented by modders and there is no "Sim1PE", or at least none that is free. --I am k6ka Talk to me! See what I have done 19:28, October 6, 2014 (UTC)

Static headings

As part of the Halloween theme, we changed div.headingblue and div.headinggreen in the wiki's css page so that the headings would be purple and orange, respectively. While this solution is simple and effective most of the time, there are a few instances in which we would want to continue using the standard blue and green headings even if we implement a new temporary theme. So, I've added div.headingbluestatic and div.headinggreenstatic to the css page. If there is some need to use a blue or green header, and you wish to ensure that the header remains blue or green even if the wiki temporarily changes theme, you can use the static versions of the headings. This is useful on, for example, our new user welcome messages, since those messages are substituted and the colors chosen will never change once they're added.

-- LostInRiverview talk ~ blog 19:26, October 16, 2014 (UTC)

Eliminating Simbio

This is something that has been brought up several times in the past, but I'd like to start a discussion specifically about this topic. Right now on the wiki, we have two "biography infobox" templates for each game - the "Sim" and "Simbio" templates. For example, for The Sims 3, we have {{Simbio3}} and {{Sim3}}.

In Forum:Organization for TS4 timeline, a particular issue with the Simbio system is mentioned, specifically regarding {{Simbio-start}}. Simbio-start lists a Sim's name and significant familial relationships. The problem arises when a Sim has a different name or different relationships between games; which information, if any, should Simbio-start display? Take for example Bella Goth. Her Simbio-start lists her name as Bella Goth, even though her name is Bella Bachelor in The Sims 3. It lists her marital status as "married" even though she is not married in The Sims 3. It lists her children as Cassandra and Alexander, even though she has no children in The Sims 3 and only Cassandra as a child in The Sims. Ultimately, it would make more sense to include this information on each Sim template.

On top of this, when you start looking at it more in-depth, it becomes obvious that Simbio-start is redundant; everything that the template does is already done by the Sim templates. Another item of note is {{Simbio-end}}. At one time, Simbio-end included links to player stories and player theories pages. But, those pages no longer exist or are deleted, so Simbio-end no longer serves any meaningful purpose.

Phasing out Simbio would not be difficult to do, since Simbio is actually based on the Sim template. It would only be a matter of moving the information from simbio-start onto the other Sim templates, and changing the template used on the pages (a task which could be handled by a bot). No syntax would need to be changed, to my knowledge, and no changes would need to be made to the Sim templates. -- LostInRiverview talkblogcontribs 17:49, November 9, 2014 (UTC)

I'm aware of the problem where the information stored in {{Simbio-start}} may be inconsistent with the rest of the series and it uses the latest of the "main timeline" of the series, i.e. The Sims 2 and The Sims 3 Store worlds, but the problem gets even worse with The Sims 4. This is also apparent in Ruby Broke, the sister or Skip Broke. It's said that Skip and their parents are deceased, but that's following to the series in TS2, even though they're very much alive in TS3, and she's not even present in TS2.
For that reason... I would actually support this change. But before that, do you think any change is needed for {{Familybio-start}}? Nikel Talk Vote! 03:08, November 12, 2014 (UTC)
Overall I support this change, but I did initially have a few concerns about it.
  • Will this mean, that we'll be seeing a huge surge of edits in the process?
  • Will fanon writers have to edit their fanon Sim info-boxes during this change?
If the answers to those questions are yes, then I might initially have opposed this change. But then I re-read LiR's message about the task being handled by a bot. And I also decided "Maybe it would be best if I just supported this change, assumed good faith (as I always claim to do), and trusted that the "highly experienced" editor responsible for making this proposal - in this case LiR - knew what they were doing, and doing it for the benefits of the community. -- C.Syde (talk | contribs) 04:42, November 12, 2014 (UTC)
Assume Good Faith is an assumption that another person is contributing positively. AGF doesn't require you to assume that they are correct or that their ideas are any more valid than yours just because they've more experienced. You are totally free to agree or disagree with me or others for whatever reason(s) you want.
As for the handling of the task and other incidental issues... Changing Simbio to Sim could be handled by a bot, or it could be a gradual process. For starters, We can look into simply keeping the Simbio templates as redirects to their corresponding Sim templates, until the template links can be corrected. The same is true for Fanon pages. It's worth noting that the syntax for Simbio and Sim are nearly identical (in fact, all Simbio templates already use the base {{Sim}} template, and have for some time). The task of moving information from Simbio-start to the Sim templates would be a manual process, but we don't necessarily need to be in a rush to change everything and delete Simbio-start. Regarding Familybio... the idea had not actually occurred to me, but since family pages may encounter the same issues as Sim pages, deleting the Familybio and Familybio-start templates (after a transition period) would make sense as well. -- LostInRiverview talkblogcontribs 05:28, November 12, 2014 (UTC)
Well yes. I assumed that you were contributing positively as usual, and I didn't think your ideas were any more valid than mine for any reasons. I can't really tell what most of the reasons are except that I assume that this proposal is correct.

P.S. I actually do know what assume good faith means. It is when one person assumes that another is contributing positively, whether or not they believe that person's contributions are correct. I'm just not the best at proving that I understand. -- C.Syde (talk | contribs) 05:31, November 12, 2014 (UTC)
We could opt to put Familybio at the 2nd priority while handling the Simbio issue first. It's better to focus on one thing before taking care of another. Nikel Talk Vote! 14:17, November 13, 2014 (UTC)

wikitable heading-blue

These two table classes, wikitable and plaintable (aside from prettytable), are commonly used in this wiki. They're pretty much alike:

class="wikitable heading-blue" table
Header Header
Text Text
class="plaintable heading-blue" table
Header Header
Text Text

Both tables use heading-blue class to make the headers blue. At some point, heading-blue no longer worked on wikitable class. This issue had lingered for years. I'm still unsure what's wrong, but my guess is that wikia's own wikitable settings succeed some elements this wiki's wikitable customization in MediaWiki:Wikia.css. Some elements are like background-color and padding.

So anyway, I figured that by adding

table.wikitable > tr > th, table.wikitable > * > tr > th {
   background: #BFD7FF;
   text-align: center;
   font-size: small;

to the css, it will change the header background to blue. It still doesn't fix the issue where heading-blue doesn't work on wikitable, and this will change all tables using wikitable class into blue header. I personally never like the gray header, but what do others think? Should we add this to the css? Nikel Talk Vote! 14:26, November 16, 2014 (UTC)

Funnily enough I brought this up on IRC a week or two ago and I tried to code something to fix it but I never got around to finishing it. I'm curious to see what the tables would look like with green (specifically, I think I was testing with
  1. CCFFCC) in the header instead of blue given the prevalence of green in the wiki's theme, however. As for implementing it feel free to do so given that this is better than the broken version you're saying we have now. ђ talk 22:48, November 16, 2014 (UTC)
Alright, I've added the lines to the css. If there's any issues regarding this, please report here.
Wikitable green header
This is what the green header looks like. I'm feeling indifferent about this. I'm content with the current blue header, but if we are to change the header theme to green, that's fine for me too. Nikel Talk Vote! 04:44, November 18, 2014 (UTC)
Maybe it's early in the morning, but it took me a while to distinguish the table on the left from the right. The green's not very visible. --I am k6ka Talk to me! See what I have done 11:49, November 18, 2014 (UTC)

Emphasized section headers

I'd like to propose to emphasize level 3 section headers and higher a bit. I feel like these section headers are a little too plain. If you read townie page, it uses a lot of level 3 and level 4 section headers. These headers are just slightly larger than normal text, and it's a little difficult to distinguish them from regular text. I think we could give them a line border like level 2 section header, or perhaps make them bold?

The result of giving them line border will make them look like Wikipedia section headers, if one wonders. It kinda helps to know where a section ends. What do you think? Nikel Talk Vote! 05:26, November 22, 2014 (UTC)

MediaWiki Emoticons

Apparently the D:< emoticon doesn't work properly in chat. It should come out as Moodlet icon smiley angry but instead it comes out as Moodlet no frame crying baby< -- C.Syde (talk | contribs) 00:15, December 5, 2014 (UTC)

Hmm, you're right. Apparently you can't make an emoticon as a superset of another emoticon. I guess it's just a technical limitation. We can change the code for the angry emoticon. Nikel Talk Vote! 06:45, December 5, 2014 (UTC)

Category placement on templates

We recently worked on cleaning up Category:Templates, and much of this work involved re-categorizing templates. I noticed that there is no clear standard regarding where the templates' categories should be placed. Some templates have the categories in 'noinclude' tags on the template itself, while other templates had their categories inside 'includeonly' tags on the template's documentation page. I noticed on at least one occasion, categories were included in both places, meaning I had to edit both the template and template documentation pages to find them. I think it would make sense to adopt a standard and implement it wiki-wide, to avoid future issues or confusion. -- LostInRiverview talkblogcontribs 00:12, March 19, 2015 (UTC)

There's an issue with Wikia in that categories placed on the template documentation page seem to correctly add the template to the category, but the template doesn't appear on the category page itself. Putting the category in noinclude tags on the template page itself seems to fix the problem. --I am k6ka Talk to me! See what I have done 01:13, March 19, 2015 (UTC)
Try clearing the cache. I've also noticed that performing a null edit on the template page after updating the template documentation will solve this problem. In any case, I'd chalk it up to the fact that adding the category to the template documentation adds an extra step to the process, so it takes a little time for the whole database to update itself. Take for example Template:SkillTable, which is categorized in Category:Simology templates, with the category included on the template's documentation page. It may not have appeared in the category immediately, but if you look now, it should appear. -- LostInRiverview talkblogcontribs 02:40, March 19, 2015 (UTC)
Edit: Wikipedia explains this phenomenon as well - "All other purge methods do not apply to categorisation and 'what links here' changes from template edits, but a null edit does... Changes in category links are put into the job queue, and re-cached when the server load is low." -- LostInRiverview talkblogcontribs 02:43, March 19, 2015 (UTC)
I tried all of those — purging and null editing. Didn't work. I did file a bug report and they told me they were working on a fix, but I still see that same glitch pop up occasionally. --I am k6ka Talk to me! See what I have done 02:52, March 19, 2015 (UTC)

Adding TS4 age logos to TS4 Sim infoboxes

Because TS4 uses different logos in its interface to the other three games, I was wondering if we could add a function to the code of Template:Sim in order for the pulling of TS4 age images into the template and onto the page. I have already uploaded the appropriate images:

TS4-Child TS4-Teen TS4-Young-Adult TS4-Adult TS4-Elder

This could possibly be a another great way to 'modernise' the wiki. I also have a proposal as to how we could achieve this.

We could add a template named, say, Template:GetTS4StageImage, using the same code as Template:GetStageImage, except with the TS4 images. Thereafter, we could put in the following code into Template:Sim:

{{#if:{{{age<includeonly>|</includeonly>}}} |
{{!}} width="75" style="background: {{Vgbodycolor|{{Vgcode|{{{game}}} }} }}; border-bottom:{{Vglinecolor|{{Vgcode|{{{game}}} }} }} 1px solid; color: #4B4B4B"{{!}}'''Age'''
{{!}} style="background: #FFFFFF; border-bottom:{{Vglinecolor|{{Vgcode|{{{game}}} }} }} 1px solid;"
{{!}}{{#if:{{{age|}}}| {{#switch: {{{game}}}
|The Sims 4
|The Sims 4 Outdoor Retreat
|The Sims 4 Get To Work = {{GetTS4StageImage|{{{age}}} }}
|#default = {{GetStageImage|{{{age}}} }} }} }}

The only disadvantage would be that there appears to be no logo for TS4 Babies, so I'm not entirely sure how to deal with that, should this plan get through...not that there are many noteworthy things about TS4 babies anyway.

I haven't tested it yet though, so I hope all you code-monkeys out there can help me iron out the code so it works! ―The Tim Man (Infinite HistoriesGalactic CruciblesThe Sims WikiHallows MaleficentWhy I'm here in the first place) 08:32, March 31, 2015 (UTC)

If we were to size the images down the amount which would be necessary for them not to expand the template they'd be hardly recognisable and would contrast a fair bit with the white background. For reference:

TS4-Adult TS3-Adult

These are both sized at 20px too but the TS4 one looks huge so we'd need to scale it down a bit. I think I prefer it how it is but if you can get a demo up and running you might be able to change my mind but I'd appreciate it if you kept in mind the things I said. As for the code, I'm not even going to pretend I understand that but it doesn't look like you forgot to close any templates or anything extremely obvious. ђ talk 10:26, March 31, 2015 (UTC)
Actually, it's 20x40px for TS4 icon, which is why it's taller. If it's set to [[File:TS4-Adult.png|x20px]], it should be at the correct height:


But still, it's way too small and narrow and not contrast compared to TS3 icon. Another thing is that TS4 lacks several life stages. Just for future references if somehow we want different series to display different icons, I suggest we use {{Vgseries}} as a built-in switch parser function. Nikel Talk Vote! 12:36, March 31, 2015 (UTC)


Is it just me or the "death from kite" is not listed on the deaths on the GetCodCat/doc template?

I'm also confused by the "coffin scare" bit of the template, because I've never heard of that death type. -- C.Syde (talk | contribs) 08:30, April 16, 2015 (UTC)

Apparently it categorises as the same type of death as "fright". But isn't that redundant? And death by "fright" is a Sims 2 base game death, so why is it listed as a Nightlife death under "coffin scare"? -- C.Syde (talk | contribs) 08:46, April 16, 2015 (UTC)
According to the information found here, there is such a death type. Is that true? I thought there were only 19 different death types in The Sims 2 (if you count dying from a death token, as a death type). -- C.Syde (talk | contribs) 09:04, April 16, 2015 (UTC)
It's a real death and distinct from the regular fright death. Read more here. Cyjon made a detailed explanation there. Though death by kite is not a unique death, I'm unsure what death it belongs to. I already forgot. Nikel Talk Vote! 11:59, April 16, 2015 (UTC)
I'm not sure I fully understand the "I'm unsure what death it belongs to" bit. -- C.Syde (talk | contribs) 12:01, April 16, 2015 (UTC)
I meant that if it's not a unique death, then it should be considered an existing death, right? The game might think it's a death by electrocution or lightning instead. But I'm unsure about lightning, since kite is in OFB while death by lightning is in Seasons. Nikel Talk Vote! 12:03, April 16, 2015 (UTC)
Kites attracts lightning only in a lightning storm. So it's a Seasons death. --I am k6ka Talk to me! See what I have done 12:23, April 16, 2015 (UTC)
I thought the original OFB evil kite attracted lightning, even without Seasons? Nikel Talk Vote! 12:47, April 16, 2015 (UTC)
Really? Hmm, well, since Cyjon says it isn't a unique death, I'm guessing it might be death by electrocution. But I'd have to uninstall Seasons to find out, and I'm in no mood to uninstall EPs anytime soon. --I am k6ka Talk to me! See what I have done 14:02, April 16, 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────This is what Prima guide said about the evil kite:

The evil version of the kite is metallic with red eyes. It flies but attracts lightning, resulting in electrocution and, possibly, death.

After all, the side effect of evil crafted objects shouldn't be EP-dependent, right? Nikel Talk Vote! 03:06, April 17, 2015 (UTC)

I've checked and seen for myself that there is such a thing as a coffin scare death. But the Sims who succumbed to this death type don't appear to have a unique ghost, or unique ghost colours. -- C.Syde (talk | contribs) 23:57, April 18, 2015 (UTC)
Ghost colors
EP-specific ghosts don't necessarily have unique ghost colors anymore (probably because EA was lazy about details at that time). I was aware of the ghost color, but the death is unique. Long ago, I found the color code of each ghost color. I wrote "Scare" in the white box, but according to ghost page, the sunlight ghost is the one that's white? The point is, not all deaths have unique colors; some may use the hunger ghost color as the default color. Nikel Talk Vote! 05:07, April 19, 2015 (UTC)

Eeek! The Edit/Talk page buttons are all over the place! What's going on?

You may have noticed how the Edit and Talk page buttons are now under the page title, and under the divider line, almost embedded into the content of the article. There is a whitespace beneath the page title and social media links above the page count....

This is because of yet another crappy change that Wikia insists on forcing on all Wikia communities. See w:User blog:Gcheung28/New sharing options on Wikia.

The overall reception for this change is very negative, but since Wikia is known for ignoring the community or taking forever to respond to their requests, we don't know how long this crappy layout will be with us. This is simply unacceptable for Wikia to do and it just shows how they are oblivious to what their own community actually wants, rather than what they think look snazzy, even when it looks stupid as hell. --I am k6ka Talk to me! See what I have done 14:23, April 28, 2015 (UTC)

This is absolutely hideous. Or just overall terrible. I'm only just passing by briefly so I won't be able to check everything out for now. The talk page has been narrowed, which is terrible. I don't know if there's any follow up to the talk page width issue, but for a temporary workaround (maybe Wikia will fix it?) just in case, add this to the wiki's css:
.WikiaPageHeader .wikia-menu-button, .WikiaPageHeader > .comments, .wikinav2 .WikiaPageHeader .wikia-menu-button, .wikinav2 .WikiaPageHeader > .comments {
  margin-top: -8px;
Nikel Talk Vote! 17:49, April 28, 2015 (UTC)
Wikia has (surprise!) deemed these changes as part of the overall user interface and therefore has prohibited changes to it through wiki css or js. I'd fetch the link to the comment where this was stated, but I'm on my phone. - LostInRiverview talkblogcontribs 20:43, April 28, 2015 (UTC)
I noticed these changes last night. I'm actually not much affected by them. I don't really care whether they stay or go. :| -- C.Syde (talk | contribs) 20:49, April 28, 2015 (UTC)
One of the staff said they'd fix this narrow talk page issue. Hopefully they will. It looks so tacky. Nikel Talk Vote! 05:32, April 30, 2015 (UTC)
I'm not entirely certain if there's anything that can be done about it, but from time to time, I do get a tad irritated by the somewhat narrow pages, not just the increasingly narrow talk pages, but I've been a tad irritated by the pages in general. Sometimes I wish that wikia pages were wider - just a little. Just wide enough to be able to fit a little more content on each line.
I now see what you mean by the really narrow talk page issue. I too find it really tacky and rather annoying. -- C.Syde (talk | contribs) 07:13, April 30, 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────It's been weeks and this issue has never been addressed. Are you sure we can't do the slightest edit which is just to move the button very slightly to the top just to work around this issue? Nikel Talk Vote! 07:34, May 9, 2015 (UTC)

Not unless you want Wikia Staff to pay an unwanted visit to forcefully remove the violating piece of CSS and scolding us for violating the ToU. Besides, Wikia is notorious for taking forever to respond to issues, but only a few days to roll out crappy new changes. --I am k6ka Talk to me! See what I have done 13:21, June 3, 2015 (UTC)

Fixing the module rails with MediaWiki:Wikia.css

Some of you really experienced CSS users might have figured this out already, but I've found out that if you want to fix the module rails, you just change them from h1 to h2. I was told this on this blog at wikia community central. -- C.Syde (talk | contribs) 09:51, May 22, 2015 (UTC)

Hmm? What issue is this about? Nikel Talk Vote! 16:27, May 24, 2015 (UTC)
The hot spots module rails are broken. They're supposed to be green, but they're broken so they're invisible. It looks as though the rest of the issue has already, though silently, been resolved. -- C.Syde (talk | contribs) 06:29, May 25, 2015 (UTC)
You were right about changing it from h1 to h2, so I did that. In addition, I also added .insights-module h2 so that the new Insights module also has the green header, just like the other modules.
To admins: Has anyone checked the Advanced tab in admin dashboard? The heading offset seems to be faulty there. The solution could be setting either .WikiaPage h2 or .WikiaArticle h2 class with margin-top: 0px, but judging from both of the classes' name, probably it's not quite safe to mess around with them? Any ideas? Nikel Talk Vote! 04:24, May 27, 2015 (UTC)
^ The reason I knew to change the module rails was because I faced much the same problem on another wiki, where I have admin rights, and needed to ask how to fix it at wikia community central :D -- C.Syde (talk | contribs) 04:49, May 27, 2015 (UTC)
I've just realised that the targeted pages module needs to be updated. -- C.Syde (talk | contribs) 11:39, May 29, 2015 (UTC)

Overpopulated list of wanted pages due to #ifexist

Special:WantedPages lists out a ton of pages with a Fanon: prefix, that are really just neighborhoood/world pages that do not yet exist. It turns out, {{Sim}} has an #ifexist parser function on the neighborhood parameter, that searches to see whether a Sim's given neighborhood page exists. The template is written such that the #ifexist search only happens on fanon pages (by use of the {{checkfns}} template). The problem is, #ifexist is bugged, so that pages that are "searched for" with that parser function are populated into the list of wanted pages. This is a known and long-standing bug in MediaWiki itself (so we can't blame this one on Wikia). I've inquired on Community Central to see if there is a work-around we can implement, but if that should fail, I think we should figure out a way to fix this.

Any ideas? - LostInRiverview talkblogcontribs 05:52, May 28, 2015 (UTC)

Is this bug fixed in later versions of MediaWiki? Wikia uses an outdated version of MediaWiki (1.19.24) -- the current version is 1.25.1. Support for 1.19 ends this month (1) --I am k6ka Talk to me! See what I have done 11:11, May 28, 2015 (UTC)
From what I've seen, it's still there as of March 2015. The explanation I've read is that there is another MediaWiki feature that depends on the way that #ifexist functions now. It's a bug that's been around for years. LostInRiverview talkblogcontribs 14:55, May 28, 2015 (UTC)
We could make the Sim template in fanon namespace not to link to their neighborhood / world page altogether from the infobox to avoid this, but I don't think anyone really wants that. Eventually, authors will insert a [[link]] inside the neighbor parameter, which, in turn, ruins categorization.
I've been aware of this issue for a long time, but I never really brought it up to attention (plus I wrote the #ifexist function). I'm sorry. But we can't really do anything with the bug, so we might need an alternative approach with the #ifexist function in the Sim template. I might have an idea.
Currently, the #ifexist function checks if a fanon page exist, then it will link to the page; otherwise, it will just put the neighborhood name without linking. How about, instead of that, we use two #ifexist functions to append [[ and ]] separately, so it will not as if the template links anything?
{{Checkfns| {{#ifexist: Fanon:{{{neighbor}}}|[[Fanon:{{{neighbor}}}]]|{{{neighbor}}} }} }}
{{Checkfns| {{#ifexist: Fanon:{{{neighbor}}}|[[Fanon:|{{{neighbor}}} }} {{#ifexist: Fanon:{{{neighbor}}}|]] }} }}
Do you think it might work? Nikel Talk Vote! 04:41, May 29, 2015 (UTC)
The issue isn't the brackets, the issue is the actual #ifexist function. When you include a page name in the function, it considers that name as a link to that page. If for example, I were to add an #ifexist function to this page that said "#ifexist: Sunset Valley," if you were to check the Special:WhatLinksHere page for Sunset Valley, it would show that this page links to that page, even though there is no link here that does so. The way the template is currently written does work in the respect that if a fanon version of a neighborhood doesn't exist, the template doesn't link to it. But simply having the #ifexist looking for that page in the first place causes the problem. I'm curious as to how manually linking the neighborhood pages ruins categorization? The category should ignore the brackets if they're included, right? -- LostInRiverview talkblogcontribs 05:22, May 29, 2015 (UTC)
Oh? I was always under impression that the brackets caused it. Well, I guess the function is pretty faulty then... Since the way {{Sim}} categorizes the neighborhood is [[Category:{{{neighbor}}} Sims (fanon)]], inserting [[Pleasantview]] to the neighbor parameter would make it appear like this: [[Category:Pleasantview Sims (fanon)]]. Nikel Talk Vote! 05:35, May 29, 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The category is another issue as well, since in theory we could have two neighborhood or world pages by different authors. If for instance, you and I both created a fanon page for Sunset Valley, they'd be titled "Fanon:Sunset Valley (Nikel23)" and "Fanon:Sunset Valley (LostInRiverview)." So in this case, the categories would be "Category:Sunset Valley (Nikel23) Sims (fanon)" and "Category:Sunset Valley (LostInRiverview) Sims (fanon)". LostInRiverview talkblogcontribs 06:05, May 29, 2015 (UTC)

Well, it's true, but it's not exactly an issue if the author wants to make their fanon Sims exclusively to be in their own universe instead of the shared Sunset Valley. Nikel Talk Vote! 09:30, June 3, 2015 (UTC)

Replacing ReferenceTooltips with ReferencePopups

For some time now we've been using ReferenceTooltips, which allow readers to view footnotes by simply moving the cursor over the reference, instead of having to click it and be transported to the bottom of the page, away from the text they were viewing.

ReferenceTooltips has been broken in Oasis for a long time, and it's unlikely it will ever be fixed now. The thing has never loaded in Oasis, and I personally use navigation popups to view footnotes. However, not everyone has, or wants to use, navigation popups. Even in my experience, the script has been buggy even in the Monobook skin, and I'd like to retire it in favor of an updated version.

I suggest that we scrap ReferenceTooltips and use ReferencePopups instead.

ReferencePopups is basically a Wikia-version of the popups found on Wikipedia. Like ReferenceTooltips, it will display the footnote text simply by moving the cursor over the reference, and allows the reader to read footnotes without having to jump away from the article text. The one big difference is that this tool offers more features, works in both Oasis and Monobook, and auto-conforms to the settings in theme designer, so we don't need to go tinkering about to make the tool work. Individual users can also configure the script for themselves, all without the need of messing with their JS files. They can disable the tool for themselves if they wish, and re-enable them at any time.

The script seems to have a few quirks though. For one, the "Configure Reference Popups" link, that allows users to re-enable popups if they disabled them, doesn't appear in most namespaces in Oasis, though it does appear in Monobook for whatever reason. This might be solvable by "locking down" the script, as described here. Alternatively we can always just hope people will be able to go to a namespace where the link does appear (it appears in the Project namespace where there are categories) or just hope they know how to switch to Monobook, where the link always appears with no trouble. However, these issues are nothing compared to the brokeness that ReferenceTooltips is now.

You can try out the script for yourself by adding the following to Special:MyPage/common.js:

importArticle({type:'script', article:'w:c:dev:ReferencePopups/code.js'});

Thoughts? --I am k6ka Talk to me! See what I have done 18:34, May 30, 2015 (UTC)

The only issue I'm aware of ReferenceTooltips is when I click the option button. But, seeing that ReferencePopups seems to be a better tool, I'd prefer to use it instead. Nikel Talk Vote! 09:29, June 3, 2015 (UTC)

Fixing the targeted pages module rails with MediaWiki:Wikia.css

Apparently the targeted pages module rails still haven't been changed from h1 to h2 in Wikia.css. I already mentioned this above but that discussion appears to have dried up so I'm starting a new one down here. Already I've fixed that CSS issue for my own personal settings here. Except that the text is not white but black in my settings, implying that the code either needs to be updated, or there's a bug in the wikia.css settings. -- C.Syde (talk | contribs) 01:06, June 6, 2015 (UTC)

Hmm, which one is the targeted pages module rail? Nikel Talk Vote! 13:10, June 6, 2015 (UTC)
The followed pages module is the targeted pages module rail. -- C.Syde (talk | contribs) 22:38, June 6, 2015 (UTC)
I didn't know what you meant by target pages module rail. I was hoping you'd say like "the one when you see another user's 'Pages I'm following' box on the right." I figured it and fixed the module now. Nikel Talk Vote! 05:30, June 14, 2015 (UTC)

AWB is not working - AWB developers acknowledge issue

If you run AutoWikiBrowser anywhere, whether it be on The Sims Wiki or another wiki, you may have noticed that the program appears to have been disabled. It will ask you to update the program, but the auto-updater always fails, and when you try to manually download the new version yourself, you'll find that the download link points to an outdated version.

AWB developers say it is an issue with sourceforge and is out of their control. The only solution, then, would be to wait for sourceforge to get their act together.

In the meantime though, AWB will be unusable everywhere.

Source: wikipedia:Wikipedia_talk:AutoWikiBrowser#Where_is_5700_download.3F

--I am k6ka Talk to me! See what I have done 02:12, July 18, 2015 (UTC)

The issue should now be fixed. --I am k6ka Talk to me! See what I have done 17:58, July 19, 2015 (UTC)

Transitioning to new infoboxes

Moved from User talk:Nikel23 --I am k6ka Talk to me! See what I have done 23:03, July 22, 2015 (UTC)

Hey Nikel23 The Sims Wiki,

We’re reaching out to a few of our top communities, hoping to get you on board with the migration to the new infobox markup. And we have tools to help!

Why we’re doing this

Simply put: Most current infobox structures translate very poorly to mobile devices, and indeed any device that doesn’t use desktop-style displays. On desktops and laptops, they often look amazing. The problem is that more and more of our contributors visit Wikia from a mobile device.

To see just how much traffic has become mobile, you can check out this graph from our forum post about infoboxes a couple weeks back:

Wikia mobile traffic growth

Mobile traffic growth on Wikia

Mobile is the future. Not just for Wikia, but for the web as a whole. Take a look at the recent trends and future growth predictions for mobile traffic - it's staggering.

We partnered with the Wikia community to create this new markup to make sure that your hard work can be displayed on mobile devices (as well as any future technologies) easily and without any new coding conventions. It'll take some effort up front, but we’re here to help with it, and the work you put in now will pay for itself tenfold in the future.

Tools we’ve designed to make the process easier

We've enabled two new features on your community. One is a tool for migrating the "old" infobox code to the new markup. It identifies templates on your wikia that look like infobox templates and places a box on the right rail of the template page. When you click the "Generate draft markup" button in this box, it opens a new tab containing a draft of your infobox using the new markup.

The second is a new feature on Special:Insights that will highlight which infoboxes on your wikia have not been migrated to the new infobox markup. It's fairly intuitive - you can click on the infobox title link itself to see the old markup, or simply click the "Convert!" button on the right, which performs the same action as the "Generate draft markup" button.

This is our help page for the new markup. I'll help get things rolling by converting a template or two as an example if you'd like me to. I'll also watch this forum post - so feel free to ask any questions you have about this.

All the best,

Mira_Laime @fandom (help forum | blog) 22:55, July 22, 2015 (UTC)

(Off topic: It seems weird that staff wouldn't know to post these kinds of announcements on a discussion page. This is not the first time they've made this kind of announcement by just leaving it on a user's talk page. Hardly in the spirit of encouraging community discussion. But I digress...)
Well, we should definitely be working to get our templates and articles (not just our infoboxes) Mobile-friendly. But, the amount of work that would be involved in transitioning infoboxes is, I'm guessing, far beyond that which a single person would wish to take on. So, it might be necessary to form some sort of pseudo-project towards achieving a more mobile-friendly wiki. - LostInRiverview talkblogcontribs 02:17, July 23, 2015 (UTC)
I'm actually kind of positive about the migration. Wikia has provided us a pretty handy guideline, so we might as well follow it. The thing I cannot help much would be the infobox design. Nikel Talk Vote! 06:51, July 23, 2015 (UTC)
I'd be willing to put my two cents into the pseudo-project where I can help. -- Icemandeaf (talk) 16:12, July 23, 2015 (UTC)
Do we have an explicit deadline for this? I hope it's not soon. Nikel Talk Vote! 07:00, July 24, 2015 (UTC)
I don't think there's any deadline, I'm fairly sure the old infoboxes will remain usable, these ones just look decent on mobile devices. ђ talk 08:45, July 24, 2015 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.