Community Central

September comes to a close with This Month at Fandom, including cool data trends, Editors of the Month, and a summary of important updates you may have missed.


Community Central
Community Central
  1. #uploaded images
  2. #blog comments
  3. #forum comments


Live Screenshot

Does " " === "" ?

  • {{#ifeq: ||Yes|No}} Output: Yes
  • {{#ifeq:| |Yes|No}} Output: Yes
  • {{#ifeq: | |Yes|No}} Output: Yes

No, of course not.

A space is not the same as nothing.

Two spaces are not the same as one space.

This is how it is supposed to look, before the UCP update fucked it up.

A space is not nothing.jpg


Live Screenshot

Can you have line breaks in a Tabber?

Yes, of course you fucking can.

It would be a monumentally stupid oversight for Tabber not to have newlines.

This is how it is supposed to look, before the UCP update fucked it up.

Tabber supports line breaks.jpg


Query Expected Result
{{#dpl: |titlematch=nothing }} Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results.
{{#dpl: |skipthispage=error message |titlematch=nothing |noresultsheader=\n}}

Extension:DynamicPageList (DPL), version 2.3.0 : Warning: Wrong 'skipthispage' parameter: 'error message'! Using default: 'true'. Help: skipthispage= 0 | 1 | false | no | off | on | true | yes.

{{#dpl: |addeditdate=true |titlematch=nothing }}

Extension:DynamicPageList (DPL), version 2.3.0 : Error: You can use 'addeditdate=true' with 'ordermethod=[...,]firstedit | lastedit' only!

{{#dpl: |namespace=error message }}

Extension:DynamicPageList (DPL), version 2.3.0 : Error: Wrong 'namespace' parameter: 'error message'! Help: namespace= empty string (Main) | Admin_Central | Admin_Central_talk | Admin_Forum | Admin_Forum_talk | Admin_Support | Admin_Support_talk | Adoption | Adoption_talk | Archive | Archive_talk | Blog | Blog_talk | Board | Board_Thread | Bot_scan | Bot_scan_talk | Category | Category_talk | Community_Central | Community_Central_talk | File | File_talk | Forum | Forum_talk | Help | Help_talk | Hub | Hub_talk | MediaWiki | MediaWiki_talk | Message_Wall | Message_Wall_Greeting | Module | Module_talk | Talk | Template | Template_talk | Thread | Topic | User | User_blog | User_blog_comment | User_talk.

Extension:DynamicPageList (DPL), version 3.3.3: Error: No selection criteria found! You must use at least one of the following parameters: category, namespace, titlematch, linksto, uses, createdby, modifiedby, lastmodifiedby, or their 'not' variants

{{#dpl: |invalid parameter shows an error message=true |titlematch=nothing |noresultsheader=\n }}

Extension:DynamicPageList (DPL), version 2.3.0 : Warning: Unknown parameter 'invalid parameter shows an error message' is ignored. Help: available parameters: addfirstcategorydate category count hiddencategories mode namespace notcategory order ordermethod qualitypages redirects showcurid shownamespace stablepages suppresserrors allowcachedresults execandexit columns debug distinct escapelinks format inlinetext listseparators notnamespace offset oneresultfooter oneresultheader ordercollation noresultsfooter noresultsheader randomcount randomseed replaceintitle resultsfooter resultsheader rowcolformat rows rowsize scroll title title< title> titlemaxlength userdateformat addauthor addcategories addcontribution addeditdate addexternallink addlasteditor addpagecounter addpagesize addpagetoucheddate adduser categoriesminmax createdby dominantsection dplcache dplcacheperiod eliminate fixcategory headingcount headingmode hitemattr hlistattr ignorecase imagecontainer imageused include includematch includematchparsed includemaxlength includenotmatch includenotmatchparsed includepage includesubpages includetrim itemattr lastmodifiedby linksfrom linksto linkstoexternal listattr minoredits modifiedby multisecseparators notcreatedby notlastmodifiedby notlinksfrom notlinksto notmodifiedby notuses reset secseparators skipthispage table tablerow tablesortcol titlematch usedby uses allrevisionsbefore allrevisionssince articlecategory categorymatch categoryregexp firstrevisionsince lastrevisionbefore maxrevisions minrevisions notcategorymatch notcategoryregexp nottitlematch nottitleregexp openreferences titleregexp .

This is how it is supposed to look, before the UCP update fucked it up.

Documenting that the expected results match the actual results.png


Wikia Staff broke this in 2014, and instead of fixing it, they ignored it for 6 years, and while the MediaWiki upgrade has rendered this issue redundant, they have introduced even more problems:

query result

This query previously gave an error, and now says I've only edited one page.


uploaded images[]

Originally, search engines saw entire blog posts with comments below.

When lazy-loading blog comments were introduced, blog comments disappeared from the view of search engines.

As soon as I noticed, I reported it to Wikia Staff, who said they would make enquiries about whether this is intentional. They never followed up on this.

Whether or not it was intentional, the simple fact of the matter is that before lazy-loading, I could search google to find where I had said something. Now, I can't.

I've said a lot of things over the years, and the majority of them are still relevant, and I'm listing them here so I can easily find them when I need to refer to them.

blog comments[]

Wikia have apparently changed the format of blog page names, rendering the previously foolproof method of |titleregexp=.*-452-[0-9]{14}$ to be ineffective. Foolproof, but not Wikiaproof, apparently.

However, because Wikia can't get anything right, they have screwed something up.

  • 1319 blog comments with "-452-" in the page name.
  • 136 blog comments with "-5473581-" in the page name. (My user id is 3403151, not 5473581!)
  • 12 blog comments with "-3403151-" in the page name.
  • 1455 blog comments with either "-5473581-" or "-452-" in the page name.

I know who 5473581 is. I bet Wikia doesn't.

The UCP update has screwed up titleregexp

This used to work:


Now this is required:


With absolutely no fucking guidance from the people who forced this update upon everyone.

1467 blog comments

There appears to have been a wikia update within the last 24 hours, where can I find information about updates?

Thanks, I had noticed that the small tags weren't working. I'm really looking forward to the updated stats :)

edit: As of October 2018, the "new metrics tool that will give admins better access to traffic stats about their wiki" has still never been released.

When asked whatever happened to this in 2016, current Wikia Staff had no idea what this was even about.

That's very strange that that small change led to such an increase in edits. Whoever thought of testing that deserves a gold star.

It was slightly confusing to see the bar gone today, but I approve of the change as it removes any sense of "ownership" a person might have, or apprehension that another user might have if the displayed username makes them want to avoid editing the page.

I always felt it was slightly redundant to have the history link and categories in two places anyway.

While I do find the right sidebar useful, it would be nice if it could be reduced so the articles could have more space.

Only the most recent userlevel applied appears. For instance, I became a chat mod after i became a sysop, so that's what appears on my profile.

IP user edits counts show "0".

Strange formatting. [[User_blog:Sarah_Manley/Try_the_New_Wikia_Editor|redesigning the ]][[User_blog:Sarah_Manley/Try_the_New_Wikia_Editor|skin of the ]][[User_blog:Sarah_Manley/Try_the_New_Wikia_Editor|edit page ]]

What's wrong with the spell check in firefox?

Problem #1
I'm using Chrome, and have disabled the Rich Text Editor, and the new editor is showing the browser scrollbar with 4-8 pixels of empty space on the scrollbar. Given that the blog post says "We now have only one scrollbar on the page in the edit window.", then this seems like unexpected behaviour.

Problem #2
In addition to this, when using the "page down" button to scroll the edit area, the summary/preview/publish bar is moved slightly upwards so as to be partially covered by the blue title bar above it. (This only occurs if there is a scroll bar in the edit area.)

And it does not re-appear by pressing "page up", or by using the mouse scrollwheel, the only way of getting the page to show it again is by pressing the mouse button down in the edit box to begin selecting text and moving the mouse cursor to the top of the screen.

Problem #3
The new preview mode is complete rubbish. When I click "preview", I expect to see what the page is actually going to look like, with the correct PAGE WIDTH so I can correctly format the damn page.

Problem #4
The tab order is messed up.

I doubt screenshots will be of much help - unless you want me to take a screenshot of each highlighted link/button, and I haven't decided to switch browsers in the last 6 hours.

The tab order of the old editor is: edit box, summary, minor edit checkbox, follow checkbox, publish button, preview.

The tab order of the new editor is: edit box, summary, wikia link on the top bar, and then all of the links on the top bar.

You have to press tab approximately 60 times to get to the minor edit checkbox. The new editor is NOT ready for deployment.

How does that fix the tab order? The point is that I should be able to tab quickly to the minor edit checkbox using the keyboard as I have been doing with the old editor instead of having to reach for my mouse.

edit: are you saying that the tab order would be different depending on whether the "right rail" was shown or hidden? The tab order is still messed up, whether it is shown or not.

And if you look at the page source, you'll find that the reason for this is that tabindex isn't even set.

New editor: <input type="checkbox" name="wpMinoredit" id="wpMinoredit" accesskey="i" />

Old editor: <input name="wpMinoredit" type="checkbox" value="1" tabindex="3" accesskey="i" id="wpMinoredit" />

No, you won't be disable the new editor. You will still have a choice between "Rich Text" or not, but you will not be able to use the same editor you were using last week.

Problem #5
With the old edit summary, it was a 1 line input box, so could access my previous edit summaries, so my frequently used summaries were always just a few keystrokes away.

Now, if I want to use the same edit summary, I have to type it over and over again.
Even with the right rail hidden, the single line summary box doesn't allow to scroll through previous summaries.

Do you NOT want people to use edit summaries?

Edit: Edit summaries were restored to a single line input with autocomplete almost 4 years later.

What are you talking about?

This has nothing to do with "customization", this has to do with the standard browser-level "remembering what was entered in an input box", otherwise known as "saved form data".

That's exactly it, thanks for the screenshot :)

Wikia obviously don't see cat-killing as enough of a deterrent. You need to step it up a notch, perhaps sending them the corpses would be a good start?

I wouldn't mind changes being forced on us so much if it weren't for all the bugs. The thing that is most "consistent" is the bugs, which make Wikia look really unprofessional. (Although most new users who encounter the bugs will blame the individual wiki for the problem, instead of Wikia)

Not bugs, but I was planning on posting these questions today anyway:

  • What's with the font? What was wrong with the old font? (Chrome, RTE disabled.)
  • Templates box, how do I change what is displayed? The default templates shown are not useful, or commonly used.

Not directly related:

  • Section edit links on multiple articles, on multiple wikis, are sometimes being displayed before the section heading.

There are 2 parts to the new editor, the old RTE and "source mode" are both being replaced by new versions.

I would approve of it being fixed and unchangeable. There's not really any reason for anyone to remove the section name from a comment.

Having it separate would make our saved form summaries even more useful, since they could also be used when editing sections.

The only trouble is, if it's a long section name, the space for comments is shortened. I assume the total length of an edit summary is a wikimedia restriction which is not easily changed, so when programming it, you would have to ensure the max characters of the editable comment box takes into account the section name.

You should find the bugs yourselves before announcing that you're rolling out the new editor.
The only reason I enabled the new editor and reported the 8 issues I found was because I didn't want to have to put up with a half-finished editor. I can see it wasn't worth the effort, since you've pushed back the release anyway.
I shouldn't have to report bugs about a forced update that I don't even want.

edit: not much has changed in 9 years.

I'm asking why the font is being changed from what it currently is to something different. In my opinion, the new font is harder to read.

Thanks for letting me know about MediaWiki:Editor-template-list. It looks like they've already fixed the edit link problem, but thanks. :)


I agree with the statement that it's an established convention that the submit buttons on a form should be below the input boxes.

I too would like to reset my profile to not display that section. As a temporary measure, my top wikis are community, help, gaming and vstf. :)

Whatever the new font is, something about the edges make it difficult to read.

What's wrong with using an old-school font like courier? Do you think people would really think "i'm not editing here, that font looks old!"?

Fonttest-courier.png Fonttest-consolas.png

  • The lines in consolas are sometimes more than 1 pixel in width, making it appear more "bold" than courier.
  • The curves have more jagged edges in consolas than courier: compare the letter q
  • Also compare the letter v, even straight lines appear jagged, making the letter non-symmetrical.
  • An x, while displaying the vertical symmetry than the v does not, is not horizontally symmetrical.
  • The line height in consolas is 1px taller than courier, each letter is 1px taller, making them appear stretched.
  • So if you were to line up the top of the first T in each image, the bottom of the p on the last line in consolas is 5px lower than in courier. Consolas uses more space than courier.

Yes, I can just override the font myself. I'm telling you why I'm doing it and why changing to Consolas is a bad choice.

You haven't fixed the tab order. edit: reported here

Is the category selector going to be improved? I'm not using the Rich Text Editor.

How is it an improvement that I can no longer use autocomplete when selecting categories?

The first problem I reported still has not been fixed either, there is still several pixels displayed on the scrollbar, meaning that there are 2 scrollbars on the screen.

The width of the preview is still not the correct width, meaning that the word at end of each line in the preview is NOT what will be displayed on the saved page.

Hopefully when it is made user-specific, it will default to "MediaWiki:Editor-template-list" if a user hasn't customized it themselves. I doubt many users will bother customizing it themselves, so it would be better to display useful templates that an admin has chosen, rather than the default templates, which are often useless.

+1, hopefully this will be changed to restore the removed functionality.

But there have been several features removed from non-RTE view, which doesn't make sense.

Suggestion: make the "are you sure you want to leave the page" popup optional. Default it to true, but allow it to be disabled in preferences.

"Working on the category interactions wasn't a focus of this work (but that doesn't mean we've forgotten about it)." It wasn't a focus, so you just decided to remove it completely? Not cool.

Thanks for fixing the "page down" problem, hopefully you'll fix all of the other issues soon, so the new editor is as usable as the old editor.

Wikia: where "improvement" means "removing functionality"

I wouldn't mind being forced to use it if it was FINISHED before release. I was really hoping that they were pushing the release back a week so they couldn't actually fix things first :/

I just noticed that the preferences has the option "Disable Category module (only applies if editing in visual mode has been disabled)"

If there is already an OPTION to disable the Category module, why are non-RTE users now being forced not to use it?

It is possible to collapse it, if you click just to the right of the scroll bar.

If you choose not to follow pages more often than you do, then you can choose not to follow pages by default in your preferences.

It's still happening everywhere for me. It's happening on this page:

I'm using Chrome.

"The reason you can't disable it completely when the visual editor is enabled," I'm not talking about the Rich Text Editor. I'm talking about ENABLING the Category Module when NOT using the Rich Text Editor, as the check box says it does.

You can edit your comments by hovering over it with your cursor and clicking the small "edit" link in the lower right side of your comment box.

"Improvements to the keyboard tabbing order" - If that means "Re-adding the tabindex attributes which were removed", then hooray!

"Your current talk pages will be archived. No data will be lost, and you’ll still be able to find the posts, but the old user talk pages will be protected from future edits."

Using the standard protection method, or will admins also be unable to edit these archived pages?

"I've already left once." - and yet here you are.

"So how are we supposed to contact any individual user directly with this thing?"

You don't appear to understand that the message wall replaces user talk pages, you leave them a message on their message wall instead of leaving a message on their talk page.

You are using the AKA field wrong. The AKA field was always intended to be what you prefer to be called. If you don't want to be called "Mark", then don't put it in your AKA field.

is this thing on?

I also do what SpikeToronto does. Except I don't notify them that I've responded: if they choose not to read my talk page notice, and choose not to follow the page for replies, and choose not to check back later, that's their choice, and not my problem. Fragmenting conversations makes no sense, and is hard for other people to read.

As I said: You don't appear to understand that the message wall replaces user talk pages.

Look at the image: File:Messagewall-fullscreen.png - Each user will have a message wall, it's not a hard concept to grasp.

Wikia welcome messages are kinda broken. User welcomes are not using MediaWiki:Welcome-message-user, and I don't really like the fact that the automatic welcomes are added to my contributions list. While it is one thing to sign it as me, it's quite another to actually make it look like I've recently been active when I haven't.

For one thing, this may cause users to think I'm ignoring them.


It hadn't struck me that this caused this. Fuck, it's worse, they're not just locked, they're impossible to access. (Well, I can't get to them, at least) User:452/Lists/Weapons has 11 talk messages, but clicking the talk link just redirects to the message wall. That's NOT expected behaviour at all.

I do not find Acer4666's tone to be un-calm.

I also hate that it makes me look active when I'm not, and that it adds to my edit count. By having it look like it's NOT automatic may also encourage new users to leave welcome messages when the bot is slow (which is often is lately, and I have already once informed a user that the welcomes were not manual)

Unfortunately not.

I wish it were like this, or at least that there was an option to use text-only emoticons.

Lack of indictor seems like a positive thing.

How are you going to block problem users if they behave themselves when they know you can block them?

Strangely enough, I had just done a search using what i knew was the article title, intending on going straight to the article, and was about to report it as a bug. I checked my email first and saw this update.

I agree that "Exact Search" searches - using quotation marks, should go to the search page, but when putting the exact title of an article in the search box, I really expect to jump to that article, and thing that displaying the search page instead will cut into productively greatly.

Unless your goal is to get more page views by forcing people to view an intermediate search result page whenever they're trying to get to an article.

Can we please have the option to go directly to the article as before?

"often, you won’t even need to finish the word before it suggests the right page for you."

I type faster than your autocomplete autocompletes, so it is faster for me to type the title and hit enter than type the title, wait several seconds, then press down and enter.

My personal productivity is already down due to the new editor's side effect of disabling locally-stored saved form history. (Meaning no local auto-complete for edit summaries) I was told that this would be addressed somehow, but it still hasn't.

And speaking of searches, I filed a bug report a while ago (edit: 2011-12-29 ) about ctrl-click in searches not opening a new window. When is this going to be fixed?

I've noticed this occasionally, but only in cases of files which have been deleted for some time. I've not ever had a problem restoring a file that I have only just deleted

I assumed that files are purged after some time of being deleted.

Chrome, latest version. (on winxp, but the same is happening with ubuntu)

I just tested it here,

  1. typed "search" in the search box on this page
  2. held "ctrl"
  3. clicked on the first result
  4. released "ctrl"
  5. search page was replaced by first search result, instead of opening in a new tab.

Just to eliminate any possible confusion, I'm talking about search results displayed on Special:Search.

Ugh, I didn't even realise this, but yes - I have created many redirects so that popularly searched terms display the appropriate article.

I know that redirects still work, my point is that I have created many redirects so that people are not shown search results.

For instance, there's an article called "Toad" about a 4-wheeler in the game. This 4-wheeler is once referred to as ATV in on-screen text, so a lot of people call this vehicle "ATV", and in the past, people had tried to create an ATV article instead - which proves it was a popular search term.
When searching for "ATV", the first result was Toad already, but since it was 100% certain that anyone searching for ATV would want to see the Toad article, I created the redirect "ATV" to point to "Toad" - so that they weren't shown the search results.

This change, to show search results even for title matches, completely destroys the purpose of these redirects which were created because they were popular search terms. (which I believe to be what Xd1358 was trying to say, but I could be mistaken)

Ah, I see what you're saying. I see the exact same thing on my wiki. - shows a message, but viewing the page does not, when it clearly should. (As an admin, there will still be a "Undelete x edits" option, but users see nothing.)

Definitely a bug, if you haven't already done so, you should report it via Special:Contact.

Edit: As of 2016, this issue has never been fixed, nor did Staff ever comment on this change.

I don't even remember that, it was either before my time, or I just never used "search". And I was going to suggest adding a second button as a solution to the problem!

I definitely agree with this. Google has had two buttons for over a decade, and they're a proven success - if no-one used "I'm feeling lucky", Google would have removed it by now.

The previous Wikia search was the best of both worlds, if there was an exact match, you were lucky, and if not, you get search results. This was an improvement on Google's 2 buttons! This was Wikia kicking Google's arse in the search department!

A similar tip that should work for most browsers:


as a search engine.

Unfortunately, after some playing around with that, there appears to be a problem with using "I'm feeling lucky" for long search strings, so your miles may vary.

My first thought was "No, that will lead to hundreds of anon users creating pages for search terms", but on the other hand, it would directly show what people are searching for, and any mis-created pages could easily be turned into redirects to appropriate pages.

  • Simply hitting "down" and "enter" works just as good.

Re-learning habits aside, I type faster than autocomplete autocompletes, so I must "type, wait several seconds, press down and enter", which cuts into my personal productivity.
It also cuts into everyones productivity because everyone now has to click on a search result, even if they were intending on being taken directly to a page.

Since some people say: "But I like going directly to articles", and others say "Good, I like being able to view search results", I think we can both agree that we would both like to be able to choose that option in our preferences, instead of forcing the other half to do things the way we like to do them.

As a programmer myself, that comment tells me that you aren't a very good one.

Having options for both is completely feasible, and would entail only a few lines of code - most of which are probably already there, commented out, since wikia once had both a "search" button and a "go" button. A simple change to the "which button was pushed" if statements to check "which preference is set", and there you have it.

A better solution to the problem would be to simply have both buttons again - that way people who want to search can press "Search" and get "Search results" and people who want to Go to an article can press "go" and go to an article. If hitting "Enter" defaults to the search, I can live with that, so long as the Tab index is set correctly so I can just tab once or twice before hitting enter. (Wikia has a problem with setting Tab indexes - they still haven't fixed the new editor)

  • "It has to be one or the other." + "this change benefits more people than it hinders."

I'm all for benefiting more people, and believe in "the greatest good for the greatest number", which means pleasing everyone whereever possible, and in this case that translates into giving people a choice.
I do not see any reason at all that there cannot be both a "Search" and "Go" button in order to give everyone a choice.

Well, I can think of one reason to force everyone onto an intermediate page, if that intermediate page happened to contain ads.

If Wikia is changing it so search results page are mandatory, they should also assure that the search index is totally up-to-date, since the current system may have a (now unacceptable) delay to include new pages on the index and preventing people to reach the article.'

This! 100 times this!

I've been reporting various issues with the search not updating over many months and I've been told via a support ticket that there are wide changes coming to Search results, so hopefully that means regular updates.

I did some extra searches for some of the text on that page and still didn't get any results, so I'd say it's because the search index for that wiki hasn't been updated since that article was created.

I was surprised to see that you created it on the 5th of January, I knew there were delays with the search index, but at the very least, I expected that newly created pages had some kind of priority.

Yes, this would be perfect.

I wouldn't even complain if "search" was the default form action, as in "Press Enter to Search", so long as the tab index was set correctly to allow me to type, hit tab twice, then press enter to press the "Go" button.

It's something else entirely, I have no idea when any kind of updates happen, but search on the wiki I mainly use gives results from pages deleted a year ago.

Seriously, more than 365 days ago, we had a vandal vandalise - and move - a bunch of high-traffic pages, the move resulted in a bunch of spam titles appearing in the "following" lists of many people - those pages are still listed there, and searching for certain obscene terms still brings up the long-removed vandalism.

But wikia support assures me that changes are coming soon...

" Special:WantedPages were working fine."

Have you see recently? - Those blue links should not be there.

I agree that the other problem were caused by the video system change - but I'll wait until the update tomorrow before commenting on that.

What time on wednesday do system updates happen?

Hopefully this means you're recording data on how many people are clicking the first search result.

And hopefully 90% of people clicking the first search result will matter.

WantedPages is still showing links that should not be there, related to the changes to the video system.

Thanks. I'll remember next time to specify which timezone I want, to save you from listing 3, and to save me from having to find a converter.

So that's 11:00-13:00 GMT, a few hours after the ~6:00 GMT SpecialPages update on the wiki I use, so any WantedPage fixes won't be apparent until today's SpecialPages update.

There's another problem with this which has been bugging me for a while: even when you don't search for a redirect name, many search results show a redirect next to them.

I think that a search result should only list a redirect if the redirect is somehow related to the search.

(Reporting this via Special:Contact with more details.)

Right-clicking on "Join the chat" in the sidebar is not giving normal link options, but ctrl-clicking successfully opens a new tab.

(Right-clicking the link in the top nav still works.)

I think that's covered by "Reduced the time it takes us to refresh the index that powers search results."

That's something that has been bugging me for the last year, since I first noticed that Vandal created pages were quick to be added to the index, but slow to be removed.

Hopefully deleted/moved search results will be improved soon.

"personal use only means personal use only."

If people want to add it globally, they will.

"..and this does none of that."

There's a theory that the only reason we are being forced onto the search page is due to the fact there are ads on that search page. And historically, search pages are good places to add ads relevant to the search results (just ask google)

So restoring the search to go directly to articles definitely "obstructs the proper functioning and view of advertisements,".

I'm not sure how to answer this apart from saying "the normal options which are shown when right-clicking a link" - which is just the words I previously used, re-arranged.

By "link" I mean "hyperlink", typically written <a href="link">link text</a> I'm specifically talking about the link text.

By "right-click", I'm talking about clicking what is usually set as the right button on the mouse, but as left handed people would use "left click" for that, I suppose I should say "the context menu button"

By "normal", I mean the options which are usually shown in the context menu.

By "options" I mean menu choices.

So I guess what I mean by "normal links options" is: The standard choices which are shown in the context menu when the context menu button of the mouse is clicked while hovering over hyperlink text.

Specifically, the "normal link options" or "standard hyperlink context menu choices" which are not being shown are "open in a new tab", "open in a new window", "copy link address" and a few others.

I hope this helps.

I don't think it would be possible to use javascript to add that option to your preferences, as that would require a server-side script for database access.

Or do you mean using javascript to set cookies? Good idea.

"1) We are adding a personal preference that enables "Go" search for individuals. "

Thank you for listening.

" so users can expect the same functionality from each wiki."

I didn't think consistency between wikis was expected.

User:Starfleet Academy: So?

User:Rappy 4187 " Hiding Wikia's ads via [[...] CSS is well within your right as a user."

I didn't realise that, thank you. (I use adblock, which AFAIK stops the ads from being loaded entirely, whereas using css would still load them, they just would not display - so CSS would not stop malware in ads)

Me: "Can we please have the option to go directly to the article as before?"

Wikia: "1) We are adding a personal preference that enables "Go" search for individuals."

Thank you for listening.

"Having an option for both functionalities is simply not feasible."

1) We are adding a personal preference that enables "Go" search for individuals.

I agree that it shouldn't be against the rules to add functionality/features. It should only be against the rules to change the button from "search" to "go".

I once added extra useful links to the "On the Wiki" nav tab, without removing any links, but Wikia staff politely ordered me to remove them.

I would like to know exactly which part of the rules forbids adding functionality, because I cannot find it.

The most obvious line which is close to applying here is:

Not to intentionally block, remove, or otherwise obstruct the proper functioning and view of [...] user interface and functionality by other users, including but not limited to changing or adding javascript or CSS changes to the Service that would prevent the proper display or function of [...] user interface and functionality;"

but that forbids only to "block, remove, or otherwise obstruct"

Adding a "go" button, or adding extra links does not "block, remove, or otherwise obstruct" anything.

The other line which is close to applying is:

You will not: (i) take any action that imposes, [...] an unreasonable or disproportionately large load on our infrastructure; (ii) interfere [...] with the proper working of the Site

i) - adding a go button reduces load on the infrastructure.
ii) - it doesn't interfere with people who want to search, it simply adds the functionality for people who want to go.

edit: Thanks for the clarification, Dopp.

I think it is pedantic to say "You are not allowed to add a second link to search, because there is normally only one search button, and therefore adding a second button "prevents the proper display of the user interface".

It is equally pendatic to say "you are not allowed to add extra buttons to "On the Wiki", as "On the Wiki" normally has 4 links, and therefore adding extra links "prevents the proper display of the user interface"

"Special:WhatLinksHere was giving incorrect results, most notably for videos."

Excellent, finally fixed, thanks!

I agree with not prompting users to create new pages when they search.

"Oh god and it seems to have some sort of personalised memory where it shows top results of things you've clicked on in the past."

That's called "form history" or "saved form data" and has been a standard browser feature for the last 15 years.

I know it's browser level form history and not some fancy wikia-only history because it's displaying what I've typed into search boxes on other sites.

(On releated note, I'm still waiting for Wikia to re-enable form history for the edit summary field)

Oh, ok, nevermind then.

In that case: why is Special:Search showing browser-level form history instead of wikia autocomplete search suggestions?

Redirects are now shown in the dropdown, hooray.

Problem with Special:Search

In my preferences, I've set "Enable Go-Search", but I wasn't expecting this to apply to searching when I visit Special:Search directly.

Also, in the lower left corner of the screen, it should say "Following", click it and it will change to "Follow".

Special:WantedPages provides an "alert" for what pages are demanded for creation.

Re:disabled link suggestions

I'd assumed that it was a local problem with AJAX being broken and was planning on restarting my browser someday soon to see if that would fix it, good to know I don't need to. (But I am missing link suggestions)

Yes, that's what it says in the post.

We've temporarily disabled search suggestions and link suggestions while we work on backend issues.

Fixed now, thanks!

"Do not ask for rights."


Since it was listed under "5 tips for new folks ", I took it as meaning "Do not ask for rights when you first join a wiki".

But I do believe there are correct times in which it is okay to ask for rights.

  • If an admin has put out a request for people interested in rights. (Obviously!)
  • If current admins aren't active enough and more are needed. (Hopefully in a polite "Hey, could you use a hand?" way, rather than a "You're not doing your job" way)
  • If a user is constantly requesting admins to do admin-things. (A good admin should notice if a user needs admin rights in this way)

I don't see any personal benefit in having admin rights, and had no intention of becoming an administrator. However, I was constantly leaving messages with the admins to do admin-stuff (moving locked pages, etc), so it made sense for me to become one, although I still didn't want to ask for them.
I would have been content being an active normal user indefinitely, but the admin rights definitely helped me improve the wiki much more than I would have been able to as a normal user.

I give out rollback rights to anyone who uses an undo on vandalism a few times, as it's a tool they can use to better do what they're already doing. In the same vein, I'll give admin rights to people who need to use those tools. I've only given out admin rights once, that user never asked, but has been a great contributor and was an obvious candidate.

I've only had to deal with a beggar once, and it was bizarre. On his first day editing, he posted saying he was intending on making many contributions and that he wanted admins rights to make it "worth his while", after I told him he no, he arguing about it. Really weird. (I can't find the conversation now, or I'd be more specific.)
After that, I added a list of things admins are expected to do to the Staff page, with a note that anyone doing those things will be considered for admin rights, so that I can point to the list if anyone asks in future. Obviously they can't do admin-specific stuff, but they can contribute to admin-general stuff, like undoing vandalism, watching various SpecialPages for problems, and contributing to discussions.

There was also an issue with a former admin (before I became an admin) who claimed he "needed" admin rights to be a good contributor. I pointed out all the admin-things he should have been doing but wasn't, and the admin at the time, told him he'd re-considered him in the future, but that wasn't good enough for him, and he stopped editing. (As a side note, it's been a year and I'm still cleaning up old mistakes he made)

No-one "needs" admin rights. As I said earlier, there's no personal benefit : the time I spend "doing admin-stuff" takes away from the time I spend otherwise contributing. But someone's gotta do it.


I know how to get a database dump from Special:Statistics and search for those elements, but that might be too much work for a lot of users (and admins!).

I think the simplest solution is to replace all relevant tags with templates based on the function of the tag. Replacing <center>centered text</center> with {{center|centered text}}, where {{center}} is a template for a <span style="text-align:center">{{{1}}}</span>. This is possibly something that could be done by a bot en masse - although it would probably have to be an opt-in service.

Perhaps Wikia can offer some kind of automated tool to generate a report of pages containing deprecated tags? Special:OldHTML perhaps?

Thanks for pointing that out, I'm not getting search suggestions either.

So "no comment" on the suggestion of a Special:OldHTML page?

The upgrade has just occurred on the wiki I use, so it would certainly be handy to have now.

I notice that is still using 1.16.5. I usually use Central as a place to verify whether the issue is a local issue or a wikia-wide one. So at first I thought that the upgrade issues must have been due to a local javascript conflict.

I've just filed a couple of bug reports related to the upgrade. Amongst a bunch of little things, I noticed a major problem with the editor page. The "Add features and media", "Categories" and "Templates" sections are missing. I'm not sure how something that big was missed during testing.

I've never liked the changes related to the editor sidebar, and the issues I've reported have never been fixed, but even if we can't have the old category selector back, I'd still like to use the Categories field. Oh, speaking of issues which have never been fixed, the upgrade has also broken my bandaid for the tab index problem. So thanks for not fixing that, and for breaking my fix.

Due to the categories box being absent, I've had to temporarily disable the category module in my preferences in order to edit categories.

"we want to keep the collection clean, relevant, and organized. Please keep us aware of what preferences are important to you and for what reasons,"

All preferences are important to me. The more the better. I prefer to have preferences.

I understand the desire to keep things simple for people who prefer simple things. And I understand the desire to have the default options accessible for people who prefer simple things.

I don't see any reason why advanced users shouldn't be allowed to access as many advanced options as possible.

Any time there is a functionality choice made behind the scenes of any programming project, it's a no brainer that the other choice which wasn't chosen as the default should be available as an option. On the one hand, this allows tracking what people actually want (Of which I'm sure you're aware), on the other hand it allows people to use what they prefer.

I'm all for having a "clean"(read: short and simple) basic options page, with only common options which the majority of people change, but there's no problem with having slightly less "clean" advanced options page.

Is this same problem also affecting other areas? I'm noticing that standardeditsummaries.js isn't working on any wiki. I know MediaWiki:Common.js itself is working. Is importScript failing?

Good question, I too am interested in an answer.

Thanks for writing this post, it explains it well, and will be handy to show to other users.

I'm glad you've specified that it also applies within wikia, because many people have been confused about that in the past.

Side-stepping whether fair use collages are under CC-BY-SA, collages are still derivative images which the uploader has put work into, and if someone copies it, they're still re-using the uploader's work and should link back to the source. ("Should" being more of a courtesy rather than legal requirement)

I believe the fact you don't "own" the copyright of an image you have edited and uploaded, doesn't mean that your contribution to the image should be completely ignored. Is this wrong?

(I know the issue gets even trickier still when another user is obviously re-uploading images which are unedited fair use images which are widely available anyway, so let's just stick with talking about clearly edited images like collages which have been created by the uploader themselves. Although I believe all sources should be credited, even as a "finders credit")

A question immediately springs to my mind: What are your plans for the old forum?

With the Message Wall, the switchover wasn't/isn't handled very well. Old Talk Pages became archived, and only admins can edit them - there were still many open conversations on those talk pages, so it was a little abrupt to lock them.

Solution: Add "editwallarchivedpages" to the "Users" group -452 (talk) 19:17, January 6, 2015 (UTC)

This problem will be even more pronounced with Forums - often there are open questions which may still require a response, and locking them all would be detrimental to any wiki which values such things.

Grandfathering the old forum posts in somehow would be far better than locking them. Simply providing local admins with a method of migrating old posts would be a great way of dealing with it.

While I understand that converting old style talk pages to message wall posts isn't something that could be easily automated, even with a one-at-a-time migration tool, forums are pages, which have a creator, which can be read by the migration tool and used to author the new "post" based on the old forum page.

At the very least, leave forum pages writable, even if creating new pages in the Forum namespace is locked.

While on the topic of the Message Wall, I welcomed the introduction of it and reported many issues within the first week of it being added to Wikia labs - however, most of those bugs have still not been fixed.

Ditto with the new editor, I reported many bugs in the first week, and even simple things like tabindex have still not been fixed.

Do you plan on fixing bugs in new Forum system once it is released, or will you be releasing it and abandoning it like the Message Wall? I had the expectation that bugs would be fixed, so I left the Message Wall enabled, but now the Message Wall has been in use far too long to simply disable it and lose all the conversations.

If the same is going to happen with the new Forum, I'd prefer to know ahead of time.

The first Message Wall bug that springs to mind is: when's the last time you looked at Special:WantedPages?

The tabindex problem is that when pressing tab while editing a page first goes to the edit summary box, but then it goes to the word "Wikia" at the top of the page. Prior to the editor update, the tabindexes were set correctly to tab to the minor edit button then the submit button (my memory is fuzzy whether it tabbed to preview). In the new editor, the tabindexes just aren't defined.

Another problem which I curse every day is the new textarea summary box. Previously, it was single line input, which meant anything typed there was saved by the browser when the form was submitted, so common edit summaries would autocomplete, making leaving edit summaries a lot quicker. Textareas do not do this, as they are multiline. Since newlines in edit summaries are ignored anyway, there isn't any benefit to using a textarea.

I'll have to track down any other outstanding problems and get back to you.

Various Message Wall Problems

The most recent one I've reported was that audio files cannot be played on the message wall.

Original issues

Talk page archives
  • The owner of a talk page should be able to edit their own archived talk page in order to respond to old messages. This is less relevant now as those conversations have been dead for months. However, I have (previously) left many messages on the talk pages now-inactive users, asking them for followup information, or if they're still active - the fact that they cannot edit their own pages to respond may put them off.
  • Owners of talk pages should be allowed to perform their own maintenance on the talk pages, such as removing dead links, instead of requiring an admin to do it.

I know there isn't a default protection level for "admins and page owners", but perhaps there should be, as individual user pages should be locked to the user alone by default anyway.

  • This issue is also relevant to consider in light of the upcoming forum change - and possible archiving. While I agree that having two options would be confusing, locking open discussions isn't productive.

Various message wall related links appear on WantedPages

There are related three issues with Message Wall and WantedPages

  • Links to individual Threads appear on WantedPages as blue links
  • Links to archived talk pages appear on WantedPages as blue links
  • Redlinks in deleted Threads/messages appear on WantedPages (This one may have been fixed, I haven't checked)

Although I originally left examples intact for reference, I don't have any extant direct examples, because I changed all problem links to external links to remove them from WantedPages.

User Talk Sub-subpages

I was told that this bug would be fixed. In May I moved pages to avoid the problem, so I have no extant examples.

ALL talk pages in the user namespace redirect to the message wall, leaving some talk pages associated with sub-subpages in the user namespace inaccessible.

  • Example 1: User_talk:452/Titles works as expected, redirecting to archive of that page
  • Example 2: User_talk:452/Lists/Modifications?action=edit - linking to edit page to prove page has content, view page directly and it redirects to the main page
  • Example 3: User_talk:452/datafiles/Titles?action=edit - a manually inserted redirect works.

Thinking about it now, perhaps the Message Wall implementation should not have been a separate page, perhaps the message wall should be done similar to blogs - at the bottom of the main page. This would enable comments to left at the bottom of each page in the user namespace, including sub-sub pages.

No edit summaries

While it's not really a bug, it would be nice to be able to leave an edit summary when editing a comment. Doubly so as an admin when editing someone else's comment, it would be nice to be able to have an edit summary noting the justification for editing someone else's comment, which isn't always immediately apparent, even when viewing the diff log.

That's all the Message Wall problem I reported via Special:Contact, and in the thread with Ohmyn0, there may be others I mentioned as blog comments here. All issues with the editor I posted as Blog comments, I'll get to them next.

Various editor problems, originally reported on

Category Module I although I prefer to edit with the RTE disabled, I also prefer to use the old-style auto-completing Category Module - which is still displayed at the bottom of each article.
I logged in to my non-admin testing account recent and noticed that this Category Module is still enabled as part of the RTE.
There's an option in the preferences to enable/disable to category module, but with the RTE also disabled that only controls whether [[Category:Manual Categories]] are entered in the main edit area or in a small category-only area.

There was a long standing category related bug where after previewing an article, and pressing the submit button in the preview window, the categories would be duplicated - I'm unable to reproduce this problem right now, so maybe it was fixed recently, but it was happening for many months. Perhaps it was fixed during the mediawiki upgrade


When pressing tab while editing a page first, the focus first goes to the edit summary box, but then it goes to the word "Wikia" at the top of the page. Prior to the editor update, the tabindexes were set correctly to tab to the minor edit button then the submit button (my memory is fuzzy whether it tabbed to preview). In the new editor, the tabindexes just aren't defined. I added some JS to fix this and restore a sensible tab order, but it's currently non-functional due to an upgrade related problem causing multiple sidebar modules to vanish. (The JS isn't causing the problem, it also occurs here.)

  • In the comments where I originally reported this, it was indicated that this problem would be fixed.

From my original comment in August 30.

  • The tab order of the old editor is: edit box, summary, minor edit checkbox, follow checkbox, publish button, preview.
  • The tab order of the new editor is: edit box, summary, wikia link on the top bar, and then all of the links on the top bar.
  • You have to press tab approximately 60 times to get to the minor edit checkbox. The new editor is NOT ready for deployment.

As this has still not been fixed, the new editor is therefore still not ready for deployment, despite having been deployed for 11 months now.

  • This comment says it was going to be fixed, but it hasn't.
    • And by attempting to direct link to a comment, I've revealed another bug: links to blog comments are partially broken. An external link works, but an internal link does not.

edit summary textarea Previously, the edit summary was a single line input, which meant anything typed there was saved by the browser when the form was submitted, so common edit summaries would autocomplete locally, making leaving edit summaries a lot quicker. (I often do essentially the same edit to multiple pages to fix related problems at once, so a saved edit summary is helpful) Textareas do not do this, primarily because they are multiline. Since newlines in edit summaries are ignored anyway, there isn't any benefit to using a textarea.

  • I was never told that this would be fixed, but that it would be considered. Whether or not anything is done about it, this is an instance of the editor upgrade removing functionality.

Edit summary length There is no max length defined for the edit summary textarea - which means you can type a nice long descriptive edit summary, only to have it truncated in the history. Setting the max length attribute would allow it to be reworded instead of having it truncated without warning.

  • This may have been a problem in the old editor too.

page down scrolling more than a single screen The behaviour of the page-down button should be to move the currently visible line at the bottom of the input area to move to the top, either just out of view or as the first visible line - this is the de facto expected behaviour as this is how it behaves everywhere but wikia.
What it is actually doing is moving the cursor down exactly one page, but if the cursor is in the middle of the screen, it is now at the top. The only time it works as expected is if the cursor was already at the top of the screen. This means that some content is scrolled past, unseen.
I'm using Chrome and WinXP and realise this may be a browser specific problem, but I don't remember this being a problem with the old editor.

I'm not done going through my past reports, but have to go AFK for a while. If there's a reply by the time i get back to this, I'll leave a new comment, but if there's no reply, I'll edit this one. I think I'm done with this list.

Just remember that if you see a post from yourself that says "a minute from now", you need to remember to post it a minute later or you'll tear a hole in the time/space continuum.

The most important bug fix wasn't even mentioned in the post: All modules are now displayed correctly on the edit page again!

Thanks for fixing it.

Lazy loading sounds like a great idea.

edit: For the record, while it did sound like a great idea, it was not. Lazy loading reduces the amount of content which is discoverable through search engines, reducing the volume of new traffic to a wiki.

I believe that this is part of the "extending past the bottom of the pop-up." problem which has been fixed.

Here are the latest technical updates at Wikia. Keep in mind that our system updates traditionally happen every Wednesday (this week we are releasing our code Thursday the 16th)

edit: I try to avoid replying to messages which have been censored by admins.

there's a history link at the bottom of your comment when you hover.

All I can find about the saying is that it's from Northern Ireland, and favoured by people's grandmothers.

I have successfully joined

Debugging was my first thought as well, but after considering it, I realised that it's not really a problem: if you need to debug, you disable minify and re-enable it once you've finished debugging.

Kinda like with compiling a program: you don't debug the compiled program, you debug the source.


You may have noticed new files on your wiki with "Wikia Visualization" in the file name.

Yes, I noticed them pop up in both Special:UnusedFiles and Special:UncategorizedFiles. I deleted them immediately as they were duplicates of existing images with no edit summary. They re-appeared today with HTML in the summary instead of wiki markup.

The "number of videos on this wiki" figure was incorrect.

Seems like there's a lot of incorrect figures going around!

Incidentally, why are newly created wikis not using MediaWiki 1.19? Surely it would make more sense for them to use MediaWiki 1.19 immediately rather than using the old version for a few weeks until they're switched over. There would be fewer conversions to be done that way.

"A wiki about an event that has already passed, or a franchise that's basically dead, or a movie that's long since out of general release shouldn't really be eligible, should it?"

This kind of attitude is widespread these days, and is detrimental to the internet as a whole.

On the contrary, wikis about things which are non-current need more advertising than something that is a current event.

How many visitors has w:c:tardis had over the past 36 hours? I'd bet rather more than usual. Does w:c:tardis need promotion right now, or do you think maybe you'll get more traffic simply because there's current activity in that wiki's scope?

I don't understand what jpg files have to do with protecting the page.

All good points.

One other thing worth mentioning is when quietly removing their vandalism, trying not to leave any trace behind.

When deleting pages, or just undoing an edit, it's best to remove the default message - which may include part of the vandalism and their username - and just replace it with the word "vandalism".

Btw, you have a typo in your categories: "Wikia Tips & Tricks" should be just "Tips & Tricks"

This post does not interact with trolls, therefore it is not feeding them.

This sounds like a fantastic idea. Hopefully the same information given locally to admins can be written up into how-to blogs here.

This same argument has come up recently in Australian politics.

That definition is not true anymore. At least not most of the time now a days.

Over the past year as a local wiki admin, I've seen hundreds of instances of random anons inserting a random rude word into an article, and not a single instance of someone doing something akin to one of your examples.

While "Political trolling" does indeed exist, that doesn't mean there aren't still plenty of old-fashioned in-it-for-the-lulz trolls - which is what this blog post is talking about.

Nothing in this blog post instructs anyone to chastise people who respond to the trolls. The actions of your hypothetical "community of people who yell at victims" do not negate the advice in this blog post, and in fact are contrary to it, as their actions are "feeding the trolls".

Overall, "Don't Feed The Trolls" means "Defuse the situation".

How to deal with people who bully victims.

Bullying is bullying and should be dealt with equally.
On the wiki where I am an admin, anyone harassing a troll gets the same treatment as the troll. (Specifically, some users have responded by editing the Troll's user page with insults. This is against the Wikia TOU, no matter what the recipient has done.)
If anyone were ever to harass a user for responding to a troll, they would also get the same treatment as the troll.

I'm looking at this page but still have a little popup box which says "Find out about layout and navigation changes happening on October 3."

edit : 10px may not seem like much to a lot of people, but I could certainly use it.

Technically, the entire site layout is "forced" on people.

"Images, tables, etc see no change."

I don't understand this line.

The content space will increase by 10px, as BertH has noted was noted. Everything in the content area can use this extra 10px.

Open a page containing a large table and test it for yourself by adding adding ?wikiagrid=1&wikiafullheader=1 to the end of the url.

  • If the table is set to 100%, it will stretch a little further
  • If the table is set to 660px, there will be 10x of whitespace beside it.

You can open the same page in a different tab normally and flip between them to see the difference.

  • One way to measure screen size is to take a screenshot and use your favorite image editing program
  • Another way to measure screen size is to use some screen calipers. I use this:

Yes, they're already 1px wide, so it's not possible to do what you've shown until someone invents a half-pixel.

Noooooooooooooooooooooooooooooooooooooooooooooooooo. :(

Here's a few ways it could be done.

edit: Nevermind, I just realised I recognised that username. Tycio thinks creating categories for hair colours is cool, and I've already made the mistake of giving them attention once.

File:Trolls2.png is licensed under the CC Attribution-ShareAlike 2.0 licence, so yes. Just remember to cite the licence and source! :)

You're allowed to use javascript to add links.

see for an example.

I suggested a few months ago that "community messages" be displayed there, but having it as a customisable with multiple options is an even better idea.

Everyone who thinks this is a good idea should use Special:Contact to let Wikia know that they want this.

Oh, that sucks.

I find it hilariously depressing that copyright on objects is so restrictive, yet I have no rights to photographs taken of me. Specifically, I'm unable to say "I do not give you permission to publish that photograph of me" - even if I tell the photographer beforehand that I do not give them permission to photograph me.

Perhaps I should hang a Troll doll around my neck at all times.

A full body Troll costume then?

Not a full solution though, as there are many places nowadays where you are not allowed to wear a mask. Even driving a car while wearing a mask may cause an officer to pull you over and ask you to remove it. (I was in the back seat when this happened once, and was still asked to remove my mask.)

So the solution is to follow around judges and other lawmakers, constantly taking and publishing photos of them until they give themselves and everyone else the right not to be photographed.

That template works fine for a page with lots of text, but on a well-maintained wiki, special pages such as Special:DeadendPages should usually be empty and so are only around 600 pixels in height, meaning that following the template will leave an ugly gap.

Spam is a catch-all term for anything unwanted.

The origin of the term is from Monty Python's Spam sketch, where a group of Vikings are constantly singing about Spam (The canned meat product) very loudly, and drowning out the person speaking.

The earliest uses of the term "spam" online was the same as the word "flood", which meant repeating something in order to drown out everyone else, just like in the original sketch.

Today, possible uses of spam include:

  • Flooding
  • Advertising
  • Inserting gibberish
  • Cross-posting the same message in multiple places

Most people's definition of the word is vague, so the only thing you can "rely" on is that "spam" means something unwanted.

On a page-by-page basis, you can add __NOWYSIWYG__ to the page source, which will force source mode for that page.

I mostly use it for pages with advanced tables which get messed up by the RTE.

This has been happening since the editor upgrade, and Wikia Staff are aware of this problem, but currently haven't narrowed down the cause, so make sure you report it to them via Special:Contact so they can investigate it further.

Redlinked usernames will now link to the user's empty profile page rather than an edit window for that user's profile page.


Special:WantedPages is showing links to Message Wall and Archived Talk pages

They say the first step is admitting you have a problem. ;)

As seen on and several other wikis, it is possible, and allowed, to add links to the On The Wiki tab (using javascript).

In addition to pages with less height, when the green "page has been deleted." box is on the screen, the content area is moved down so additional background area is exposed.

Which is why fixed width website layouts have always sucked.

And from a Staff member, please, not from yourself.

You asked in public, so I, a member of the public, answered.

If you want staff to answer, contact staff using Special:Contact instead of asking in public.

My point is that the supplied template does not take that space into account.

That adage has been proven true, as the problem has now been fixed - thanks!

Is there any word on when this new forum will be available?

At the time of the announcement, I was considering overhauling the existing forums on the wiki I use, but decided against it because I assumed the new forum style would be available shortly.

Probably, this update.

My personal creed with block durations is: block them for only as long as they have been a problem.

So I quite literally only block potential troublemakers for 1 second if they've only made one blockable edit, so that they are entered into the block log for future reference. If they make another blockable edit on the same day, I block for an hour. If they may a blockable edit the next day, I block them for a day, if they make a blockable edit again after a day block, I give them a week block, and so on.

(All of this assumes that a some form block is needed, and that warning and discussion avenues have not helped)

I see a lot of power-tripping admins giving out "1 year" or "infinite" blocks, but there's really no point in having a bunch of active extended blocks for people who weren't going to return anyway.

I have pretty much the same outlook on "protected pages".

A more precise background template. Background template.png

Not in my experience. If they return, they get a longer ban, and usually don't come back a third time.

On the wiki I frequent, there have only been 2 vandals who have returned after a 6 month block, while almost all of the vandals who receive a 1 second "warning" block for gibberish or blanking never make a second edit. I assume they're all just children who have discovered for the first time that they can "edit" a wiki "anonymously"

I'm sure that larger wikis probably do have a higher number of each type of vandal, and have a greater number of returning vandals, so if I were an admin on one of them I'd probably start with a 1 week block instead of a 1 day block. (edit: If I found that there were too many returning vandals after a 1 day block.)

Too bad there isn't some kind of vandalism analysis tool to automatically make a report about returning vandals.

What's a "bad" image?

Ah, ok. I agree, wikis shouldn't have too many offtopic images.

Nice, although it'd be nicer if we could use it.

I hear that an updated Special:WikiStats is coming soon enough to make it not worth fixing the namespace section, so perhaps at least one form of visualisation will be included.

I agree, but I think the exact wording of the "Hi there! I’ve been following some of your edits and you’ve done a really good job so far,..." example sounds patronising (edit: I see below that it was meant as an general example, so this paragraph is largely redundant), and if someone said it to me I would feel they were treating me like a child. I try to treat others as I would have them treat me, and try to be polite while not patronising. (Reminds me of the tale of how Walmart failed in Germany because they don't like door greeters).

I agree that an admin is just a user with access to more tools, and when I've had to write policy/guides I've tried to make a point of indicating that everything is open to further discussion and changes.

There's definitely a fine line between an admin making corrections to be in-line with written guidelines and it seeming like the admin is trying to control everything. As an admin, I also try to communicate the fact that I'm just another user by proposing things for deletion and request feedback just like everyone else, rather than just deleting things immediately.

I've had some bad experiences with overbearing admins who don't seem to care about seeming like bullies. Recently I saw an admin block someone just because they created another wiki on the same subject. When I was a new user, I made a complaint about a tyrannical (as per definition: Marked by unjust severity or arbitrary behaviour) admin, and I got the standard response of "feel free to make your own wiki if you don't like it".

While these "Tips for being a great admin" are great for people who care about being a good admin, some admins simply don't care. Since these types of admins make new users seem unwelcome, I think there should be more Staff oversight on admins who act outside of the policies of their own wikis. Or a Volunteer Tyrant Task Force.

Thanks to the standard behaviour on most forums, the titles "admin" and "moderator" have become synonymous with "people who you do not disagree with or you will be banned", so perhaps the title "admin" should be changed to "Helper" or "Janitor", just to take the implication of importance away from the position.

edit: In a discussion with another user about something that he had done in good faith that I was trying to let him know what I'd changed it (I don't remember the specifics), he said to me "ban me if you like, I don't care", even though what he had done wasn't even considered an offense, let alone a blockable one. That user clearly had the impression that if you do anything that an admin disagrees with, they can just block you.

I always check the history of the requester to see if they've been an admin and/or abused their powers in the past.

Good advice!

People offering differing opinions often leads me to think in ways I hadn't considered, so yes-men really aren't helpful. Luckily, the other active admin knows this and often offers alternate ideas.

I want to be able to take part in a discussion without people thinking "oh, that's an admin, so that must be the final word on the matter". I've never said "because I say so" in a discussion, I always explain the reason why something is done, so I don't know if people actually think I'm "laying down the law".

This is one of the reasons I wish I could turn in my admin rights, but I do admin-things often enough that it would be a burden on the other admin if I was constantly asking him to do things I couldn't.

Harry granger, I brought up several different issues in my comment, I'm sorry I didn't separate them better. In that paragraph I was referring to changing other's perceptions of what a user with "admin" rights is, not changing to behaviour of power-tripping admins - of which I have no solution other than to empower the community so that they can stand up to them.

Although, now that you bring it up, letting the community know that users with admin rights are nothing more than janitors in practice may make it easier to overthrow any tyrannical mop-wielders. (Not that there's nothing wrong with actual janitors, they play a crucial role in the world, as do wikia admins, but neither of them are irreplaceable is my point)

Brandon Rhea - nothing specific, no outstanding examples, but in general I try to use edit summaries to explain that I'm not just doing something on a whim, and I start a lot of talk page discussions asking for feedback on changes I've made and proposals - I hope that both of those things help get across the general idea that although the word "admin" is in my user header, I'm not a maverick and I'm openly seeking input into my edits.

edit: Also transparency in general. I've never said "We're doing it this way because I say so", if I ever think there's a better way to do something, I'll post the full pros and cons of the issue and ask for feedback.

I strongly disagree, and think that all discussions about a wiki should happen in public.

  • It is not acting in good faith to talk about someone behind their back.
  • It is not in the spirit of a wiki to have some things not open to everyone.

If it wouldn't be right to publicly discuss something, then perhaps it isn't right to have the discussion at all.

(That said, I have had semi-important discussions with fellow admins in the chat simply because it was faster that way, but a summary and conclusion on the discussion was posted publicly afterwards rather than stating "the admins have privately decided...")


The default text for MediaWiki:User-identity-box-group-sysop is "Admin" and MediaWiki:group-sysop-member is "administrator". While sysop is indeed the technical term for the user group, that does not mean the term "Admin" is incorrect.

"no need to think up other names like janitor or helper." The idea behind saying that "perhaps the title should be changed" was to suggest a way to take away all possible preconceptions about the position that new users might have that may make them act differently towards "admins". The term "system operator" is no better than "administrator" in this regard, as it would still sound like a "big scary position of power" to a new user who hasn't been told that all users are equal. (Especially if they have had any experience with wikipedia bullies)

The term "helper" is more "friendly" and describes what an admin should be, and "janitor" much better describes the actual function of the role. Both of these suggestions take away any connotation of "authority" or "leadership". Perhaps a middle ground between the two would be the word "maintenance", which still doesn't imply power, but communicates the function of the role sufficiently.

edit: I don't think I've ever seen it changed on any wikis to be "less scary", the only time I've ever seen it changed is to be some in-universe term for a position of power. Does anyone have any examples of the title being changed to be more friendly?


Unfortunately, my google search hasn't found any other good examples, but quite a few bad ones, such as "Ruler" and "Sheriff". It's hard to "downplay the idea that admins are rulers" when that's what some literally call themselves.

Good to know the category duplicate bug was finally figured out!

I think what Kuopiofi means is: if a single apostrophe is inserted in the RTE, it appears as &apos; when switching over to source mode.

(I just tested this, and it's true)

KidProdigy, does the problem with normal words appearing as links just happen on wikia, or is it happening on other sites as well?

(I ask because some types of malware may do this)

It would appear that it's not just within the editor, I've now noticed that pages are being saved with &apos; in place of apostrophes.

As you saw after submitting your post, the things you typed didn't appear. An admin has edited your post with a &amp; in place of a & so that your post appears as you intended it.

&apos; is the HTML entity for ' (an apostrophe, or single quote)

&nbsp; means NonBreakingSPace and is a special space character which will not cause a linebreak.

For example, this previous sentence with nonbreaking spaces would be: &nbsp; means NonBreakingSPace and is a special space character which will not cause a linebreak (As you can see, because there were no line breaks, the sentence has continued outside of this comment box)

There has obviously been a change in the RTE which encodes special characters as html entities - which is a great idea, I've recently been converting all non-latin characters to HTML entities myself - but apparently the code is also converting apostrophes and spaces in certain cases.

edit: Hilariously, editing comments containing HTML entities here causes those entities to be translated into characters, breaking the examples.

More information:

"No, no, no and no" is not a helpful comment.

If there are four things in my comment which are incorrect, please specify exactly what they are so I can correct them.

Each of the pages I linked contain a list of working entity references. If there is something incorrect on the pages I have linked, please specify exactly what it is.

I've seen one nbsp pop up, it was immediately before a link. (I've reported the diff to support)

And a & was also converted to &amp;

I've also noticed that existing duplicate categories are being removed when those pages are edited, hooray.

An opinion on video:

The problem with video- and image-heavy wikis is that while a picture is worth 1000 words, the content in videos and images is not searchable, and people who add videos and images rarely take the time to add the same 1000 words to the article.

Images and videos are great sources for information, and great things to have available to refer to examples, but they do not make a wiki.

Thanks Kangaroopower, I had also thought that that preference was to opt out of achievements.

Additional feature request: Add an option to the preferences to fully opt-out of achievements rather than just hiding them.

Oh :(

I hope you reported it via Special:Contact :)


Changes to the Landing Page defaults and preferences = Awesome.

Possibly related to the known section heading bug - I've sometimes noticed that when there are two identically named headings, after submitting a section edit for the second heading, the anchor link points to the first heading instead of the second. ...I'll submit a bug report with an example.

"and I don't see what you'd stick in the URL to make it link to the second header if you have identically named headers. "

Try it and you'll see exactly what Wikia already sticks in the URL. The TOC links to each section heading just fine - the second header anchor has a _2 suffix, but that suffix is not added to the url after editing.

edit: Community_Central:Sandbox#Heading_2.

edit: and I see you've highlighted yet another problem, one that is already affecting the wiki I use, as well as potentially all other wikis for video games which have numbered sequels.


These Links that link to the same base page but different headers are both rendering correctly and working properly.

I cannot replicate the problem as described.

Thanks to Admin_Forum:Weird_effect_with_the_if_parser_function, I've reproduced the problem.

The problem only occurs when links have identical link text.

(I tested, and using different base pages with identical link text does not trigger the bug.)

edit: and as we discovered through CzechOut's problem, this also occurs if the first link doesn't use a section heading at all. Meaning these two links with also be the same:

  • this - (Help:User_page)
  • this - (Help:User_page#More Help)

edit: Another example, showing that first letter capitalisation doesn't matter.

  • this - (help:editing)
  • this - (Help:Editing#Next Steps)

The basepage+linktext section link problem is messing up references.[1]

Because all "back to section" links next to references use the link text ↑ and link to the same page, they all point to the first reference on the page. [2]

  1. name=name1, ↑ is #cite_ref-name1_0-0
  2. name=name2, ↑ should be #cite_ref-name2_0-0, but is #cite_ref-name1_0-0

Special:Contact is to communicate with wikia staff, which are a higher level of authority than local admins.

When reporting the issue to wikia staff, make sure you link to the original artwork where the copyright notice is clearly displayed so they can verify your claims.

The more information you give them, the easier you will make it for them to verify, and you will get the best results faster.

Not fixed this week. :'(

Sweet, looking forward to trying it out.

I like that there is a "move this thread" option, hopefully this will be backported into the Message Wall, or better yet that the Forum, Message Wall, and Blog Comments will be unified.

However, there doesn't appear to be any facility to move old forums topics into the new forum.

As I've said in the past, I believe it is amateurish when forums on the internet switch from phpbb to invision and lock all old topics instead of making the effort to convert them to the new system.

Wikia is at least keeping the old forums rather than deleting them, and is maintaining old links to forums topics directly, but it would still be better if it were possible for local wiki admins to move the topics manually into the new forum system if they choose to do so. (I've already tested doing it via import, and it isn't possible)

edit: strange, half of my comment was missing

Yeah, I understand the difficulties and realise it's virtually impossible to do it automatically.

Even just moving the old page verbatim and allow new-style comments to the old page would be better than not being able to reply at all - the old content would still be locked, but at least it would be visible and accessible through the new forum system, and new comments could be left.

Manually, my only option currently would be to post each comment myself and include the original signatures on each - time consuming, but would be less so if import were possible, using a bot would probably work as well.

Assuming that sigs were used, a bot could be used to determine where each comment ended in that way, rather than basing it on revisions. Of course, with varying sigs, particularly sigs which don't link to a userpage, it would be easy for a bot to merge two comments.
Even more likely than nonstandard sig is nonstandard indenting, so I wouldn't even attempt to use them as a delimiter when parsing.

Possible new methods to do that would include:

  • Local admins having the ability to define a username for a thread, this could be open to abuse - but you can still have the history show the actual thread creator, rather than the displayed username - I think this is something that may be possible, as User:Wikia does exactly the same thing with welcome messages - the Wall message says I posted it, but the history says User:Wikia created it.
  • A slightly less time consuming way to do it manually would rely on importing manually defined threads - but there's a problem there as I'm fairly certain that the "thread/parent" relationship is completely inaccessible, although I haven't yet examined exactly how the "move thread" function functions.

Personally, I'd prefer the option of importing and exporting entire threads, so that importing manually defined threads would be possible. (The history would still record that the importer imported the thread) But I don't really expect that to become available, since if it was, it probably wouldn't be used by very many people, as it would be time consuming and complicated for most.

I hope you find these suggestions useful, even if you don't use them.

You might want to enable enhanced recent changed (grouped recent changes) and take a look at how all the messages look.

Delete forum, create forum, move forum, create thread and edit thread are not displaying properly. Create thread is displaying a message wall related message.

While we're at it, grouped changes for Message Wall messages are still expanded by default, and it looks like new Forum messages are too.


Good idea, but perhaps a name change from "Topics" to "Related Pages", so it's more obvious what the purpose is?  At first I assumed it was a "tag" kind of thing, so I think it's likely that other people may try to use it that way as well.  (There is also no feedback after entering an invalid "topic", which doesn't help the confusion.)

Having autocomplete for that field works in theory, although the first time I tried to use it I typed "test help topic" so fast that it didn't pop up with any "T..." article suggestions.

I'm not sure if I like the addition of the "Start a Discussion" section at the bottom of pages - is this another attempt to replace talk pages? It's a good idea in theory as it would allow the "articles comments" - which I don't have enabled - to be merged into forums. Although the fact that talk pages are still enabled may cause confusion about where people are supposed to talk about pages.

I would definitely appreciate the integration, although I'd have the same concern about locking unfinished discussions without a convenient way to manually re-create them as threads.

In my previous comment, I mentioned: "Manually, my only option currently would be to post each comment myself and include the original signatures on each "

I realise upon re-reading that I was unclear in using the word "would", I should have used the word "will", as in "I will be moving old forum posts into the new forum system manually, and currently my only option is to post each comment myself."

Any one of my suggestions would make this less time consuming, or at least less messy.

I also had the same question, due to having the same local policy, and was told that I was not permitted to hide the remove link, due to the fact that "it was possible the old way".

As CzechOut mentioned, the problem is that the old method didn't explicitly have a link inviting users to remove their comment.  While I've not had the misfortune of having to argue with a user about it yet, I fully expect their response to be "If I'm not allowed to remove my comment, why is the link there in the first place?" - that's exactly what I would say if I was in their position. I think it's ridiculous that we are supposed to enforce a policy of "never use that link" instead of simply being allowed to hide the link.

That said, Toughpigs' response was far better than TomekO's.

I fully agree that threads should keep the "wiki spirit".  If threads are supposed to have the "wiki spirit", they should be normal wiki "pages" which can be moved to any location, and imported/exported just like any other page on the wiki, instead of pseudo pages which do not respond to ?action=edit.

Until just now, I hadn't realised before that non-admins could remove any post - I assumed that they could only delete their own posts, and that thread authors could delete any comment to their post - isn't that how blog comments work?  Wait, no, I can't remove my own blog comments.  So the question is: Why is it impossible for a user to delete their own blog comments, but it's possible for them to delete any forum comment? That makes no sense at all, ordinary users don't have rights to "delete" (or hide) normal wiki pages, they only have rights to edit them and wipe them. Therefore, it is not in the "wiki spirit" to allow users to "delete" their own forum posts - it is only in the "wiki spirit" to allow wiping them.

Surely moving the old articles comments into the new forum system would be a lot more useful - and more technically possible - than just locking them?

I'm sorry that I didn't go into as much detail as Randomtime did.

Hopefully that forum merge function can be used to merge message walls also.

edit: by the way, the normal "undelete" link is still appearing as part of the "Board:Test1" has been deleted. (undelete)" message, even though it doesn't work.

If you replace "page" with "wiki", then yes.

It occurs to me that I hadn't attempted to actually move a page manually into the board_thread namespace - and I've just discovered that it indeed is not possible.

I created test thread, then attempted to move a page to that name, and it failed the first time due to the name changing in the move box between submissions, but when fixing that name every time - it worked, or at least it tried to work.

The page was moved, to a page with the same name, in the main namespace.

So, the board thread url was: wiki/Board_Thread:test/@comment-452-20121203183957 So I moved it to wiki/Board_Thread:test/@comment-452-20121203183957 - but it didn't move it into the forum, it moved it to a page named "Board_Thread:test/@comment-452-20121203183957" in the main namespace.

These two diff views showed the diff for each separate page, while just ?action=history only showed one of them: wiki/Board_Thread:test/@comment-452-20121203183957?diff=next&oldid=103868 wiki/Board_Thread:test/@comment-452-20121203183957?diff=prev&oldid=103869

Additionally, while viewing old revisions for any forum post, the edit button will be shown at the top of the page. If the edit button is pressed, it is possible to edit the page, and submit the changes. On the most recent revision, the "add topic" button will be shown instead. Using the button will cause a page to be created in the main namespace.

It seems to me that all of these situations should have been tested during development.

I'm 99% sure the response from staff will be an explanation that it is no different than there being a link to the talk page at the top of the disambiguation page. If you're lucky, you might even get a response phrased as a snarky question, like "Could you explain how your wiki solve this problem in case of Talk pages?"

That is, if you're lucky enough to get a response at all.

I agree that there should be a way to suppress it on certain pages if necessary, and that this would be much better in the siderail.

As per the update in the blog post, they're not allowed to disable the forum section using css.

Please have some patience. I've been waiting several days for feedback to my comments, while you waited exactly 6 minutes before posting this follow-up comment.

Agreed, and you make an excellent argument against it.

I think there is merit in having the option for the new forums to entirely replace talk pages, but as it is, having them both enabled but forcing the message to appear the bottom of the article will cause confusion.

In your Email Preferences, there is the option: "Email me when page I'm following is changed", but that will disable all following emails, there doesn't appear to be a way to do it only for threads.

You've highlighted an interesting point that should probably be addressed: better email preferences.

There is a new section for Message Walls, so hopefully there will be a new section for forum threads as well.

Admins can enable it on Special:WikiFeatures

So, assuming you mean shipsandthings, take a look at:

Redirecting to threads is not working - both via "Thread:..." links, and via "Board_Thread.../@comment..." links. (The latter because "Board_Thread.../@comment..." links don't work at all.)

Are you sure?  You have a user profile page.

I believe this is probably by design: the new forum link is automatically added to the on the wiki tab - so if there is a forum-url link in another menu, there would be two links to the same page. I think they've probably left it up to local wikis admins to decide what to do with the old link.

Until now, I had no idea that anyone could remove anyone's message wall posts.  The only time I had ever seen it happen was thread authors removing sub-comments, so I assumed that that power was limited to them.

If my main concern was "vandals will delete everything!" then I'd be placated.

As I said on the second page, my main concern is I want normal wiki functions available for all features : I still can't move Message Walls threads from one wall to another, nor move a post in a thread to a different thread.  (I can also not move a forum post into another thread, in order to merge threads about the same question. "Link and Lock" is sloppy moderating which creates needless noise.)

Being able to perform maintenance tasks like that was something I could do that with old forums and talk pages, and are therefore in the wiki spirit.  I can't even move something from another namespace into the board_thread namespace.  So if a user mistakenly creates a main namespace thread asking a question, I cannot move it to the forum - as I could with the old forum, so I would be better off creating my own user_blog based forum alternative. (Which I was thinking about doing around the time of the forum announcement and I've been putting it off because I assumed the new forums would meet the same needs)

Importing and exporting are also things I could do and are also therefore in the wiki spirit. (Admittedly, I've tried importing/exporting user_blogs, but since I can move things to/from the user_blog namespace, I assume it's possible.)

déjà vu:

Poppycock - I responded to your first followup, and I told you to have some patience.  It's only been 20 hours since then.  I know that sometimes issues don't get dealt with for months, but less than one day is hardly a good time for a reminder.

By the way, don't post a new comment if you're replying to someone.

Additionally, all posts or edits in the same forum are appearing in the same group.

This is actually a blessing since they're expanded by default - so please do NOT fix this until they're collapsed by default, or it will clutter RecentChanges even worse.

The Editor had reverted to using an old monospace font for source mode.

Damn, I thought that was a feature. :(

Hooray for that "links on the a page which point to different sections of a page while using the same linktext all point to the first section" problem being fixed though.

I've just made and removed a test post on tardis and checked the box, so you can see if anything happens.

Cool, I already reported the fact that those type of links didn't work - but the only way I knew to get to those links through the interface was through recentchanges - devs will be happy/annoyed to know there's another way to get to them.

IMO those links should be made to work correctly, as they work correctly for user blog comments which are formatted the same. (As demonstrated by this link)

Rappy, you said that the "problem of after-edit URL anchors pointing to the wrong heading" was the same issue as the "links on the a page which point to different sections of a page while using the same linktext all point to the first section" problem.

Since the "links on the a page which point to different sections of a page while using the same linktext all point to the first section" problem has now been fixed, why does the "after-edit URL anchor" problem still occur?

Demonstrated here: Community_Central:Sandbox

  • After editing section 1.2, the anchor in the url points to section 1.1 - the anchors for these headings are not the same (Heading and Heading_2), and the TOC leads to each of those headings fine.
  • Unrelated to that problem, but also occuring: the anchors for sections 2.1.2 and 2.2.1 are identical. (The TOC also jumps to the wrong heading.)

You bring up a good point, Spencerz - protection options should be available, analogous to the protection options available to admins on other areas of the wiki.

I don't think CzechOut is trying to "calculate" the success rate, as far as I can tell, it's mostly about calculating the accuracy of the text of the related discussions module (and usefulness of the "related discussions" module as a whole, based on this accuracy).

At the very least, if the text is inaccurate, then the text should be changed.

  • I agree that closed discussions shouldn't appear in the module.
  • I agree that it is the normal state of an article to not be under discussion, because discussion is the symptom of an article which has problems.
  • I agree with the overall point that the "related discussions" module should be optional. (Per the policy of each wiki)

Well said, Noemon.

The more issues come to light, the more I think that a better solution to "fix" the old forums would have been to just enable Article Comments for the Forum namespace, rather than re-inventing the wheel as an oval. (It works, but it's not a gentle ride.)

Every new wikia feature seems to depart further and further from normal wiki pages, meaning more and more normal features aren't available, and more and more bugs appear when trying to glue things together (Moving pages across namespaces? redirects? importing? grouped recent changes? links in diff logs?)

Since all comments seem to be implemented as pseudo subpages anyway, I don't see why they weren't implemented as actual subpages, and transcluded in-line.

end of url for a comment to this blog post:

  • @comment-Vandraedha-20121204074520

end of url for a reply to that comment:

  • @comment-Vandraedha-20121204074520/@comment-452-20121204153244

Appending ?action=edit to those urls does nothing, and neither do the usual range of "action="s. Export works, Import doesn't.

If the features were implemented as normal wiki pages, then all normal actions would be possible, including move: which is not available for any comments.

and moving a misplaced reply would be as easy as renaming:

  • this: /comment-Vandraedha-20121204074520/comment-452-20121204153244
  • to: /comment-SapphireOfNeptune-20121204091607/comment-452-20121204153244

Or, in the case of replies made out-of-thread:

  • this: @comment-Kerry_Stapleton-20121205073227
  • to: @comment-Kerry_Stapleton-20121204155753/@comment-Kerry_Stapleton-20121205073227

The one "new" feature that would possibly need to be implemented would be a new "creator and sysop only" permission.

  • It's not necessary, but this is the current permission on editing blog, message wall and new forum messages. (So don't give me the old "not in the wiki spirit" excuse.)

I think I'll implement this in DPL and use it instead of the new forums. (edit: working well so far, having trouble with recursively loading replies to comments - a limitation of DPL, apparently. But since the new forum only allows a single level of comments anyway, it's no big deal!)

edit: I'm also implementing a DPL-based "Related Discussions" module - because I like the idea, but don't like it appearing everywhere automatically.

The problem of red links from deleted message wall messages appearing on Special:WantedPages, (reported in support ticket 32529 on the 27th of April), is also an issue with both removed and deleted forum comments and replies to comments.

If everyone can remove any message "to allow easy vandalism cleanup", shouldn't red links in removed messages be suppressed from appearing on Special:WantedPages?

In light of BertH's response, can you confirm that you received a notification when I removed this test comment, CzechOut?

Be active pretty much sums it up, and is basically what I tell anyone who asks.

I give rollback rights to anyone undoing vandalism, and I'll give admin rights to anyone who needs access to admin tools, but there are always people with 0 edits asking how to become an admin, and I always just think "Why?" Those people rarely stick around, but I do wonder if they would have stuck around if they had been given admin rights.

I also had no intention of becoming an admin, although it's been unforeseeably useful to have access to admin tools. I became an admin because I was constantly messaging the inactive admin about admin tasks which needed attention, so another user proposed that I be given admin rights.
I've appointed another new admin since becoming a bureaucrat, and would de-admin myself if it wasn't for the fact that I'd still be constantly messaging the other admin to do random things.

I don't know how to be a great admin, but I try to be active and do whatever I can to benefit everyone.

Hooray for Top 10 List descriptions being fixed!

That "Photos" link is really misnamed. It links to Special:NewFiles - which shows pdf files, ogg files, and all other files which are not image files.  Most images tend to be screenshots anyway, although every now and then I do see someone upload a photo of their television.

Oh yeah, I'd forgotten about those, thanks.

At least those can be fixed with MediaWiki:Uncategorizedimages, MediaWiki:Unusedimages, MediaWiki:Wikianewfiles-title, MediaWiki:Wantedfiles, etc.

The On The Wiki tab doesn't use MW messages - that's the problem.

Things in the File: namespace are files which have been uploaded, whereas pages work different than files.

Fixed: Rollbacking an edit was giving an error at times when a Rollback was performed

Months, actually.

Awesome, thanks!

The easiest solution would be for the server to pass a "currentServerTimestamp" variable for the js to use instead of using your computer's time. (This is what I've always done.)

I don't think the "posted ago" text is dynamic, let's test.

(several minutes pass)

I've been staring at "7 minutes ago" on the above comment for a few minutes now - since it's not dynamic, there seems to be no reason for the script to use the current computer time as opposed to the time at time of serving.

Definitely not negative! While at first I was apprehensive about giving a tool for possible edit-wars, no-one has abused having rollback rights; although it unfortunately hasn't resulted in any long-term contributors. Over the past year, I've given rollback to around a dozen users who've undone random vandalism, but not a single one is still active. :(

There are quite a few long-term editors who are active, but while those users are productive editors, I haven't seen a need to give them either rollback or admin rights. There's much less vandalism these days, so less of a chance for people to undo vandalism - but if any user requested admin rights in order to - I don't know, fix links in locked forum/talk pages or something - I'd give them admin rights.

I suppose I could "assume good faith" from everyone who requests admin rights and give it to them, but it seems like too much of a risk, if they're completely unknown users.

Those are all really good points, and the type of things I've always tried to do.

The one thing I'd change about that list is the "ask an admin" part. I'd definitely say "start a discussion", but admins are not the rulers of a wiki, the community is, so posting a proposal on a talk page is all that is necessary if you wish to discuss a major change. Seeking the opinion of an experienced admin is one thing, but asking "permission" is another.

In addition to the "be nice" points, I'd also add:

  • "always use edit summaries to explain your edits"
    • Edit summaries, particularly when editing something that someone else has just added, helps explain why you're "correcting" their addition, so they don't take it the wrong way.
  • "Always be neutral and factual in those edit summaries"
    • While a pun or wordplay may be acceptable, users who leave sarcastic, snarky or passive aggressive edit summaries really shouldn't be admins, as it shows they don't respect other users.

The removed posts appears when you view the post directly:  a direct link to that URL can be found in several ways: RecentChanges and UserContributions being the easiest.

  1. You can't.
  2. You can create one, there is no need for a default one.
  3. No, you cannot, that is why there is a confirmation screen.
  4. That's an interesting bug, nice find!
  5. Yes, don't click "quote".


You just replied to me without quoting me: do the same thing in the forum.

Definitely, which reminds me of something I've always done, both before and after becoming an admin: trying to have discussions about non-minor changes rather than just being maverick.

Particularly with merges, splits and deletes, but also with major overhauls, I often leave talk page messages discussing my ideas for the page and asking for feedback. (We also have an index of active talk page discussions, for easy reference)

So I think another good tip for becoming an admin is to engage other users in discussions about improvements.

There doesn't have to be a committee and a vote about every little thing, but other people will always have a different viewpoint, so discussions are always helpful, and starting discussions also communicates that admins aren't rulers.

This also reminds me of a discussion I had recently with an admin from another wiki: I had left a message on a talk page, but because I hadn't contacted an admin directly, they said I hadn't "contacted the wiki". As far as I'm concerned, admins should be monitoring all talk pages via RecentChanges anyway.

I got the idea from the Muppet wiki: (Other wikis have the same thing, but the Muppet wiki's page was created in 2005 by User:Toughpigs, and so appears to predate all others, who must have plagiarised the page from the muppet wiki without attribution.)

The easiest way to do it is to add a template to talk pages individually, and have that template add the talk pages to a category, such as Category:Active Talk Pages

A more advanced way is to use DPL, and there are two different ways that could be done:

  • Using a template with a "topic" parameter, and DPL is used to list all template usages, with the topic listed
  • No template, just a DPL list of recently edited talk pages.

I use both DPL methods, so no talk pages are accidentally forgotten if the template isn't used.

The Muppet wiki has a <forum> list on the page I linked, but they don't have a topic parameter.

I think you just answered your own question.

Tab ordering when on an edit page should make more sense now. Tabbing from the editor moves to the summary field then minor edit button then preview and publish.

Excellent! I was beginning to think that the tab index was never going to be fixed.
What is the current record for the longest time a bug has been known before it was fixed? I guess I should go back and look at the list of bugs I reported about the new editor and see what's left.

These sort of changes only affect the default text, the MediaWiki page on your wiki will still be used instead.

it's always OK to say "I don't want to share that", or "I prefer to use my nickname, not my legal name".

Try telling that to facebook.

My golden rules:

  1. Assume any information you give will be used against you
  2. Don't do or say anything you can't explain to your grandmother

Unfortunately, due to the fact that Wikia loads on every pageview, Facebook knows all about my activity on Wikia, and is free to do whatever they like with that information, including telling my grandmother. Or at least they would, if I didn't use adblock to block everything from and other third-party usage trackers.

The bottom line: Be aware that you cannot trust Wikia to protect your privacy. Only you can act well to ensure that they're not passing your activities on to others.

"Direct links to blog comments will now visibly indicate which comment you were linked."

Cool, this is already working - also, lazy loading is not preventing scrolling down to the linked comment. (Not sure when that was fixed)

Facebook still associates it with your account, because they have you IP and cookie when you log in there, and they have your IP and cookie when the image loads here. Unless you block with either an adblocker or a firewall, facebook still sees every wikia page you view, and unless you clear your cookies and use a different internet connection, they associate it with your account (behind the scenes, obviously).

Basically, if you look at a lot of wikis about penguins when you're logged out of facebook, you're still going to see ads about penguins when you log in to facebook - most people won't really notice, because if they're looking at penguins on wikia, they've probably already added "penguins" to their interests on facebook.

Do you mean MediaWiki:Forum-specialpage-blurb?

The way to find this kind of this is :

If you mean the line at the top of each individual forum, I believe that's in the forum management area.

(I'm sorry it took 2 days for someone to answer you, I don't work for Wikia, and I don't know why their paid support staff are not more helpful with answering questions on Community Central.)

How old is the oldest bug in the bug tracker?

When you have a backlog blitz, do you start from the beginning and work forward, or do you still work on them according to priority?

There's a side issue of the current bug tracking system where you can't retrieve passwords to track tickets either.

I assume you're talking about logging into zendesk to look at support tickets.

You can, but it requires a change of email address.

  1. Go to and sign up - you cannot sign up with an address you have already used to submit a ticket. Take care choosing a "real name", you cannot change this later, and wikia staff cannot change it for you.
  2. You will receive an email with a confirmation link, and can then set a password - don't forget it, as you noted, it's impossible to reset it. I've forgotten mine a few times, luckily I found it again after trying a bunch of passwords.
  3. Change your email address on wikia - this way when you use Special:Contact, it will associate the ticket will your new zendesk account. Alternately, you can log out before using Special:Contact and specify the zendesk email, or simply submit a bug directly through (Tickets submitted through special:contact include info such as username, wiki, user agent and some wikia variables, tickets submitted directly through zendesk do not - if you're submitting a bug which may be related to your browser, that information is helpful, although Wikia Staff have been known to ask for that information even when it's automatically attached to the support ticket, so it may not matter either way.)

I submit a lot of bug reports, so it's immensely helpful to be able to log in and few all of the tickets and replies in order rather than searching through emails.

In the editor, the right rail category module from visual mode is now used in source mode as well.

Thanks for fixing this!

(I'm trying to be optimistic about having this functionality restored after so long, but I guess if the pizza guy forgets your breadsticks then takes a year to return with them, you should still be thankful you got them at all.)

Will the chat log be posted afterward?

PedroM, you apparently joined in April 2012 - after the new editor was introduced, so you're missing some information.

The previous editor had the category module enabled when the RTE was disabled (with the option to disable it, obviously). They removed this functionality when the new editor was introduced, and it has taken them a over year to restore it. (Although I re-enabled it with javascript a while ago anyway - showing that there was never an issue, it was just arbitrarily disabled.)

Today's change has simply restored how it used to be. Therefore there must have been something that needed fixing.

(Note: I'm uncertain about the exact length of time, trying to look it up now, but it has been over a year since the new editor became available. Edit: multiple people were complaining about it being removed in September 2011 - here's my comment)

Yeah, there appears to be some sort of ugly un-styled video related thing at the bottom of articles. :(

I just took a look at a bunch of random articles, and have found that the "related" videos are never, ever related to any article.

It would appear that it is not yet enabled on all wikis.

Hmm, that's interesting. I'm seeing it differently on some wikis. I've contacted staff and asked them to disable it for the second time.

Since it has now been that way for over a year, it definitely is confusing to new users, so I think there should now be an option introduced to allow it to be used either way.

Allegedly yes, although I'm not aware of the log of the previous chat being posted anywhere.


We could just do most of this ourselves. I've already started a list of my own reported bugs, with "fixed or not" statuses, for my own reference, as I keep forgetting to check back on old bugs.

If you want to start a page here (or a wiki like wikiabugs.wikia) for that purpose, I'd be happy to contribute my past reports to help jump-start the effort.

We still wouldn't know the internal status of the bugs, but we could track when they were reported and if and when they were fixed.

Would a list of articles with time it took to generate them help you?


I use google chrome and upload images without a problem.

What version of Microsoft are you using?

I don't know how to find out what version of Google I'm suing, but I'm using the latest version of Chrome (Version 24.0.1312.57 m), and last uploaded images around 19 hours ago.

Dear wikia, I was in the middle of typing a fairly long comment regarding my recent experiences with ads on wikia, and this page just refreshed and lost my comment for no reason.

Thanks for that.

I'll keep this comment short in case the page randomly refreshes again.

Wikia should give Bereisgreat more ads: allow people to opt-in to receive more.

I recently saw an ad that I wanted to see again, and even though I refreshed the page for an hour, it didn't display again: What's the point in having ads if I can't even find the one I actually want to see?

so if you're an Opera user for example, please do still tell us about any bugs you see, especially if they're major.

I recently reported some Opera issues and was told that it wasn't a supported browser (and therefore the issues wouldn't be fixed).

I think the idea of a mobile app is so that the app can use the API to retrieve data instead of the full html version.

So a browser extension could be used to do the same thing. Reducing bandwidth for you, and reducing load time for users. (In theory, I'm not aware of any which actually do this, or if it's even possible.)

How would you know if they didn't? ;)

I assume that the source of the info is google analytics, and that that graph isn't specifying operating system, and that the "Chrome" chunk is for Chrome on all OSs, including Android, and that the "Android browser" is referring specifically to the default "Android browser".

I checked google analytics, and I listed visits by both browser and OS and can see multiple browsers listed for Android: "Android Browser", "Opera Mini", "Chrome", "Firefox", "Mozilla Compatible Agent", "NetFront", "Opera", "Opera Mini".

So I can definitely say that some versions of Chrome running on Android devices report as being Chrome running on Android, but it's possible that some of them don't.

Safari 5.1.7 for Windows:

If you contacted Wikia on the same day you gave them the rights, and informed them that they had deleted a bunch of pages that shouldn't have been deleted, it should have been obvious that the users you promoted were vandals, and should have had their rights removed.

  • Mediawiki:user-identity-box-group-chatmoderator
  • Mediawiki:user-identity-box-group-helper
  • Mediawiki:user-identity-box-group-authenticated
  • Mediawiki:user-identity-box-group-staff
  • Mediawiki:user-identity-box-group-bureaucrat
  • Mediawiki:user-identity-box-group-sysop
  • Mediawiki:user-identity-box-group-blocked
  • Mediawiki:user-identity-box-group-founder
  • Mediawiki:user-identity-box-group-adminmentor
  • Mediawiki:user-identity-box-group-council
  • Mediawiki:user-identity-box-group-vstf
  • Mediawiki:user-identity-box-group-wikiastars

I concur, the "Followed Pages only | See all activity >" links at the top of the page, shown in the screenshot on Admin_Central:Guide_to_Wiki_Activity have been replaced with "Special" page.

MediaWiki:Oasis-page-header-subtitle-special is what is currently being shown.

The normal text is stored at MediaWiki:oasis-button-wiki-activity-watchlist and MediaWiki:Oasis-page-header-subtitle-special-wikiactivity or MediaWiki:oasis-button-wiki-activity-feed. (Just the text, not the links)

I think I'll make that my new motto: "Mistakes happen, why bother testing anything?"

Mistakes happen, that's why testing is necessary.

I contacted wikia staff on your behalf, explaining how his first action as admin was to attempt to remove your rights.

This apparently convinced them, as his rights have now been removed.

In future: never give anyone bureaucrat rights. I suggest reading the help pages regarding various user levels.

Also, when contacting Wikia staff, it helps to be as detailed as possible.

Be sure to include as many links as possible, to prove what you tell them.

Yes. A bunch of images from the 12th disappeared.

But you probably already know that wikia has already fixed the bug and has not able to restore the images that were lost.

"For videos that had attribution changed to "WikiaBot" in the past, the original attributor's name has been restored in most cases."

Thank you. *crosses it off the list*

edit: Regarding "In most cases" - will you be wanting extant cases of WikiaBot attribution to be reported? (It appears that videos which were renamed since it occurred were not fixed.)

"The <videogallery> tag is deprecated and has been changed to <gallery> on all wikis."

Videos do not display in a gallery with type="slideshow"

Thanks, the uploader information is still in the page history.

Support ticket #76791 has full details.

I have received confirmation that videos which were renamed while attributed to WikiaBot were not corrected.

(edit: As all of the comments were about a single part of my multi-point comment, I'm forking the comment and reposting the rest of my original points)

A lot of people also watch porn online. Does that mean wikia is going to try to force porn as a vital part of the wikia experience?

The word you are looking for is "no", not "yes". My point is that they're not going to do that, so using sarcasm is pointless here.

Also, there are plenty of wikia wikis dedicated to non-family-friendly violent video games.

The point is that just because something is popular and makes money for some people does not mean it should be part of everyone's business model.

I never said anything about parents complaining a children using websites.

Wikia is the basis of our "business models".

What are you talking about? I don't have a "business model".

"So if they know that videos are popular among the contributors, and they know that the people who make the videos earn money, then why not use that same tactic."

Every time you use the word video, replace it with "porn": "So if they know that porn is popular among the contributors, and they know that the people who make the porn earn money, then why not use that same tactic."

Get the point yet?


A friend from Canada once warned me in the past that I should stop using examples of negative things to prove a point, because many people are completely incapable of understanding those particular type of examples. I don't know where you're from, but he and told me it was particularly a problem with people from the USA, and he didn't know why that was.

Porn is not illegal. Porn is legal, and is a huge business. Porn is the reason VHS won over betamax, Porn is the reason bluray won over hddvd. I don't know how much of the internet is dedicated to Porn, but there are certainly more Porn sites than there are Wikis.

I am well aware that Wikia is not likely to start including porn, much less force people to include it. That's my point. I deliberately picked an example of something that makes a lot of money, but that would most definitely not work as part of Wikia's business model, or most other businesses.

I guess that the example I picked was too good for its own good. I'm going to fork my comment, so that this thread is dedicated to that bad example, with a new thread for the rest of my points.

I'll rephrase:

My Little Pony is also big business. A lot of people like My Little Pony, also watch My Little Pony online. Does that mean wikia is going to try to force My Little Pony as a vital part of the wikia experience?

Most business are not going to force My Little Pony into their business model just because it makes a lot of money.

The fact that something makes a lot of money is not justification unto itself for forcing it into a business model.

Obviously, some businesses will. Costume shops will probably start stocking My Little Pony outfits. Pop culture stores all over the world probably started stocking My Little Pony paraphernalia once it became popular.

(As all of the comments to my original comment about a single part of my multi-point comment, I'm forking the comment and reposting the rest of my original points)

Yes, a lot of people watch videos online. That doesn't mean people want to watch videos on wikia.
I think it's telling that 50% of respondents haven't watched videos on wikia. Did the survey 'ask those people whether they wanted to watch videos on wikia? How many of the 50% who haven't watched videos on wikia have said they would like to?

Videos are what youtube is for. I've read a few youtube comments over the years, and they're not the sort of people I would want as wikia editors. (Although I realise that wikia is more interested in eyeballs than editors.)

The main point of wikia is that anyone can edit. Text is easy to edit, videos are not. Videos are not in-line with the spirit of a wiki because "anyone" cannot edit a video, there's no way to "edit" an embedded video. (Although I would heartily welcome a wikia video editor - most videos people add are terrible and need to be trimmed and cropped, and while it's easy for me to download an image, crop it and re-upload it, it's not as easy for me to do that with a video.)

Is there a standalone windows version of the app for those of us who don't own iproducts but wish to ensure pages will display correctly?


I know the android market share on wikia is less than the iproduct marketshare, but it's not that much less.

And a quick google search for "ios android marketshare" shows that recent news articles regarding ios v android marketshare are saying that android has now overtaken ios web-wide.

When writing links in source mode, the link suggestion dropdown should no longer be able to extend below the bottom of the browser window.

I'm hoping this means the dropdown box will now extend upwards instead, rather than being truncated.

Yes, apparently a recent update broke case insensitivity.

So searching for "wiki help" wouldn't go directly to the page named "Wiki Help".

WAM certainly looks like a great scoreboard. While I understand that this may encourage some community improvement, I personally don't see Wikia as a competition.

Is there any chance of a tool, possible related to WAM, which can be more directly used by communities in order to improve their wiki?

It just kinda feels like I've taken a test and I've been given a mark out of 100, but haven't been told which answers I've gotten wrong.
It would be handy to know if I should focus more on my subtraction skills than my division, y'know? (To put it in wiki-related terms, it would be handy to know if the "level of user activity" was good, but the "page views" were down - or something.)

As I understand it:

  • Rank is out of all wikia wikis
  • Vertical Rank is out of all related wikis (Video games / Entertainment / Lifestyle)

But is the Peak Rank out of all wikis or just the vertical?
It would be handy if the date the wiki achieved that Peak was noted - so that the Mad Men wiki can later say "This wiki was rated highest on the day of the wardrobe malfunction", or something.

Also, do you only store the peak, or do you store each day? Is there any chance of a graph?
I like graphs. I'm still waiting for updates about that graph thing that was posted a few months ago.

Did this update break welcome messages?

Welcome messages linking to Message Wall or Forum threads will now display the thread title.

Did this not happen?


I thought it would be better to check on whether this was actually implemented before reporting it, since I know some updates have been rolled back recently.

Also, since welcome messages are currently disabled, pending updates, it's entirely possible that this has something to do with that downtime and that it's about to be fixed anyway.

I completely overlooked the date box, so that one was a silly question anyway, thanks!

One thing I've noticed while looking at some of the early dates is that wikis which were once in the top 5000, but aren't today, aren't shown when searching for today's date.

So if you want to know if your wiki was ever in the top 5000, you're currently out of luck unless you want to check every date.

It would be beneficial if the search also searched the past dates automatically.

I assume (because it's the simplest implementation) that you're just generating a list of 5000 wikis, and storing that information daily, and so have around 2.5 million entries in the WAM database already, but when you search, it's only searching the 5000 entries of the specified date. (Which makes sense. However simple or complicated your database is, that last part is surely true.)

For search purposes, it might be worth adding a boolean "lastseen" field to each entry, set as "true" for the entry when that wiki was last in the top 5000, and unset when there is a more recent entry. (So, each wiki which has ever been in the top 5000 has exactly one entry in the database with "lastseen=true".)

Then you can restrict the search to "lastseen=true & before X date". That way, someone looking for could find info about the last date they were ranked, without having to hunt through every day of the previous 16 months to find it.

(I'd assume that the top 5000 is actually pretty stable, or at least the top 2000 at any rate, so the number of entries with "lastseen=true" may not be terribly high. How many wikis have ever been in the top 5000? - I'd love real stats on this, if you have them.)

edit: typos, some rewording for clarity.

As a temporary measure, I've set MediaWiki:Welcome-user to "Wikia".

The downside is that the name appearing on the message wall is "Wikia", but at least it keeps the message out of my contributions.

According to this comment, that is something they are looking to do in the future.

Along with adding WAM-releated information to the WikiStats page on each wiki.

What exactly is this issue?

I looked at Special:Contributions for everyone who has replied to this blog post, but can't seem to see a link of that format. Could you link to somewhere that the problem occurs?

I reported this problem about 24 hours ago, no reply yet.

It appears to be a problem with the notification cache. As we all know, there's 2 types of notifications, Message Wall/Forum reply notifications, which are shown in your notifications where-ever you are, and forum highlights, which are only displayed when you're looking at that wiki.

It was explained to me recently that when you visit a wiki, all new forum highlights are copied to your notification cache, but it would appear that there's a bug which is marking new forum highlights as global notifications instead of local notifications.

So when you visit a wiki and get a new forum highlight notification, you'll continue to see it when you visit a different wiki, if you haven't marked it as read.

Oh, I see.

On my contributions page, the link saying "452's wall" is instead of


Styling when editing blog comments is acting strangely. (I'll update this with a screenshot in a minute.)

edit: I was going to try to be clever and use a screenshot of this exact comment, but only one of the two problems is occurring with this one, so I'll use a screenshot of an earlier comment.

Strange gaps when editing blog comments.png

According to this comment, that is something they are looking to do in the future.

Good question - it appears the first column is just the row number.

So it appears there are several top-5000 ranked wikis we cannot see in the list.

For 2013-05-06, if you view a single Vertical, and go to the last page:

  • All - Row #4224, Rank: 4999-4224 (775 missing)
  • Gaming - Row #1803, Vrank: 1803
  • Entertainment - Row #2349, Vrank: (115 missing)
  • Lifestyle - Row #72, Vrank: 708 (636 missing)

Total missing from individual verticals: 751. So there are 24 Ranked missing wikis which don't fall into the vertical categories.

Hopefully Bert can shed some light on this.

Well, Babar Suhail, I don't think it really matters, because plenty of people use both.

But you don't have to take our word for it, here are thousands of examples:

Unless Wikia Staff actually want to press the point in order to prevent their trademark being genericised, I see no problem with people calling this "the community central wikia", or calling it "the world of warcraft wikia".

If Wikia, Inc. themselves don't care, then it doesn't really matter what is technically correct, since it's a common usage, and people know exactly what you mean when you say it. The point of language is to convey ideas, after all.

The welcome messages are now being left by Wikia and signed by whichever admin correctly again, but they're still appearing on RecentChanges.

I just tested and it is currently still broken.

Thanks Eladkse, I'm new here and am not familiar with Technical Update blog posts so I had no idea.

RansomTime didn't ask if it was going to be fixed tomorrow, he asked in the past tense, which is why I used the words "currently still broken".

Last week's technical update mentioned that some fixes are being released outside of the weekly code release, so testing it now tells me that it hasn't been.

You're right that blank thread titles are definitely a problem which should be fixed, but I wanted to let you know for future reference that does link to it. (Click the date)

Impressive list of fixes this week! I'm looking forward to trying out the new search improvements.

On the eighth, Wikia sent an email titled "Hello from Wikia", to the same people who were invited to take the survey back in (whenever it was)

The email had a whole section devoted to the file page redesign, which really helped me understand the reason behind it better than anything I ever read here.

I'm not sure why this explanation wasn't posted here someplace, or maybe it was but I missed it.

You can read it here:

I don't agree with hiding the useful information away on other tabs either, but at least now I better understand Wikia's motivation for doing it.

Well, were you invited to take the survey?

We know for a fact that not all admins were invited to take the survey, because some of them posted here stating as such, and they were told their wiki was too small.

The email states ""Back in March, we asked you, the admins of some of Wikia's largest wikis, to fill out a survey". So, if you were not invited to take the survey, but still received the email anyway, let us know.

Many things are now live, but the WAM page only goes up to 4984.

Also, will the WAM fix be retroactive?


Since the email states that it is supposed to be a follow-up for everyone who took the survey, we don't need confirmation from people who were invited to take the survey email, we only need confirmation from people were were not invited to take the survey (but received the follow-up email anyway).

I guess it would also be useful if anyone who took the survey but did not receive the follow-up would also say so.

Well spotted, I'd now like to know this too.

(I just uploaded two identical files and confirmed that there's nothing on the file page to indicate they are duplicates.)

As described in the email linked below, yes, the goal of the file page redesign is to bring more people to wikia.

The inclusion of those text snippets means that those images will get higher search result rankings, therefore more people will find the images through text searches, and hopefully click through to the images, see the ads, and Wikia will make more money. Once those users are on Wikia, the presence of the summaries is also designed to get those people to click through to the articles and stay on the wiki to view more ads.

Since Wikia is viewed by more non-editors than editors, most of Wikia's revenue undoubtedly comes from the countless viewers who never edit, meaning that it's financially prudent to consider non-editors first.

But it would be nice if logged in users had the option to view the old file page instead, since I haven't heard of a good reason to force logged in users to view that page with tabs.

Excellent, thanks.

I like that they've sent the email to (possibly) everyone - that's how it should be.

It's just a little strange that text of the email indicates that only the people who took the survey should have received it.

The reason I was asking is because while there's 16 missing today, there's 33 missing from this day last year

But I assume you mean "the problem effecting all remaining missing wikis will be resolved", and that every day have 5000 wikis listed after it's fixed. :)


I saw this happen 45 hours ago.

Damn ninjas.

The system that picks images for use in Related Pages and categories galleries will no longer skip over valid images from articles.

I've noticed in the past that the first image isn't always used - what images are considered "valid"?

edit: nevermind, apparently there's a bug.

So, if I'm an admin on a gaming wiki, Special:GameGuidesContent should be available, because the feature is turned on by default?

Ok, well I'm an admin on a gaming wiki and can't access that page, so I'll use Special:Contact.

Is there a known problem with the image cache?

Re: youtube tags being converted to file pages.

I've been recommending using youtube tags for userpage videos rather than adding unrelated videos to the wiki, but now all unrelated userpage videos are going to become file pages anyway. :(

Edit: I love how there was never a response to this and how this same thing is a problem to this day. 13:50, July 9, 2015 (UTC)

Images uploaded earlier are still not showing.

edit: More than a day later, and images with problems have still not updated. Specifically, an image uploaded at 04:12, 6 June 2013 still shows no thumbnail.

edit: 4 days later, still no thumbnail.

Oh, I just noticed that the welcome messages are now correctly hidden again - hooray!

Will the youtube tag conversion check for videos which have been deleted?

I miss Dopp, she was really good at knowing what people actually meant when they inadvertently used the wrong words.

Tormented Sufferer's confusion stems from the fact that "Add a video" and "Add a photo" links both use the word "Add", and to a non-technical user, there is no clear distinction between the two processes, or any obvious explanation to how "Adding a video" works.

  • Upon taking a look at a video file page, I notice that it says "From Youtube", and not "This file is hosted on Youtube", giving no indication that the video is not hosted by Wikia.
    • The word youtube is linked to, not the actual video page, so even clicking that link gives no indication either.
  • The "File History" tab even has a link "Upload a new version of this file", indicating that the video is indeed uploaded and that it is possible to Upload a new version.

Wikia should look into hiring a User Interface specialist in order to avoid this kind of confusion.

As an aside, I was recently told "your wiki is a mess", and after asking for examples, their problem was with Wikia's UI, not with the content or structure of the wiki. I've been here so long I don't really notice anymore, but Wikia's UI isn't very cohesive. For instance, this blog comment form - most users wouldn't know that it has different origins to the forum comment form, and wonder why on earth they look completely different. The fact that the comment forms work vastly differently makes for a bad user experience, as does the fact that so many system pages are formatted differently. Now, many times that's a Mediawiki problem, but the difference between blog and forum UIs is entirely on Wikia.

Anyway, given the fact that Wikia's UI does not make a clear distinction, we can tell that Tormented Sufferer is using the word "upload" to mean "add/create", similar to how many people use the word "download" to mean "upload", because they think it means "transfer".

While the video itself is not "uploaded (copied to wikia)", a file page is added, so mentally replacing all of his uses of the word "upload" with "add" works fine for understanding what he is saying. In the case "add to a hosting site" it can still be understood to means "upload to a hosting site" and "add to wikia" can be understood as "create a file page on wikia".

It will still show your username. What this fix does is hides the welcome on RecentChanges and WikiActivity.

If you don't want it to show your username, you can change it here: MediaWiki:welcome-user. You can just change it so "Wikia", if you like.

For more info about the welcome tool, see Help:Welcome_Tool.

Apparently you can use a template. I haven't tried it myself, but I imagine it would go a little something like this:


with Template:youtube containing:


When will there be a way to view the app layout through a normal browser?

I've asked about this before, but perhaps my reason for asking was not clear:

useskin=wikiamobile exists for viewing the wiki as it is seen through a browser on a mobile device, so why not also create a useskin=mywikia and useskin=gameguides2 ?

Something like this would be very useful for admins to ensure that their wikis display correctly in these apps.

I recently discovered, using useskin=wikiamobile, that a table on the main page was being displayed incorrectly in the mobile skin, and overlapping other content when the browser width was narrow (something common on mobile devices.)

Without useskin=wikiamobile, I would never have known, and the main page would still be messed up for mobile users.

A skin, or a desktop program, would allow admins to ensure that these apps are not also messing up the formatting.

Excellent Mira84, thanks!

I really don't like how the automated youtube video uploading script is gives no indication in the edit summary of what is actually happening.

  • In Recent Changes, it's posting the videos AS the user who edited the page, using the edit summary "update".
  • In Special:Contributions for those users, it's listing both the video upload, as well as a page edit, with the summary "update".

This is making it appear as though long-inactive users are uploading videos and editing pages, and giving no indication that it's actually an automated process.

"Automated Wikia video upload" would be a far better summary than "update".

edit: Sure, I know what's going on because I read the technical updates, but the average user won't know that.

edit: The RecentChanges entries I'm talking about are actually what occurs if the video already exists.

  • Someone has added a video as a File page
  • Someone else has used the youtube tag to embed the exact same video
  • The automated updater is causing the user who added the youtube tag to be recorded as updating a new version of the file - with the edit summary "update".

The rest of the youtube tag conversions aren't even being shown in RecentChanges - even with "show bots" selected.

They can only be seen by going to Special:Contributions/WikiaBot.

To get notifications of new blog posts, you need to follow the category.

Category:Technical_Updates is probably what you want to follow.

Check out WAM

Apparently community interaction is one of the factors in the score, so highly ranked wikis should have a large amount of social interaction.

Just look for a wiki about a game you like.

That will work for the time being, but the next time those pages are edited by anyone, the youtube tags will be converted to file pages again. (And clicking rollback won't delete the new file pages either, so you'll end up with a bunch of unused videos)

I think the problem is mostly that it's attributing it to them now rather than backdating to when they made the contribution. Even a comment saying "Originally added 2010-05-02 02:49 GMT" would help ease that confusion, if actually backdating it isn't technically possible. (I know I can backdate an edit via import, but I don't think I can do that with a file upload)

Good to know that it's visible in the upload log.

Thanks, I didn't know there was a difference. I've unfollowed the category and followed using that link instead.

Special:Top/most_visited :)

Why not a "Content Notice" style interstitial screen asking anon users to legally confirm they are over 13? (Or to agree to the Terms of Use as a whole, as during the signup process.)

Would this not be as good as people confirming their age during the signup process?

It may be slightly annoying, but it would be less annoying that not being able to edit at anonymously at all, and make it slightly easier for over-13 anon users to edit.

Due to the changes to the law, will you be purging the history of IP addresses if you find out they are used by people under 13?
(For instance, if someone begins editing next month, and then 2 months from now publicly posts that they are 12 years old.)

edit: removed edit, since the next person asked the same question.

We appear to be thinking along the same lines, I just edited a similar question into my comment, I'll move it as a comment here instead.

For wikis with anon editing disabled due to this, will there be a helpful message explaining why anon editing is disabled and inviting them to sign up, or just the standard "You do not have permission to edit this page".
I know each wiki can customise this locally, but many people don't know how, so it would be nice if it was done by default.

Incidentally, here are some related Mediawiki pages.

It's about complying with the law, and Wikia would like to make it as easy as possible for users while doing that.

Incidentally, Wikia Staff have also said "Wikia does not ask admins to police this aspect of our Terms of Use."

Dear Neo Bahamut,

1. Wikis which have been determined as "high risk" of being targeted by COPPA, but feel that do not, have been invited to discuss it. Wikia is being very fair about this - they could have globally blocked anon editing.

2. Wikis do not need information about the selection criteria in order to dispute placing on the list. All wikis which will be affected have been contacted on their local forums, and have been invited to discuss it if they feel that that law does not apply to them.

3. Yes, it is unfair that an adult fan of pokemon is not allowed to edit anonymously. However, creating an account is a snap - it's not like you have to give your real name, or even uses a real email address. An account named "QWERTYUIOP" or "452" is more anonymous as posting as an IP address, for all intents and purposes.

4. It's not supposed to "keep children safe". It's supposed to comply with the law (which is aimed at "keeping children safe"). If you do not think that the law keeps children safe - don't whinge to Wikia about it, call your congressman or whatever.

5. I agree.

"Wikia is still obligated to try and protect children, and people who may be children."

Citation needed.

Jäzzi is 100% correct that "concerned parents" should not use the internet as a babysitter.

We do not need these kind of laws, we need responsible parents, but unfortunately irresponsible parenting is the reason people think we need these laws.

"IMO this is unnecessary."

Strange, because that's exactly what the law says is necessary.

The FAQ addresses lying.

14. Will the amended COPPA Rule prevent children from lying about their age to register for general audience sites or online services whose terms of service prohibit their participation?
No. COPPA covers operators of general audience Web sites or online services only where such operators have actual knowledge that a child under age 13 is the person providing personal information. The Rule does not require operators to ask the age of visitors. However, an operator of a general audience site or service that chooses to screen its users for age in a neutral fashion may rely on the age information its users enter, even if that age information is not accurate. In some circumstances, this may mean that children are able to register on a site or service in violation of the operator’s Terms of Service. If, however, the operator later determines that a particular user is a child under age 13, COPPA’s notice and parental consent requirements will be triggered.

Poor nutrition is the reality, should the government also mandate what you eat? This is a rhetorical question to highlight that you are speaking nonsense.

Nothing you have said address what I have said.

Where was it ever said that "Wikia is still obligated to try and protect children, and people who may be children."?

If I hadn't recognised the quote, I would have had no idea what you were talking about.

Why did you post this as a new comment, instead of as a reply in that thread?

"The really bad thing is how this law effects IP addresses of other countries due to what Wikia is doing."

Not wikia's fault, the law says they have to do that

7. The Internet is a global medium. Do Web sites and online services developed and run abroad have to comply with the Rule?
Foreign-based Web sites and online services must comply with COPPA if they are directed to children in the United States, or if they knowingly collect personal information from children in the U.S. The law’s definition of “operator” includes foreign-based Web sites and online services that are involved in commerce in the United States or its territories. As a related matter, U.S.-based sites and services that collect information from foreign children also are subject to COPPA.

The law says that because Wikia is based in the US, it applies to collecting information from "foreign children".

7. The Internet is a global medium. Do Web sites and online services developed and run abroad have to comply with the Rule?
Foreign-based Web sites and online services must comply with COPPA if they are directed to children in the United States, or if they knowingly collect personal information from children in the U.S. The law’s definition of “operator” includes foreign-based Web sites and online services that are involved in commerce in the United States or its territories. As a related matter, U.S.-based sites and services that collect information from foreign children also are subject to COPPA.

This is a question that really needs an answer, and if posting it time and time again in a new comment as opposed to a reply, then that's what we'll do until we get that answer.

If someone did that somewhere that I was an admin, I would regard it as spamming. I suggest you try posting it time and again and see how that works out for you.

Even if normal users won't read multiple pages, Wikia Staff do, and will respond if a response is necessary. Annoying them by posting the same question is unlikely to convince them to respond.

If a website's "primary target audience is children", then the website operator may not collect identifying information from them.

IP addresses are regarded as identifying information.

Therefore, Wikia may not collect and share IP addresses from users of websites whose "primary target audience is children".

Since IP addresses are recorded as shared if you edit while logged out, wikis whose "primary target audience is children" trigger COPPA.

So, Basically they disabled anon editing for all major wikias whose primary target audience is children. - as is necessary to comply with the law.

If you're a lawyer who thinks that Wikia has somehow misinterpreted that law, I suggest you contact Wikia and offer them your services.

edit: see also, Brandon Rhea's comment below.

We would also be violating the law if we collected certain private information on wikis directed to children

Sorry about 4, I'm used to people saying the opposite, so I misinterpreted your point. Good to know we agree on two things at least!

1. We'll just have to agree to disagree, and I think it has to do with our respective definitions of the word "fair". I agree that it would definitely be more equal to apply the same restriction to everyone, but I don't think wikis aimed at adults should have to block anon users because of COPPA.

2. A summary of the selection criteria has been given.

We looked at factors like the subject of the wiki, taking into account the rating, medium, genre, content, absence of explicit material, demographics, intended audience, actual audience, likely audience, and general accessibility. We also looked at the wikis themselves, and considered their visual content, layout, local character, and activity.

More important that Wikia's criteria is the law - which is public. All you need to do is convince Wikia that COPPA does not apply to a wiki.

1. COPPA applies to Web sites or online services that are “directed to children.” What determines whether or not a Web site or online service is directed to children?
The amended Rule sets out a number of factors for determining whether a Web site or online service is directed to children. These include subject matter of the site or service, its visual content, the use of animated characters or child-oriented activities and incentives, music or other audio content, age of models, presence of child celebrities or celebrities who appeal to children, language or other characteristics of the Web site or online service, or whether advertising promoting or appearing on the Web site or online service is directed to children. The Rule also states that the Commission will consider competent and reliable empirical evidence regarding audience composition, as well as evidence regarding the intended audience of the site or service.

I'm sorry, I can't do that.

Daly Listors

I need to give them a complete reason as to why they're banned

They're not banned. They're required to log in.

Spamming is done with bad intentions.

Citation needed.

Posting something over and over is most definitely spam. The best example of this is Monty Python's spam sketch, which is where internet spam got the name. Nowaday's it is more specifically known as flooding, but it is still a type of spam.

As I said, go ahead and post it over and over, and we'll see how well it works out for you.

Has it occured to anyone to use a popup asking for confirmation of you being over 13 before editing?

No, I've read through all the comments below and absolutely no-one has suggested this.

I've had an account of mine deleted in the past because someone who did not like me decided to fraudulently report me as being under age. They actually claimed they were a parent, and my account was suspended without any proof.

What are Wikia's policies regarding a third party making this kind of fraudulent report?

Lady Lostris, an answer has finally been given:

Semanticdrifter said: "One issue with what you (and others) are proposing is that a checkbox for verifying that you are at least 13 before you can edit has been specifically called out as insufficient by the FTC."

"I was right not to follow whatever 452 suggested."

Don't put words in my mouth, you suggested it, and I told you go through with your own suggestion to see what would happen.

It's people like you who make me think twice about trying to help others.

Is this related to .oasis-split-skin?

I noticed that class was removed, so I updated the CSS to compensate, now the class has been re-added.

I wasn't going to mention it, because you're entitled to change whatever classes you like, and if it interferes with local CSS, then that's my problem, not yours, but changing things backwards and forwards like this is annoying.

MakeCollapsible is broken:

Example on User:452.

Confirmed fixed, thanks for the prompt action on this!

Anonymous users were not always notified that a message had been left on their talk page.

Since this is bug I've reported in the past, I've tested this and it doesn't appear to have been fixed.

Steps to reproduce:

  • Find a wiki that has Message Wall and Welcomes enabled, and allows anon editing. (Or create a test wiki)
  • Edit anonymously.
  • View Special:Contributions/Wikia and wait for the welcome message
    • You can't just refresh your wall, or you wouldn't see the notification anyway.
    • This step sometimes takes hours, I suggest passively waiting, rather than refreshing constantly.
  • When the welcome message is posted, observe that you have received no notification.


And, I've noticed an additional problem, which you can see yourself by clicking Special:Contributions/Wikia and searching for "Welcome to Community Central! on Empty's wall".

I'm seeing 8 in the first 100, and more prior to that. It turns out that some users aren't receiving the welcome message at all.

I wouldn't post here about something which has been fixed.

This sounds like a great idea. Once I've got my own ducks in a row, I'll contribute. :)

I like the emphasis on the template policies being generic, and that individual wikis should modify them for local use.

I find that too many wikis copy complex policies from other wikis without actually thinking whether those policies make sense for them.

Is the wiki focused on having one set of policies per subject, or can it have multiple policies which people can choose between?
When I was expanding some policies, the first thing I did was to go to a bunch of different wikis to see the types of things that they addressed, and used them to create a list of ground to cover.
So I think it might be useful to present multiple policy templates for the same topic so that people can "shop around" for policies more easily.

Doing this may also help encourage greater contributions, as people can drop by and copy/paste/license their local policies. (Perhaps a category of "example policies" can be set up to store "full" policies from other wikis)

A good example of why "alternate" policies are needed would be "Category policies".

  • Some wikis have a policy of "categories are like tags - add every tangentially related category to an article",
  • Other wikis have a policy of "categories are for navigation - use specific categories",

They're both valid approaches, depending on the subject and style of the wiki, so it would make sense to have both policies represented.

When I was writing up policies using my list of "what other wikis addressed", I didn't necessarily follow the same direction as the policies of those wikis, and in many cases I wrote policies which were explicitly opposite what others had written, so there was no confusion.
I figure that it one wiki is going out of their way to forbid something, I might as well go out of my way to ensure that people know it is not always forbidden.
And likewise, I think the Policy wiki would do well to have "permissive examples" alongside "restrictive examples" so it's clear to people browsing that they don't need to forbid something just because another wiki does.

I like the idea of making the pagenames match, it makes it nice and simple to use. (And easy cross-wiki substing, I imagine.)

My ideas are going a little beyond the current scope of the project, since you're focusing on general polices at the moment - I'm mostly thinking of my own experiences, and what would have helped me the most.

One general thing I think is important is avoiding too much overlap with the newly updated terms of use, which now includes the Community Guidelines and Wiki Creation Policy.

Apart from avoiding redundancy, I think it's important to distinguish between global Wikia policies and local wiki policies, and having global Wikia policies repeated in local wiki policies may cause confusion about what policies each wiki is allowed to customise.

Good luck in your travels! I don't know how Wikia will ever replace you!

"Tables wider than the available content space will now allow horizontal scrolling in-place"

Please define "allow"?
Horizontal scrolling appears to be "forced", rather than "allowed", as the "popout" class is no longer being respected.

My feedback:

  • The usage of the word "allow" when describing a forced change is deceptive.
  • Allowing something is great. Forcing something is not.
  • Taking away the ability to add the "popout" class to any table is bad.
  • It would be great if a vertical scroller was allowed, as I'm currently using a div trick to allow scrolling down a table rather than scrolling the entire page.

Disabling the ability to lightbox altogether is a bad move, because there are times a lightbox works better, such as when you want all the information on the screen at the same time. Or for cases where the table is within the page width, but the "popout" class has been added so that cramped information has more room.

I can't actually think of a single table were I would use horizontal scrolling instead of a lightbox - if I had any use for a horizontally scrolling table, I would have used the same a div trick to do that.

While I have no use for the horizontal scroller myself, I respect that others might, and think horizontal scrolling sounds like a great optional feature, but I don't agree with taking away the ability to show a tables in lightboxes.

edit: I can't think of any reason why not to "allow" both at the same time.

  • When a table is wider than the page width, show the table with a scrollbar for people who want to scroll, but continue to show the popout icon, in case people want to see all the content on screen at once.
  • When a table has the popout class manually added, show the popout icon at all times, as usual, and only show the scrollbar if the page is wider than the content area.

Related to this comment: There appear to have been no welcomes since the 1st.

BTW 3cooldog92, the Empty's wall welcome messages have been happening for over a week now. If you look at Special:Contributions/Wikia, you can see which welcomes were left on "Empty's Wall", then you can click through to each message and see the username, then manually welcome the users if you want.

That problem appears to be caused by a "width: 2em;" inline style in the span around the link.

I'm not seeing this problem occurring on other wikis, and I can't see where that style is being applied, but it's a complex template, so hopefully someone with more experience with the template will be able to work it out.

I notice that the navbox is using the old "collapsible" class rather than the built-in "mw-collapsible", so maybe that's the cause.

update: After typing that, was going to link you to and point out that it's deprecated, but first went to check to make sure you were indeed using it, but you're not. = "2em"; is your problem.

edit: nevermind, I was 4 mins late.

I'm looking forward to testing out Darwin, hopefully there won't be any other useful features removed because of it. :/

It was only as clunky as the the gallery lightbox, perhaps even less so due to the gallery lightbox bugs. Speaking of the gallery, I'm hoping there's going to be a Darwin-related fluid width change for that too.

I'm particularly concerned with cases where there is no horizontal scrollbar anyway: Here is a perfect example where class="popout" is being manually added, and is being negatively effected by the removal of this class.
That table is not wider than the page, but popout class was added to allow people to expand it to be less cramped. I have used this technique on multiple pages, and having a fluid width would not effect it. (Other than that people with wider monitors likely will not need to pop out the table after Darwin is available.)

Yes, I could restructure that table to be less cramped in the first place, but even then there is still the other case of allowing people to view all the information on screen at once, rather than having to scroll left and right in order to see the first and last columns.

Hopefully these examples will help. :)

This sounds like a great idea.

I hand out rollback rights like candy to anyone I see undoing vandalism more than once, because I figure that it's best that as many people as possible are able to undo vandalism. (I tell them all "Only click rollback if you don't need to use an edit summary", and there hasn't been any problems.)

I don't even care if they only have few edits, because there's nothing someone with rollback rights can do that I can't undo instantly anyway. (But like I said, I have never had a problem, if someone did hit rollback on every page while everyone was sleeping, I might rethink this)

It would also be nice if there was some form of global-recent-changes available for global-rollbackers - even if it only listed page-blanking, or other mass data removals.

"never an intended method"? That is utter nonsense.

Sannse's instructions make it very clear that it was an intended method.

And we've added a new CSS class so that it can be manually added to any table that you want to be expandable.
Just add class="popout" to the table via source mode

I don't think I have any better examples than the one I linked.

I had noticed that the right rail was already being lazy-loaded while logged out, so this is going to be happening for everyone after tomorrow?

Oh, I thought this would be about previewing the Fluid layout on other wikis. :(

I'm looking forward to testing it as soon as possible. I've tried ?useskin=darwin without success. :(

Thanks for the offer, but it would be negligent of me to request that it be enabled for everyone without having tested it myself to ensure there are no CSS/JS problems.

I'm glad Wikia is testing it so thoroughly, and I'm happy to wait until Wikia thinks it's ready to add to Special:Preferences or to enable ?useskin=darwin

Is there any more information available about the image transfer thing? Or is it purely a backend change which won't affect how we use images?

edit: Also, even if it is a backend image server change, will permalinks be affected?

Category:Technical Updates

It would be nice if it were possible to use the wiki nav before the right rail is loaded. (It's also not possible to access the user menu or notifications list)

What I'm saying is: lazy loading isn't lazy enough, because you still have to wait for it to load before you can use other features.

edit: I just checked: when the blog comments are loading, I'm still able to access the menus.

Either one of those would be great.

Kangaroopower, the fact that it is an evolution of oasis is irrelevant and does not alter the fact that I wish to test the changes for myself before enabling it for the entire wiki.

"Button" color could not be changed in ThemeDesigner."


"Editing or highlighting a forum thread could cause a user to unintentionally unfollow the thread."


"Slideshows sometimes used the interface language of the last person to edit the page."

Hooray! (I assume the TOC language changing is part of the same fix.)

Try this:


=test 1=
==test 2==
=test 3=
==test 4==

H1 headings appear to be ignored by the TOC currently. I hadn't noticed until now, but it is messing up at least one page I use them on. Hopefully this is what they've fixed.

Hmm, well, the update should have been applied by now, but the H1 headings are still missing.

It would seem that this isn't what that was about after all.

Write &amp;nbsp; to produce &nbsp;

H1 headings were not included in Tables of Contents.


Image attribution and Tables of Contents sometimes used the interface language of the last person to edit page.

Part 2 of last week's Hooray!

Improved widescreen source mode editor toolbar behaviour on fluid width wikis.

Good, I had noticed that it was kind of messed up and taking up extra vertical space needlessly, I hope it will act more sensibly now and only use extra height when necessary.
(I had also noticed that there was a positioning problem, but was I never able to work out the exact cause - hopefully this will also resolve that issue.)

If you want to add a warning to editors that they shouldn't use H1 on a wiki which has a policy against it, try this:

.ns-0 .WikiaArticle h1:after {
    content: " Invalid heading level!";

Firstly, I'm a "What can I achieve with this tool?" person, rather than a "What was this tool specifically designed for?" person. If it renders fine in the top 4 browsers, that's good enough for me. (Wikia doesn't pass HTML validation in the first place, so I don't need to worry about that.)

  • "So the reason that the TOC did not include H1s by default is because it is actually wrong to do so. "
  • "It was not a bug, and it definitely didn't need "fixing""

I find that using false statements to support an opinion tends to weaken the argument being made.

I am an admin on a wiki which has a detailed manual of style and has not "outlawed" H1 section headers. They are not used frequently - which is why I didn't notice it sooner - but they are used in some content pages, when it is desirable to have a heading higher than H2, while still using H2 normally. (An alternative would be to add a custom style for that page so H3 looks like H2 and H2 looks bigger, but that would be more work with no real benefit.)

In the past, I've found several bugs I actually liked. One such bug prevented videos from being adding to the wiki, including by local admins and Wikia Staff. Even though that bug helped enforce local video policies, it was obvious to me that it was an unintended bug, so I reported it rather than keeping it to myself, and thanked Wikia after it was fixed. (Along a playful "drat, I was hoping you wouldn't fix it!")

There are plenty of things which are possible but which are against the local policies of many wikis, so the fact that some wikis have local policies against using H1 headings is irrelevant to the fact that it was a bug created by recent TOC changes, and therefore needed to be fixed.

Incidentally, I disagree with Wikia's policy that wikis may not disable default functionality in order to enforce local policies, but their reasoning is the same as I'm using here: just because something is possible doesn't mean it's allowed. (Like you, I wish I were allowed to disable the pop-up upload form, as it is the leading cause of poorly named files, and it does not show the correct error message when people try to use blacklisted filenames.)

I googled it, and it seems that using multiple H1s on a page is not objectively wrong, nor is there a majority agreement amongst subjective opinions. Most search results are people asking questions, to which there are varied answers. (I also found this nonsense: "Strict semanticists sometimes suggest that you should only have one h1, two h2's, 3 h3's etc.", haha.)

Some people seem to be of the opinion that it is better for SEO, but some people are also of the opinion that deliberately leaving spelling mistakes all over your website is good for SEO, so that's a weak argument.

If you inspect the Oasis source for this very page, you'll find 14 H1s, so "H1 is for the page title, only" doesn't apply on Wikia in the first place, as the developers have already decided that it's okay to use more than one per page.(Even in Monobook, the "X comments" line is even wrapped in H1, and that is definitely not a "page title" - and that's fine by me.)

w:c:wowwiki:WoWWiki:Manual of Style#Section headings says that "to use further h1s would be poor semantics.", but there are 12 H1s in the source of that page (in Oasis), so they clearly don't know what they're talking about either.

The Wikipedia page you linked says that H1 is "reserved for the automatically generated top-level heading at the top of the page containing the title of the whole article." but does not explain why it is "reserved", how multiple H1s cause problems, or what the top-level heading has to do with multiple H1s in the article text.

I don't think very highly of anything, be it a manual of style or otherwise, which forbids something without even attempting an explanation.

It just seems to me that none of the monkeys know why they're not allowed to climb the stairs.

After writing all of this, it has only just occurred to me to actually read the HTML spec - none of the discussions I read even mentioned the spec!
I just checked the specifications for several different HTML versions, and the only thing the specification actually specifies is that H1 is more important than H6. (Fun Fact: Early HTML specs call for H1 to be centered, so much for that.)

Some advice for everyone: save a copy of a few pages on your wiki so you can take a look at them after Fluid is enabled.

There's a few little changes you may not be expecting, so if things end up looking "wrong", it will be much easier for you to work out why if you have a saved copy to compare.

I just tested the preview width against the actual width at various resolutions, and it's only correct for the "current" width, and that's only if my browser is maximised (1280px)

It's incorrect at both 784px and 1024px, which are the two "minimum" widths.


edit: Hilariously, I messed up the filenames, but the content of the images is correct.

I've been wondering why a screen width of 768px wasn't supported, as this is a common width on tablets, so I looked into which style was stopping the width from changing below 784px.

This one is. {
 min-width: 768px;

From this, it appears that a minimum screen width of 768px was intended to be supported, but that the vertical scrollbar wasn't taken into account.

The body width does not include the vertical scrollbar, which is 16px wide. So, when the window width is 768px, $("body").width() is 752px.

To allow a screen width of 768px to be used without the horizontal scrollbar appearing, that style must be set to min-width: 752px or lower.

Or, why not just get rid of the min-width style altogether?

The split background is controlled by the :before and :after pseudo-elements, so changing body doesn't do anything, unless you also do this:, {
.background-image-gradient {
display: none;

I was just setting my browser to 768px wide.

But just in case I was mistaken, and both my screen calipers and chrome's width variables were somehow wrong, I set my resolution to 1280x768, then rotated the monitor. (Some graphics card drivers let you do this, others don't. The first computer I tried didn't support 768px height but supported rotation, the second I tried didn't support rotation but supported 768px height, but the third one was just right.)

768px width scrollbar example.png

As Penguin-Pal said, you need to add !important, here:

background-image: url("") !important;

edit: also, to basically every background-related line, like:

background-position: top center !important;

(You currently have top and center on two lines, which doesn't work.)

'; !important;'

In CSS, ';' means 'end statement', so it can't go before the '!important'.

BTW, you might want to find a taller version of the image which includes her legs, because a lot of people with larger monitors will end up with a black bar at the bottom under the image.

Well, if you just want your own layout to look how it was before, you can edit your personal CSS with this:

#WikiaPage {
  width: 1030px;
  margin: auto;
#WikiaMainContent {
  width: 700px;
  float: left;
#WikiaMainContentContainer {
  margin-right: 0px;
#WikiaRail {
  width: 300px; 
  float: right;  
#WikiaSearch {
  display: block;
.WikiaArticle {
  font-size: 13px;
  line-height: 21px;
  • You can set the widths to whatever you want.
  • The margin:auto is important so it will be centred.
  • Font-size and line-height back to how they were previously

But you can only do this in your personal CSS, not the site CSS. (Although Wikia Staff do encourage community discussion regarding changing the font-size in site CSS.)

edit: Updated.

That doesn't sound like how it's supposed to look - if your tablet allows taking a screenshot, you should take one and send it in to Special:Contact.

If you can't take a screenshot, you should report it all the same, because it shouldn't look "crushed".

Just in case:‎

That "(don't ask me who)" bit is weird, that's from Thread:562302.

See Help:JavaScript_and_CSS_Cheatsheet‎. :)

You may have to wait a few minutes before you see the changes.

edit: I made a mistake in my earlier comment, but I fixed it now.

Haha, okay.

  1. Decide if you want it to be for just one wiki, or all of them.
  2. Edit that page
  3. Paste what I said earlier
  4. Save page.

For example, here's what mine looks like: User:452/wikia.css, but I've set my width to 100%, instead of 1000px. You can put whatever value you like.

You cannot do this for a whole wiki, you can only do it for yourself.

Nobody needs to do anything, but you can change anything that you want to change.

Yous should be aware that adding code to MediaWiki:Wikia.css to override the new changes to the fluid layout on yous wiki could potentially land yous in trouble with Wikia Staff.

Small compatibility tweaks to yous wiki's custom skin are obviously okay, but the new font-size was obviously a deliberate change as part of Fluid, so it's best yous ask Wikia Staff before yous change it.

It would help if yous explained WHY yous don't like it. "I'm irritated by it" is not constructive criticism, and "I'm irritated by it, so I'm changing it" is not a justification that any good admin should use when making a decision - and not likely something that's going to sway Wikia Staff.

BTW, they told me to start a discussion about it on the wiki in question, which is what yous should do too. (Personally, I set up two example pages, one using font-size 13 and the other using font-size 14, I asked people to compare them side by side, then set up a poll so people could vote on it anonymously without fear of the vocal minority belittling their choice.)

That said, everyone is free to add any code they like to their personal CSS (Special:MyPage/wikia.css)

I took a look at the wiki you're talking about, the problem is being caused by the images in your right sidebar being 300px.

You'll have to change them to 284px or lower.

Changing the font to 13pt site-wide without permission violates the TOU.

edit: No, it won't. See BertH's comment here

If Wikia Staff give you permission to do something which would otherwise violate the TOU, it's not a TOU violation.

If you have a good reason to need the font-size to be 13px, tell Wikia Staff via Special:Contact, and link them to specific examples of pages which need to be 13px, and maybe they'll see things your way.

It's mandatory right now.

Why does having a larger monitor mean you're suffering?

Try explaining exactly what it is that you don't like about it.

This post is about the Fluid layout. You want User_blog:BertH/New_VisualEditor_now_available_in_Labs

You can simulate the old layout by creating your own CSS page at Special:MyPage/wikia.css.

I hadn't previously read about the increased font size being for to larger monitors, thanks for the info.

In that case, why not have the font-size change dynamically along with the width? So that the font is 13px for monitors at the lower end of the scale, and 14px for monitors at the higher end of the scale?

It is a good idea, and is something you can do using CSS already.

The way the theme designer "splits" the background is that it just applies the background twice (using and, once aligned to the left, and once aligned to the right, the covers the middle with the fade section.

The trouble is that it's difficult to get it to appear exactly how you want through theme designer, as it pretty much has it's own ideas of where it wants to align the background.

Personally, I gave up on trying to "make it work", and just switched to a tiled background.

edit: Expanding on BertH's comment below, it's would be better to upload a single image containing the "left" and "right" halves, and used CSS to make sure it is positioned correctly.

Perhaps instead, the Theme Designer should be updated to allow the "left" and "right" portions to be manually aligned, instead of doing it automatically.

They're still 300px. It could be that you're just getting used to it, so it doesn't seem so small any more.

Ok, I thought you meant there was some other problem.

I've used a 23in monitor at 2048x1536 for years. I expect websites to use the full width, and to me it's annoying when some webmaster arbitrarily decides "I'm going to set my site width as 1024". I didn't buy a huge monitor so there would be empty space on either side of a website.

"So the larger the monitor the more zoomed out and empty the new layout is" is exactly how I would describe a 1030px column in the middle of a 2048 screen. (Although, Fluid maxes out at 1600px, so it's still annoyingly thin.)

I am still very interested in understanding why you feel that it is a burden that more of your horizontal space is used up, if you would like to explain it for me some more.

I've seen a couple of specific complains about the wikinav being "empty" on the right side at high resolutions, yet I've not really seen any solutions offered other than "change it back!"

It does seem a little silly that on wider monitors, it's:
"Wiki Activity, Random page, Videos, Photos, Chat, Forum                                                    "

My suggestions:

  • Make the links variable width so that the full space is taken up.
  • Make the font-size of the links variable so the menu becomes visibly larger and takes up more of the space.
  • Make the menu fixed-width and aligned to the right, instead of stretching across.
  • Make it easy to add extra menus/links which only appear when the width supports them. (I'm planning on looking into this option myself.)

(I'm posting this here rather than suggesting it via Special:Contact so that others can offer their feedback on these suggestions)

That's weird, because I always felt like the small content space disguised it when articles had very little actual content.

While difficulties in maintaining two separate layouts is often cited, I don't really think it applies in this case, because it is possible to simulate "the fixed width look" using CSS fairly easily.

The reason that's not allowed is probably more to do with the fact that they want all wikis to have the same general layout.

"Now I have to scroll down to access the links and objects that were once conveniently placed."

Are you saying that on your wide monitor, the "Recent Wiki Activity", "Recent Photos" and "Live Chat" boxes are at the bottom of the screen? Because that doesn't sound how it's supposed to be. They're all still on the right side of the screen.

Can you take a screenshot of your screen please?

They sound like some great improvements, I can finally remove my hacky solution to stop the mobile browser rendering non-infoboxes as infoboxes.

If you would like to keep the right rail on the right at resolutions lower than 1024px, you can add these CSS rules to Special:MyPage/wikia.css (See Help:JavaScript_and_CSS_Cheatsheet for more info)

.WikiaMainContentContainer {
  margin-right: 310px;
.WikiaMainContent {
  float: left;
  margin-right: -320px;
.WikiaRail {
  float: right;
  width: 300px;

Perhaps Wikia Staff would consider adding "Don't move right rail at lower screen widths" option in preferences to achieve this for people who would prefer it this way. (It would be beneficial for Wikia, as the right rail ad would still be displayed in the same place, and by their own accounts, that ad is the breadwinner.)

That's not a new prompt, it was supposed to have been like that for a long time, but there was apparently a bug that caused it not to appear in some cases - they fixed it two weeks ago.

(I also don't really like it either, but I've learned to live with it, and I've used Mediawiki:newarticletext to add a helpful message when creating a new article.)

That screenshot is of an Ipad, and that is how the layout is supposed to look at lower than 1024px wide.

If you have a larger monitor, and your browser window is wider than 1024px, then it shouldn't look like that.

Mscoree, please post a screenshot.

Could you please post a screenshot, Hail Storms Wrath?

Here's how to achieve my first suggestion:

.WikiHeader .WikiNav li.marked>ul.subnav-2 {
   display: table !important;
   width: 100%;
.WikiHeader .WikiNav li.marked>ul.subnav-2>li {
   display: table-cell;
   float: none;
.WikiHeader > nav li.marked .subnav-2 li.marked2 .subnav-2a {
   float: left;

In practice, it is not really much of an improvement, due to the huge space between each link/tab.

I didn't think that custom backgrounds for the top header were allowed.

If you're talking about how the background on the bottom bar has a margin, that's because .wikia-bar has a margin. Apply the style to .WikiaBarWrapper instead.

AlexShepherd, it doesn't look like you've actually read this conversation.

From what Mscoree is saying, it sounds the skin is actually not displaying correctly, so how does it help to bring up some random browser extension?

Hail Storms Wrath, are you saying that it's an intermittent problem and isn't consistently reproducible? That definitely sounds like a bug, because the changes due to Fluid width should always change the the same way at each browser width.

making highlighted words etc non highlighted.

Standard bold, italic and sup text is working fine for me.

I imagine that em, strong, mark tags are also respected (And I'm deliberately using them here so I can check this immediately after)

edit: em and strong work, but mark isn't even supported by Chrome, haha.

How does that fix the problem Mscoree is having?

Did you post this in the wrong thread by mistake? That doesn't appear to have any relevance to this discussion.

There are many websites which show a variable number of links in a menu depending on the screen resolution. (The earliest I remember noticing that kind of thing was 6 years ago, but there were probably websites doing that even earlier.)

Unfortunately, by default, extra tabs aren't actually hidden, they're wrapped onto the next line, but they can be hidden better with this style:

 .WikiHeader .WikiNav .subnav-2 {
   overflow: hidden;
   height: 2em;

There are also more complicated CSS rules to specify certain links to disappear at lower resolutions, like this: @media screen and (max-width: 1024px) {

 .WikiHeader > nav .subnav-2 li .subnav-2a[href="/wiki/Blog:Wikia_New_Features"] {

} On Community Central, this will make the "New Features" link in the news menu disappear at widths below 1024px. As you can see, with this method you need to display the URL for each link.

I'm thinking of doing this myself to use the extra space, although really, what Wikia should do is add an extra ad into any blank space that people whine about.

It sounds like "Everything is just stretched to unproportional widths" because the right modules are incorrectly being moved to the bottom.

These questions:

  • "Why must people with larger monitors suffer?"
  • "Why not have useful stuff on the sides, so I can get more out of an individual screen? Now I have to scroll down to access the links and objects that were once conveniently placed."

appear to indicate that Mscoree has encountered a bug, because someone with a larger monitor who is seeing the right modules below the article content will certainly see the article "strectched to unproportional widths".

Which is why I'm waiting for a screenshot from Mscoree, because then we will know:

  • The browser
  • The resolution
  • Exactly what is happening on the screen, and whether it is indeed messed up.

However, the problem could also be caused by an outdated browser, so Mscoree, along with that screenshot, could you also please tell us the version of your browser. (Also, update it to the latest version, if possible, and see if the problem goes away.)

Hail Storms Wrath, that's kinda the main point of Fluid.

I don't understand why people with Ipads are even posting in this thread, Mscoree specifically mentioning having a larger monitor - an Ipad is not a larger monitor.

Mscoree, we're still waiting for that screenshot please.

  • You can still use Oasis-like fixed-width.
  • You cannot set an entire wiki to use Oasis-like fixed-width.

I've noticed that occasionally too, it most often happens to me when actively resizing, and I've yet to work out that cause.

Does it happen for you all the time?

If you can say it on TV, you should be able to say it here.

A better question is "Since when was using vulgarities a problem on Wikia?"

The only words that are problems are in "content that is obscene, pornographic, abusive, offensive, profane, or otherwise violates any law or right of any third party, or content that contains homophobia, ethnic slurs, religious intolerance, or encourages criminal conduct;"

Vulgar is not the same as obscene. There's no rule that says you have to write formally, so vulgarities, slang, colloquialism‎s and other informal language should be fine.

Futhermore, the phrase "lucky bastards" is not an offensive one. Would you have a problem with the phrase "lucky devils" even though that also uses a word that could also be used offensively?

I also see the second scrollbar on that wiki.

I poked around at their CSS, and it's indeed their site CSS that is the problem. It looks like whoever made it had no idea what they were doing.

You need to tell the admins of that wiki that they need to fix the problem.

One of my favourite recent games in this genre is Aquaria (available for Windows, Mac, Linux, Android and iPad)

  • Introductory hand-holding, then it's up to you to explore.
  • Auto-map with bookmarks
  • New areas open up after acquiring new abilities
  • A variety of different areas, each with unique visuals, enemies and music
  • Full access to backtrack through all areas, with new shortcuts later in the game
  • Plenty of hidden stuff to reward exploration
  • Story is basically optional if you just want to kill things
  • The jellyfish look a little like metroids

There's an aquaria wiki, but it needs some work.

Yes, .picture-attribution was the class used in pages published yesterday, and .attribution is the class in pages published today.

Since cached pages still use the old thumb style, the .picture-attribution rule will have to be left for a while in order to remove it from both old and new pages.

Yes it is tedious to correct oversights and mistakes of the past, but naming standard are important, as good filenames help with searching, and it's always useful to be able to identify content from the filename alone.

The fact that some wikis have lax naming standards is a shame, and those wikis are doing themselves a disservice, so hopefully this change will encourage many wikis to adopt naming standards now.

And this isn't just my wiki, it's literally every video on every Wikia in existence.

That is false. All videos on the wiki I use have sensible names - although the fact that Special:WikiaVideoAdd doesn't allow specifying the title certainly doesn't make it easy for people to use good names.

I've personally renamed hundreds of poorly named files, and use MediaWiki:Titleblacklist to prevent gibberish filenames from being used anymore. I have not actually tested whether Titleblacklist applies to videos, but I assume that it does.

I'm sorry that I misunderstood, I thought that was your point.

I understand that you don't like the change, but I do not understand why.

Your original comment was:

I also don't like the idea of having video titles in thumbnails. Some editors will add video titles with silly names such as "File:439fdk-9fkm2ldk3" and being unable to hide that in the article itself will look atrocious.

Then your next comment was also entirely concerning poor filenames, but you've told me that I misunderstood.

EVERY video on every Wikia is going to have their filename publicly shown

So, if all of the videos on your wiki had sensible filenames, would you still not want them displayed?

You've only given reasons against showing poor filenames, what do you have against showing sensible filenames?

Alternative method to hide username below thumbnails:

  1. Create MediaWiki:Thumbnails-added-by with &#32; (Character 32 is a normal space, FYI)
  2. Purge pages with thumbnails to see the change.

This has the downside of not affecting cached pages, but the upside of the username being removed from the page source entirely.

Normal captions may also be be inconsistent. Having consistent filenames, and captions, is up to local wikis to work out.

Your point now appears to be "Displaying filenames duplicates captions", which is a great point, but I do not understand why you had not mentioned that previously.

You can restyle it however you want, within reason. As far as I'm aware, there's nothing stopping you from re-styling it to exactly how it was before.

See: Help:JavaScript and CSS Cheatsheet

It can easily be reversed with CSS, and I have had no trouble doing so.

The width of the thumbnail wrapper has always been fixed width, as can be seen by inspecting any cached page.


<figure class="article-thumb tright" style="width: 280px">


<figure class="thumb tright thumbinner" style="width:282px;">

Is there any way I can make this look any less horrible?

Yes, you can edit the CSS: Help:JavaScript and CSS Cheatsheet

Here's how to edit the CSS for a wiki: Help:JavaScript and CSS Cheatsheet

Here's the customization policy: Help:Customization_policy

It looks like it's working fine to me on

I would also prefer that the photo and chat modules be above the video module, because both the photo and chat modules promote interaction more than the video module does.

It doesn't, but you can add this to your personal CSS

#videosModule {
  display: none;

If your wiki is aimed at children, it should already restrict anon participation.

Use Special:Contact and let them know.

If you just have a comment spam problem, then it should be possible for anon comment creation to be disabled while allowing anons to still do other things.

In general, commenting is usually kept open, so be sure to link to a bunch of examples of spam/vandalism.

I am not Wikia Staff, giving me that link is pointless.

Flawless Diva wrote: You'll need to make the wiki anon-free, and therefore anonymous users who aren't logged in won't be able to edit, comment, or leave messages.

That is false information.

I have asked via support about restricting which videos are shown, but was not told of any way in which to do it.

remember you don't have to be an admin to stand out on a wiki.

This is great advice.

the administrators are elected out of the pool of rollback users

This is a great idea which all wikis should adopt. (I also do this.)

Why do you want to be an admin?

That sounds like a very useful feature. I've wanted something like that for some time, and would definitely add TemplateData information to all templates.

It don't think enabling it creates extra work, as it's up to individuals whether they want to add the data to each template. It doesn't appear to be any problem if the information isn't filled out.

Not having it enabled currently creates extra work when users add bogus fields to templates, or add unsupported values to boolean fields due to the lack of a visible description.

The attitude that you shouldn't ask to be an admin stems from the fact that the majority of people who ask to be admins are unsuited for the task.

For some reason, a great many people request adminship as their first contribution, or within their first week of editing.

Of course, if someone who has been on a wiki for years and has thousands of edits was to request adminship in order to help with a backlog of maintenance issues which the current administration is unable or unwilling to deal with - then I don't think anyone would have a problem with that request.

Wanting to be an admin without a need to be an admin is the problem.

Good stuff!

I know it's mentioned elsewhere, but you might want to expand the "bad admin" section a little:

  • Try to resolve the situation, on that wiki, calmly.
    • Establish why the admin did what they did, and find out about applicable local policies.
  • If the admin is acting illogically, unfairly or are not following local policies, contact another admin on that wiki, calmly.
  • If blocked, contact the same admin here on Community Central, calmly.
    • If the problem admin won't respond here, contact alternate admins, or other users of that wiki here, calmly.
    • It's incredibly likely that other users here on Community Central will contribute to the discussion with their opinions on whether or not the admin is in the wrong.

(I'm actually not sure what the best step is after this.)

Many problems users have with "bad" admins stem from the offended user flying off the handle.

Right now, on gaming.wikia, I'm slowly using these steps to deal with the fact that an admin there has deleted my user page for apparently no reason.

Many "rules of thumb" say to "never" do something, but there are always exceptions.

Let's make a flow chart:

  • User has few edits:
    No reason to ask for admin rights
  • User has many edits
    • User has a history of "problems" on the wiki:
      No reason to ask for admin rights
    • User is in good standing
      • The wiki has enough admins to deal with all admin tasks:
        No reason to ask for admin rights
      • The wiki has no admins:
        Follow adoption procedures
      • The wiki has active admins, but there is a backlog of admin tasks:
        • There is an existing application/nomination process:
          Follow application/nomination process
        • The wiki is well-managed by attentive and responsible bureaucrats:
          Bureaucrats offer admins rights to likely candidates
        • The wiki doesn't match the two preceding statements:
          Good reason to ask for admin rights

The majority of cases listed have no reason to ask for admin rights, so there is likely to be far more people who have no reason to ask for rights, therefore it makes sense for the default to be "don't ask".

The majority of the people who responded below are probably talking about well-managed wikis with attentive and responsible bureaucrats, who offer admin rights to likely candidates when the need arises.

I've never been asked for admin rights by anyone who had a reason for wanting them. Or who stayed active after being told to become a good contributor first. That makes me question why they asked in the first place, and what they would have done if I had just given them admin rights.

Becoming an admin shouldn't be anyone's goal, the goal should be to be good contributor. As others have said, you don't need admin rights to be a good contributor.

If someone tells me they want to be an admin, I respond in two ways:

  • Telling them how they can help the wiki without admin rights.
  • Asking them why they need admin rights.

No matter how active and responsible a user is, or how many people "vote" for them:

  • If a wiki does not need a new admin, then there is no reason to appoint one.
  • If a user does not need admin rights, then there is no reason for them to have them.

No regular contributors have ever asked me for admin rights - because I always give admin rights to regulars once they've proven themselves suitable.

  • Part of that is just being a good contributor
  • Part of that is making things easier for myself and other admins by doing maintenance tasks.
  • Part of that is whether they need to be able to delete redirects, files and vandalism.

I just created a test wiki and anon editing is allowed:

Did you check with Wikia Staff, like I did?

Wikia Staff have confirmed that it is possible to block anons from leaving comments, while leaving the main namespace fully open to editing by anons, which makes Flawless Diva's post false.

edit: They even linked me to the documentation on the subject:$wgNamespaceProtection

Yeah, that's unfortunate.

I always appreciate small spelling/grammar/formatting edits - those type of edits are a great way for new people can start editing without having to know anything about wikis.

If you make a lot of tiny edits to the same page, then I would expect you might get a warning to take your time and preview your edits first, but a block for that seems excessive.

Since the addition of the video sidebar, fewer new people are joining the chat.

I can only assume that this is because the chat module is further down the page, and fewer people are noticing it.

edit: because I'm a fan of actual data:

  • 8-16 May: 5 users: 3 regulars, 0 first-timers.

The 8th is the first day I saw the videos sidebar, so I assume this was the day it was enabled.

  • 1-7 May: 14 users: 4 regulars, 4 first-timers.

To give you a better idea of the "norm":

  • 24-30 Apr: 15 users: 5 regulars, 6 first-timers
  • 17-23 Apr: 17 users: 5 regulars, 7 first-timers
  • 10-16 Apr: 16 users: 5 regulars, 8 first-timers
  • 3-9 Apr: 12 users: 4 regulars, 4 first-timers

It has never been a "busy" chat, and activity over the last month is a little below average, but since the introduction of the video module, activity has really dropped.

Of course, this is just the results from a small wiki with a chat with rarely more than 5 people at a time, so it would be good to know whether other wikis have noticed a drop in new people joining.

Thanks for the report, I'm sure that Staff can find out who is and block them.

edit: Nope, Staff have refused to do anything.

Congratulations on getting away with it, Legouniverse143, and good luck with your future trolling.

Test wikis are allowed, but personal wikis are not allowed on Wikia.

"There should be some sort of voting system for the normal members, to prevent (or fix) admin abuse."

So, make one. Tupka217 has already linked to the relevant blog posts.

The main consideration should be whether or not the individual user being considered needs the rights.

I'm glad you both agree with me, thanks.

the flow chart misses at least one key possibility: current admins are not good admins and the process for adding admins is unclear and arbitrary.

This is intended to be covered by the "doesn't match the preceding statements" line.

  • If the current admins are not good admins, that means the bureaucrats are not attentive and responsible, so it's okay to ask... although there's also no point, since the bureaucrats are not attentive and responsible.
  • If the process for adding admins is unclear and arbitrary, then that's the same as if it didn't exist. (Writing "The wiki has an existing, easy-to-find, detailed and clear application/nomination process that completely removes any reason to ask" was too long.)

Yeah, the tense used in these updates often misleads me too.

As far as I can tell:

  • If they write something in past tense, they mean it will happen tomorrow.
  • If they write something in present tense, they mean it has already happened.

You're correct, but if the smaller duplicate wiki is abandoned, an admin on the bigger equivalent can merge the content and request that the wiki be closed.

See Help:Merging wikias for more information. (As linked earlier by Tupka217)

Incidentally, to use youtube links in a ref template like that, you need to add 2= before the second parameter, because the = in the youtube link is interpreted as a parameter name.

The 'inline' video style is being retired - videos will always be displayed as if the thumb option has been selected.

I often use center|frame for videos - will this remain available?

The "View photo details" link now appears to be missing from all image and video thumbnails.


The "view file details" option on thumbnails will be removed, since the file page can be accessed by control-left-clicking on the image or video

Personally, I preferred to be able to single click that "view file details" icon, although I do like the fact that the image link now leads to the file page rather than the image.

I concur with Acer4666, control-right-click is opening and then immediately closing the context menu for me.

control-left-clicking the image is opening the file page.,_Slideshows,_and_Sliders/wikitext#Live_example_2

Chevron kittens.jpg

Every slideshow now has these. The chevrons, not the kittens.

Since many people are likely to notice this and start complaining about it, I felt it was a good idea to highlight this in public in an attempt to avoid unnecessary reports.

Here's how to edit the CSS for a wiki: Help:JavaScript and CSS Cheatsheet

DEmersonJMFM, one thing I've found handy is to double-check things in the CC Sandbox to make sure that it's a problem which occurs everywhere.

div[id^=wpPollStatus] {
  display: none;

the new revision will spread across the caches faster and more reliably.


The Special:WikiFeatures status refers to whether it's the default when you click the "edit" button.

I also hate it when any editor alters spacing.

Here's Kirkburn's comment about that

The change has apparently been reverted, and the problem no longer occurs on the linked page - you can easily see that the arrows no longer match and no longer turn blue upon hover.

It is good to know that you're not happy with it, and I hope that means you're intending to resolve the "spaces removed" issue. It's weird that it's not happening on wikipedia though.

I think that the fact that the spaces are being removed is a symptom of a larger problem with how the VE works, and the same problem may cause other currently-unknown changes, so it's always best to find and fix the root problem, even if you can only currently see minor symptoms. (Note: I'm not a doctor.)

I guess it all comes down to "Should all changes be intentional changes by the user?"

I believe they should, and that users are responsible for the edits they make, and that unintentional changes made by the VE undermine that.

On the other hand, if making changes on behalf of the user is okay, then I have a javascript "spellcheck" script which I would very much like to enable for all users but haven't because I assumed that it was against the TOU to force people to make changes they did not desire to make.

edit: Also, adding and removing spaces makes it more difficult to review diffs, and may lead to an increase in people getting away with "removing a single space in a paragraph" vandalism.

What Wikia staff should be spending its time on is creating "How to" guides for new editors that are written in plain, simple, straight-forward language and accompanied by " Do this A and you get this B " examples -- and that don't assume that the proficiency of a wiki user is anything more than basic.

Hear hear!

Many of the help pages are too confusing for new users, and it's hard to actually find needed help.

Additionally, I recently contacted Wikia Staff asking about something on a help page that wasn't working, they told me it was out of date, but didn't update the help page.

Woah, cool.

It's just way too complicated for the average user in my opinion

The average user does not need to use it. It's optional.

The Visual Editor is not the default for me, or anyone else who chooses for it not to be. The new Visual Editor was always intended to replace the old Rich Text editor.

But that is completely beside the point.

Do you seriously think that they will disable parser functions and break all existing templates and force people to use LUA templates?
The words to describe anyone who thinks that are forbidden on Community Central.

They do not have time to learn a Wikia-specific blogging language. Nor should they have to.

Nor do they have to.

Could you elaborate please? I'd like to see if I can help.

I did elaborate. I brought up specific issues, and asked you specific questions.

In return, you gave only vague general responses, which did not address the questions I asked. Some issues I brought up received no response at all.

  • As the person asking the questions, the burden falls on me to be as specific as possible with my questions.
  • As the person answering the questions, the burden falls on you to give responses which address the questions.

When I informed you that I did not think you understood my questions, your reply was something about me not understanding your answers, which is not a constructive reply - your responses did not match my questions. Due to the fact that you did not appear to be interested in answering my questions, or addressing the specific issues I brought up, I stopped replying to you. Until I saw this request, I just figured you were "too busy" to answer my questions.

Lua isn't used for a lot of things outside the Wiki realm

It is one of the most popular video game scripting languages, and has been for over 10 years, and there are many other uses.

At the bottom of every Wikia email is this message:

* Want to receive fewer messages from us? You can unsubscribe or change
your email preferences here: 

even though infoboxes are ultimately meant to look consistent from wikia to wikia.

Woah, what? Since when?

Where does it say that there is supposed to be consistency amongst page content from wikia to wikia?

I have specifically asked about this in the past, and was told that there were no policies even regarding internal consistency, let alone external consistency.

edit: For the record, I slightly misremembered this:

  • I asked: "Once upon a time, I swear I read a wikia guideline saying that there was no requirement for different wikis to follow the same layout conventions, and even that consistency across articles within the same wiki wasn't necessary either. There's an editor telling me he's "right" because "all the other wikis do it this way", and I would like to point him to what I remember reading about consistency between different wikis not being a rule. Any idea where i can find that?"
  • The answer I received from Wikia Staff confirmed that this was true, and quoted "We strongly encourage wikis to create their own specific guidelines and rules that fit their community and topic." from Help:Community_guidelines.
  • I never found what I had previously read about there being no rule regarding internal consistency, nor was it addressed in the response, but clearly, if wikis may create their own specific guidelines, then wikis can choose for themselves whether they want their "character" and "location" infoboxes to look the same, and whether or not they want the HTML to be consistent.

The "view file details" option on thumbnails will be removed, since the file page can be accessed by control-left-clicking on the image or video (see the bug fix noted above).

This does not work after playing a video.

I think that enabling the new visual editor before it was finished was a big mistake, one which Wikia repeatedly makes. Just about every new feature is unfinished and contains a bunch of bugs.

First impressions are important, and when people's first impression of the new feature is "another unfinished piece of rubbish", then that's how they're always going to think of that feature.

I was excited about both Message Wall, and the new Forum, but both still have issues which were present on day 1, so it stands to reason that the new VisualEditor will continue to have issues for years to come.

If I had the option, I would disable the visual editor until it was complete, or at least until there were no known bugs.

Summary: The chat is unofficial and what happens there does not matter.

Special:EditWatchlist and Special:EditWatchlist/raw

I could easily make a fake android screenshot, if you would like proof that it's possible.

I agree, the temporary nature of the chat is at odds with the goal of most wikis: sharing information.

but it matters to quite a few users and wikis

Solution: quite a few users and wikis need to realise that the chat does not matter, and that their time would be better spent improving their favourite wiki.

and then problems will form on the wiki

If issues in the chat spill out of the chat, then there will be evidence, and those people can be blocked for disruption.

A "chat bot" could be interfered with by whoever controls it, making it only as reliable as whoever runs it.

In summary: Text can be changed, screenshots can be altered, chat bots can insert fraudulent lines, and people can lie.

It is a good thing that Staff do not make decisions based on information which could possibly by falsified.

If the server stored the logs, then there is no chance of tampering. edit: except by Wikia Staff...

You know when you enter the chat, and you can see the last ~10 lines so ~10 minutes of recent chat? That's stored on the server. Presumably, there's a literal ~10 line and ~10 minute limit - I haven't experimented to find the actual values.

There is no technical reason why that couldn't be increased to be stored for longer. Except disk space, which is obviously not an issue.

edit: apparently the "when you edit a blog comment twice in a row, your first edit is removed" bug was never fixed.

In this blog post, he is going to talk about a question that staff often hear: "why won't you look at my chat screenshot? It shows someone misbehaving!" It can be hard to say no when this happens, because often we believe those showing us the screenshot. But we have to be fair and consistent, and Master Ceadeus explains why that means not accepting screenshots.

"No bugs" is unlikely. There will always be edge cases that even the best testing may miss, but releasing with known bugs is abhorrent behaviour.

Testing and bug-fixing is vital part of of the software development life cycle.

Web development with an existing database gives you a vast amount of input data for tests. A script to load each page in the database though the Visual Editor and log changes would be trivial to implement, and is an obvious test to use if the goal of the Visual Editor is to make no changes to existing wiki-text.

That template appears to rely on Template:Time convert, which is not present.

Yes, this is offtopic, try asking on Message Wall:Jimbo Wales.

I didn't say he would respond, but if you look at the posts on his wall you can see that someone usually responds.

Yes, thank you Volunteer Developers, it's about time those 2 bugs were fixed.

Removing or closing a Wall or Forum thread will no longer cause a broken link to appear on Recent Changes.

On Recent Changes, single entries, whether viewing grouped or ungrouped, have malformed a elements: "on the <a href="Board:Support Requests - Getting Technical">Support Requests - Getting Technical Board</a>‎".

edit: Additionally, all edits to Threads have the summary "((edited message))"

edit: this also effects Special:Contributions

Imagine this says "Visual editor" instead of "Classic editor"

"Is there a way to reach the new VE when I am logged in?"

It should be at the top of the drop-down list, right above history.

A bot operator can potentially edit the bot's stored memory before it is committed to the log page.

Yes, the old visual editor was notoriously bad at placing images within the middle of sentences, and even within headings - hopefully the new Visual Editor won't do this.

As with the thumbnail changes, the change occurs when the page is saved - so if you edit or purge a page which has a working audio file, it stops working.

Until this is fixed, I would avoid editing pages with audio files, if at all possible.

Disabling the Chat is simple, and not enabling it in the first place is easier done than said, because it only requires inaction.

I do not have a deeper problem.

Wikia has a deeper problem in that they do not care who become admins, or whether admins are trustworthy.

"Here are the latest technical updates at Wikia. Keep in mind that our system updates happen every Wednesday, so we're posting this on a Tuesday to give you advance notice. Also note that we change hundreds of tiny details every week, so these are just the highlights."

I've noticed and reported that too.

I'm surprised this hasn't been fixed already, or just reverted. I think they're going to make us wait a whole week.

The worst part of this problem is that even when they fix it, any "broken" pages will remain broken until they're purged.

Perhaps "Lua is optional, and nothing will change unless you choose to use it." needs to be in big letters at the start of the blog post.

You do not need to wait an eternity.

Although I also expected the update to be rolled back as soon as these issues were discovered, we only need to wait around 16 more hours.

A very helpful post indeed. Every single step is exactly what I would do.

You shouldn't use other wikias for this and drag the conflict into another community's space. That can get you banned from that wikia

It might also get your original block extended.

It's also generally considered bad form to contact another admin from that wiki to complain about the first admin without first attempting to resolve the issue with the original admin. I rarely bother contacting a second admin if the first admin is reasonable.

Telling a corrupt or incompetent admin they are incompetent or corrupt rarely works. And pointing out that they are corrupt, incompetent or just plain lazy to people who are equally corrupt, incompetent or just plain lazy is likely to fall on deaf ears. (Of course, if your intent is to highlight to others that Admin A, B and C are all corrupt and/or incompetent and/or lazy, then this is a great way to do it, as the way those admins respond to such claims says volumes about them.)

How would you question an unexpected block?

Assume there was no block reason, or something nondescriptive like "vandalism", and that there was no related informative edit summary, and no wiki rules.

Okay. I personally wouldn't mind someone asking "Why was I blocked?", but I personally don't tend to leave anyone guessing since I normally leave messages before blocking someone. (Unless they replace the main page with "aasdkadkj".)

That's interesting. I didn't think Staff did that. Could you please link to me to the wiki where you were blocked?

Is this it? Thread:450572

block log

You were indeed unblocked by Wikia Staff, but were subsequently reblocked, and are currently blocked.

The point of this blog post is to reduce the number of people posting on the CC forums regarding blocks. Or at least reduce repetition by linking those people to this blog post instead of explaining all of this each time.

Contesting a ban never works. For it to actually work there would need to be mature adults and not kids running as administrators around wikia.

Contesting a ban may "never" work on the wikis you frequent, but not all wikis are the same, thankfully.

There are wikis with mature adult administrators who warn before blocking, never use infinite blocks, and realise that most vandals don't return and therefore only block for as long as is necessary,

And frankly, who would want to contribute to a wikia that has admins who block badly and won't listen to reasonable discussion about it?
Case study: Me.

When I first started editing on wikia, I was blocked by a <redacted due to Community Central's "be nice" policy> admin.

I had made several edits he disagreed with, so we started discussing it, at which time I immediately ceased my edits - because it's rude to continue editing while discussing the merit of those edits, and doing so would most likely incur a block. While we were still discussing it, he blocked me, even though I had not made any further edits.

I did not "move on" because:

  • I enjoyed the subject matter
  • The wiki in question was in terrible condition
  • I wanted to help create a great repository of information
  • I knew that that particular admin was in the wrong
  • I knew that one <redacted> admin doesn't represent the community

I created a second account and appealed to the bureaucrat, who agreed with me, and demoted the other admin. I now have the most edits on the wiki, and eventually became admin myself, although I was not seeking that position.

The moral of the story is: If you are ever unfairly blocked, keep a cool head and you will eventually become admin.

but what if the bureaucrat had been a <redacted> too?

I probably would have "moved on", because at the time I didn't realise that bureaucrats were answerable to the community. Knowing what I know now, I always try to inform people to start a community discussion if the highest-ranking admins are provably unfit for their position.

I made it clear to him that the second account was only to contact him and not to continue editing. I didn't know about Community Central then, and didn't think it was appropriate to contact him on a different wiki about issues from that wiki.

I had mistakenly attributed the lack of IP welcomes to lag.

Many, I dare say most, Wikis that would be interested in this would already have a map image uploaded, yet the maps tool doesn't appear to have the ability to select an image which already exists on the wiki.

My apologies to the creator of Map #208, but it appears that all users have the ability to delete everyone's maps.

Additionally, the deletion log entry only appears on the wiki where it was deleted, so it will be very difficult for normal users to work out who is deleting maps, since anyone can create a new account and a new wiki and then delete every single map.

Now I'm wondering if I'm pronouncing "wikipedia" and "wiki" "wrong" too.

Yes, as pronounced here:

I naturally assumed it was that word ^ + "uh"

XxOppiex200X, whenever you see a bug, you should report it.

You moved the pages, you cannot rename the accounts.

I agree that having it as a shared repository makes it less attractive to use.

AKA Notifications FYI.

Please paste the block message.

Nevermind, the autoblock is clearly visible here:

Yes, "Automatically block the last IP address used by this user" is checked by default. If it is unchecked, "autoblock disabled" is shown in the block log, which it is not:

Before you unblocked autoblock #3, it said "Autoblocked because your IP address has been recently used by "Road Runner1".", so there is no uncertainty that his IP was autoblocked.

Any word on welcome messages for IPs?

Currently, see Message Wall Greeting:452.

Perhaps "Pages in the 'Message Wall Greeting' namespace will be visible to all users, not just the creator" would be a better way of putting it.

One way I choose new admins is if they're often contacting existing admins to perform admin actions, then they probably need to be able to do those actions themselves. Specifically, if they're replacing a lot of images with better versions, I'll give them admin rights so they can delete the old files themselves.

Another thing I always take into consideration which is only briefly covered above, is whether they take part in discussions on forums and talk pages. It's all well and good for someone to have a thousand great edits in the main namespace, but admins should also be expected to take part in discussions. (Tagging active discussions helps.)

An extra point of advice I would add for anyone choosing new admins is to not be afraid to pick people who don't always agree with you. So long as everyone means well, and is willing to discuss the merits of their ideas, it's great to have different opinions, as it really helps work out what's "best" for the wiki.

Oh, and I also try to look out for people who are in different timezones, to help ensure there's always an admin awake somewhere in the world.

Usually, you can reword things without admin rights.

That would be a short blog post.

Q1. Are all administrative tasks being covered in a reasonable amount of time?
  • Yes: Then you have enough admins.
  • No: Appoint another admin.
Q2. Is there too many administrative tasks for the current admins to handle?
  • Yes: Appoint another admin.
  • No: Then you have enough admins.

Sounds messy.

If there are existing discussions regarding the updates and improvements, then you should definitely link him to them.

An icon linked to an image's file page will show upon hover in the lower right corner of image and video thumbnails.

Hopefully the image itself will continue to link to the file page instead of to the image.

The Chat right rail module will appear above the Videos module for logged-in users.

Excellent, it's hard to believe it's been three months already. Hopefully the images module will soon follow.

Were there any changes to table rendering this week, possibly related to infoboxes?

This class breaks infoboxes, thanks.

.image, .video {
  display: inline-block;

I fixed the problem immediately after posting here.

I can't seem to work out why this change was even made. I can't find a single case where .image is used which requires display: inline-block; and it is not already set by a more specific style.

For instance, all image and videos thumbnails are overridden by this style:

.article-thumb a.image-thumbnail, .article-thumb, .article-thumb img[data-image-key], .article-thumb img[data-video-key] {
display: block;

And images which aren't thumbs don't appear to need the class.

Do you have an example of why this style was added?

In future I think I'll just stick to using .452infoboxClassWhichWikiaIsUnlikelyToOverride

We are currently looking into some issues with image caches not updating in a timely manner.

The same issues that have been occurring without a fix for years, or new issues?

I'd love to help, as I've got over 100 late emails over the last few days - exactly what kind of details do you want?

Edit: My initial estimate was pretty good.

Out of 140 main namespace email notifications since the first 3 hour delay on the 6th, there are exactly 100 emails which were over 20 mins late. 89 of which were over an hour late.

  • There were also 5 between 10 and 20 mins, and 7 between 1 and 10 minutes.
  • The majority of late emails were between the 10th and 12th.
  • The longest delayed email was 13 hours late, on the 9th.
  • The last delayed emails were two on the 12th, which were both 1.5 hours late.

That sounds like completely "standard" broken behaviour of images on Wikia to me. As always, all current uses of the image has not updated from anywhere from a few hours to a week, but if you post an image of a different size, that new thumb is generated from the new file.

But if clearing your browser cache fixes the issue, then the issue is clearly your browser, and not anything to do with Wikia.

I was under the impression that the Welcome Tool problems were already known and being worked on. I will also send examples.

edit: soon, it may take me some time to compile them.

Edit: 107 examples sent.

With my examples, none of the users welcomed by User:Wikia and appearing as User:Wikia have had their user pages automatically created, so I have no examples of that, sorry.

edit: After looking in to this some more, it turns out that you only need look at Special:NewPages in order to see examples of this, on wikis with userpage creation enabled at least.

I was with you until this part: "However if the community does not know that you are behind these accounts, then you have just created a sock account..."

I disagree that disclosure of alternate accounts is always required.

I have a former account which is not at all related to this account, and I currently maintain a fully-disclosed bot account, as well as a completely-unrelated and undisclosed alternate account. (Perhaps two, I don't recall... and like 4 different testing accounts with "452" in the name.)

I agree that if you wish to edit on the same wiki you should not misrepresent yourself as a different person, and that is probably what you were talking about, but is not what you said.

One Computer can actually hold 2 accounts at the same time on the same chat but makes it so that only one of them can actually write and respond which can come as big help.


There is absolutely nothing to stop someone being in the chat as one user, then logging into a different account and joining the same chat in a different tab in the same browser. I do it all the time for testing with 2 accounts, but I could easily do it with 6 if I wanted.

If you said exactly what you wanted to say, then you are wrong.

I'm sorry that you were not able to understand the information I have given you. My point was that I use alternate accounts on different wikis without disclosing them, and that there is no reason for me to do so.

Here's a list of some of my accounts:

  • My original account, which I do not use anymore - no-one, including Wikia Staff, are aware of this account, and I've never even mentioned it until now. There is absolutely no reason for me to disclose it. Someone really, really, really smart with full access to all Wikia server logs over the last 10 years could potentially work it out, but I doubt it. Google and the NSA could probably tell you.
  • This account, which is my primary day-to-day account, completely unrelated to my real identity - apart from my email address, obviously. But that is unique to this account, and hopefully Wikia will never have a database leak which discloses it.
  • My bot account, which Wikia staff are aware of, and states me as the owner on each wiki where I use it - the funny story about this account is that I originally created it to "evade a block" in order to contact an admin.
  • A completely unrelated account for a completely unrelated community. There is absolutely no reason for me to disclose my connection with that account, either to you, or to any communities I am a part of. Wikia Staff can probably work out this account, although in the support requests I've submitted from that account, they've made no indication that they knew it was me, so I assume there is no automatic IP-check for support requests.
  • Several, at least 2, throw-away accounts which I use to ask questions on wikis which I do not want to be associated with this account. There is absolutely no reason for me to disclose my secondary interests to anyone. I occasionally just also post anonymously from a different IP for that purpose, but if I'm too lazy for that, I just create an account.
  • Several, probably 4, different testing accounts with "452" in the name. Such as "TestingNewUser452", which I created for reasons which aren't relevant. There is no explicit disclosure that it is my account, other than the user name.

I have never used any of these accounts to misrepresent my identity any more than I use the moniker "452" to "misrepresent my identity".

If you think that disclosure of unrelated accounts used on different wikis is always required, then please, report me to Wikia Staff using Special:Contact.

"I still stand by what I said."

What you said does not properly communicate what you meant.

You said: "However if the community does not know that you are behind these accounts, then you have just created a sock account..."

No community, or user, knows about the connection between my 452 account, my former account, my current unconnected alternate account, or any of my throwaway accounts.

What you said in your post applies to these accounts, even if that's not what you meant, which is why I'm bringing this up.

I said in my first reply, I said that I believed you meant: "if you wish to edit on the same wiki you should not misrepresent yourself as a different person", which you have now basically agreed with. (Technically, I don't think it's even absolutely required by the TOU to reveal your identity on the same wiki, so long as you're not acting maliciously, but I think that it's always better on the same wiki to reveal alternate accounts, to avoid potential accusations.)

I'm sorry if this sounds pedantic, but as I often use multiple accounts, I dislike when people do not understand what a sockpuppet is, and I do not want people reading your post to misinterpret it.

Here's a handy list which you could add to your post to help clarify it:

What is a Sock Account?
  • An alternate account used for malicious purposes, including harassment and vandalism.
  • An alternate account used to pretend to be a different user in a discussion about yourself.
  • An undisclosed alternate account used to evade a block.
What isn't a Sock Account?
  • Any disclosed alternate account
  • A bot account
  • A testing account
  • An undisclosed alternate account used on other wikis for unrelated purposes.

(There may be additional situations I forgot, sorry.)

I never said anything about wanting to use a width parameter with center|frame.

What does navigation="true" do?

(I'm hoping "kill the lightbox", but that's probably too optimistic.)

Will the "icon linked to an image's file page will show upon hover in the lower right corner of image and video thumbnails." mentioned 2 weeks ago be added this week?

Hopefully the image itself will continue to link to the file page instead of to the image.

Now that this change has actually taken place, I have confirmed that the image itself once again links to the full sized image instead of to the file page, unless link= is specified. :(

edit: however, the change does not appear to have taken place on Commmunity Central yet.

test thumb

See also: Help:Message_Wall

I'm still not seeing this icon on Community Central.


Confirmed, thanks.

This is a table

This is an image inside a table which still has an (i) when hovering

More specifically, the (i) does not appear on images width width less than 100px.

horizontal example (100px width)

horizontal example (99px width)

vertical example (100px width)

vertical example (99px width)

That's a great idea. I'm going to use this on a light-themed wiki since it's ultra HD, as you mentioned.

I will be glad when it is fixed.

Take a look at the thread history for welcome messages: "a Wikia contributor created this thread"

Thankyou Kirkburn and Wikia Staff, for continuing to fix various chat problems, and for keeping us updated, despite the ungrateful few. If I were you, I would have just disabled it completely and said "Sorry folks, the beta is over for now" long ago.

The chat has been far more stable over the last week, and I haven't really noticed any problems until just now:

I just saw my message being said by someone else, then the chat crashed immediately afterwards, haha.

An explanation of what is happening in the chat. (I've only noticed this behaviour over the last 24 hours.)

(I have already reported this via Special:Contact, but I am posting it here so that others can better understand what is occurring.)

  • I was in Chat A, with regulars User2 and User3.
  • I saw new users UserC and UserD join.
  • I said hello to each of them individually.
  • Both of my messages appeared as if UserC said them.
  • I saw UserD reply, confused.
  • Then I typed "uh oh" and it looked like UserC said it.
  • Then the chat crashes, giving me the message "you have connected on another browser"
  • User2 and User3 never saw UserC or UserD, or any of the messages after they joined. But they did see the chat crash.

Meanwhile, in Chat B:

  • UserC and UserD were sitting there, minding their own business.
  • Suddenly, UserC randomly says hello to UserC and UserD individually
  • UserD reponds to UserC, confused why he's suddenly saying hello.
  • UserC then randomly says "uh oh"
  • (The chat never crashes for Chat B.)


  • If you see people join, then your messages appear as them: Your chat session has been attached to someone else's session, and your messages are appearing in their chat. No-one in your home chat can see this.
  • If someone else's messages start appearing as you: someone else's chat session has been attached to your chat session. Everyone else can see this, including the person typing as you.
  • If you see someone you know saying odd things: someone else's chat session has been attached to your friend's chat session: they can see their messages show up as your friend, and they can see what you type.

If ANY of the above happens, I suggest saying:

  • "Hi, I'm User:Bob from the Bob's Wiki Chat, and the chat appears to have glitched, refresh the chat and all should be back to normal." - which will help the other people present understand what is going on.

I am now seeing "navigation=true" being added automatically (and it being impossible to remove it), but when will the script adding navigation=true to existing navigation galleries take place?

The "Today's views" email also reports 0.

I guess Wikia just isn't cool anymore.

Without the FCC, who would stop the corporations doing whatever they like?

I question the need for the FCC these days.

So, you would rather the corporations just do whatever they like?

Since some people think the FCC is the enemy:

The FCC, and other government regulatory bodies, are all that protects individuals from being trampled by corporations.

Corporations spend millions of dollars lobby the FCC, and politicians, to allow them to be increasingly unfair towards consumers. The FCC didn't create the legislation, the Corporations did, via the politicians they have purchased.

Corporations are your enemy, and want to steal all of your money, and provide the least amount of service. The FCC is there to stop them from doing that.

However, the FCC needs guidance, and that comes in the form of petitions, emails, comments, and calls to tell them what you want.

Read also:

I definitely agree.

Given that one of the only reasons I've ever found in favour of using interwiki links has been "Shorter wikitext", it would appear that keeping page-size low is a goal on some wikis.

As with all metrics, deliberately aiming high or low can be easily achieved.

  • Number of articles? It's easy to create pages for air and water.
    • I've seen some wikis duplicate entire wikipedia articles, simply because the subject is mentioned once.
  • Page size? It's easy to not use templates, include completely irrelevant information... or copy wikipedia articles.
    • Unfortunately, I'm in favour of adding full transcripts, or at least a lot of quotes, which has the side effect of massively increasing the raw page size. I wasn't trying to inflate the average, but I did.
  • Raw edits? It's easy to make lots of "valuable" small edits instead of 1 large quality edit.
    • When looking for admins, anyone who says "I've got 100 edits!" when they've only edited 5 articles... shouldn't be an admin any time soon.

Still, metrics are always interesting to look at.

{{#expr:{{NUMBEROFEDITS:R}} / {{NUMBEROFPAGES:R}} round 2}} will give the average edits per page, if anyone is interested in that.

edit: Of course, that's "all pages", not just content pages. Unfortunately, I don't know of any {{NUMBEROFEDITSINNAMESPACE:R|0}}.

{{#expr:{{NUMBEROFEDITS:R}} / {{NUMBEROFARTICLES:R}} round 2}} might be closer, but will higher than it should be.

I volunteer myself to test this.

Please first block me on a whatever wiki you would like to test on, then give me bureaucrat rights on a the same wiki.

Once you have done that, I will unblock myself and then immediately remove the rights. (If this is a trick and I refuse, Staff can remove those same rights.)

I have successfully unblocked myself, editing my userpage, and removed my rights.

3cooldog92 is correct, ... but so is IvyLover.

Without rights, says:

"The action you have requested is limited to users in one of the groups: Administrators, Bureaucrats, Wikia Staff, VSTF, Wikia Helpers, adminmentor."

Emphasis mine.

There is not much that Bureaucrats can do without admin rights, but Special:ListGroupRights shows the full list, which includes "Block other users from editing (block)" and "Unblock themselves (unblockself)"

However, we just tested again, this time I was only given Bureaucrat and not Admin, and while I was able to remove the block for "452", the autoblock is indeed still active, and I cannot remove seem to remove it.

"You cannot block or unblock other users, because you are yourself blocked"

I also cannot access Special:UserRights/452:

"Autoblocked because your IP address has been recently used by "452"."

Like last time, I went straight to "Special:Unblock/452", and as far as I can tell, the only difference between the two tests was that I was not an admin the second time.

edit: I've sent in the results of this test via Special:Contact - I highly doubt this is intended behaviour.

I've noticed some problems with autoblock expiration recently, perhaps this is related.

edit: Or maybe not.

Looking a little closer at Special:ListGroupRights shows that Admins and not Bureaucrats have the "ipblock-exempt" right.

Until the issue is fixed, you can use Special:Export and Special:Import to make changes.

Thanks, that makes it much easier!

About 6 months ago, I was given a 1 year block on a wiki with 11 pages, and about a month ago I successfully adopted a wiki, even though the block is still active.

So I'm sure that they probably look into each block to see if it has merit.

Fun Fact

If someone copies your content onto another wiki, and you edit that wiki to add the required licensing information, they are allowed to block you on that Wikia.

I believe that blocks for adding licensing - or for any other TOU compliance - should be declared invalid.

I also believe that blocking on one wiki due to the actions on another wiki should also not be allowed. (Such as when if you block someone for a clear reason, and they respond by blocking you on another wiki for no reason.)

For the record, The Great Lord David, that comment was meant to be an example of something that Wikia Staff permit, but is unfair, not an example of something you should do.

I think SemanticDrifter may have already written a blog on that topic.

edit: He didn't specifically address "What do you do if you get blocked for doing it, or threatened with a block", but he did mention using Special:Contact "If the friendly approach fails", so that's covered.

  • 2014-09-16 13:52:13 - PageID: 733080 - User blog comment:Thegoldnguy/A Wikia Star/Bureaucrat is abusing his power/@comment-452-20140916135213 - raw
  • Wikia Stars have no powers
  • There are no global chat rules
  • If there are no rules, then there is no such thing as breaking the rules.
  • There is no rule against kicking someone from the chat for no reason
    • I once asked a Wikia Star and VSTF member whether there was any rule forbidding me from banning him, he told me no, so I banned him. He apparently complained to Wikia Staff, but I didn't hear any more about it.
  • Staff do not care what happens in any chat - because the chat is not the wiki: The chat is "play time".
  • Staff do not make decisions based upon screenshots (unless they ask you for one first)
  • Sannse has written multiple blog posts regarding what to do about problems with admins.
  • If you use Special:Contact, and the wiki has no established rules, and no community discussion outside of the chat, they will do nothing.

When you say "Ratted us out to the adminship", what exactly are you talking about? If you were breaking any rules, then reporting you sounds fair.

If you have a problem with an admin, start a discussion about it on that wiki.

  • I propose that you suggest a set of chat rules be created, that will govern everyone's conduct, including the admin.
  • If the wiki does not have any other formal rules to govern user and admin conduct, I suggest you also propose those too.

Edit: Oh, and the fact that he has disabled chat is a good thing: Now, nothing can happen "off the record", and if he continues his bad behaviour in public, you will have real evidence of it, instead of just screenshots.

Wikia Staff have replied to tell me that they do not think this is something they will fix.

I suggest that anyone else who thinks that this is a problem also send in your feedback.

So, you were discussing "rebelling" in the chat, off the record, out of public view, and behind everyone's backs?

Then he did the right thing to close the chat.

Discussions regarding the removal of admins should occur in public so that everyone has a chance to give their input. It is also more mature than discussing it out of sight.

If you had had the discussion in public, then he would not be allowed to remove it, nor block your for participating in it. Is there any evidence on the wiki other than chat screenshots?

To make it easy, here they are:

Once informed, Wikia Staff will undelete both of those pages and all comments.

For reference, you can view all deletion via

It looks like there has been a lot of other deletions recently. If any of these were useful content, the next admin will be able to undelete them.

As JosephHawk mentioned: Special:Contact

Have you tried purging, or null-editing, the articles?

One thing that has worked for me in the past is changing the size of the images in the article.

This causes a new thumbnail to be generated using the new image.

I notice that the deletion log is growing. Apparently he is playing bailiff at his own "trial".

The "Does_Titan_deserve_his_adminship%3F" blog has still not been restored, and the other blog has been restored without comments enabled.

I also make much use of sound files, and have just null edited several pages using them, but I am not seeing any changes.

It is therefore likely that this is a problem with the Fallout wiki CSS - however, after pressing the Random Page button 30 times, I have been unable to find any pages using audio files, so I cannot confirm this.

Hey, I just thought of something else for the "What is a Sock Account?" list:

  • Claiming a secondary account is not your own.

While it's fine to have an undisclosed secondary account, making false claims that the secondary account is not yours isn't cool - even if it isn't being used for malicious purposes.

Yes, I agree.

So "A secondary account used to pretend to be a different user in various discussions, contests, ect." could be reworded to just "A secondary account used to pretend to be a different user" to cover both.

Wikia Staff have said recently that discussions such as this must take place on that wiki.

The reason behind this is so that everyone on that wiki can see that the discussion is occurring, and have a chance to have their say.

‏Speaking of RTL and LTR, is there any word on getting the &lrm; and &rlm; characters removed from links on special pages so they're not inserted when copied? Edit: or simply stripped when inserted as characters?

For those who do not know what I'm talking about:

  • Go to Special:RecentChanges and copy any link, such as "Help:Welcome tool‎" < Or just copy this
  • Paste it and use the keyboard arrows to progress through each character, and notice that it takes two arrow presses to get past the ".

Pasting that link into gives the result: "Help:Welcome tool&lrm;" - revealing that there is an invisible character which is added to pages whenever anyone copies a link from most special pages.

Special:WantedPages has both a lrm and a rlm: "Wikia IRC channels‏‎ (16,013 links)" is "Wikia IRC channels&rlm;&lrm; (16,013 links)"

Edit: Or, you can simply inspect the source of the special pages to see them displayed there as "&rlm; and &lrm;" - but copy/pasting to test is helpful to prove that they're inserted when copy/pasting links into an article.

I believe I already reported this, possibly years ago (edit: I apparently first discovered this was occurring on September 20, 2012), I'm only asking for an update. I added the details because I assumed that others wouldn't know what I was talking about.

I just tested in firefox, and I'm seeing the same thing there, both in the source and when pasted.

This is what I see:

edit: A Community Central admin has decided to delete these example images, then restore them, then delete them again, restore them, then delete them again:

You mean something like has?

On Mediawiki:Wikia.css,

Add something like this:

  cursor:url('Mouse.png'), auto;
  cursor: url('Mousehover.png'), auto;
  cursor: url('Mousehover.png'), auto;
  cursor: url('Mousehover.png'), auto;
  cursor: url('Mousehover.png'), auto;
(Copied from CC-BY-SA)

Of course, you will need to change those urls instead of using the cursors from the disney wiki.

Yes, there are a number of glitches which have been around for years. I suggest that you outline each specific one, so that people know what you're talking about.

I'm personally familiar with the page counter glitch.

Although "all pages" are supposed to be counted, with or without commas, adding a comma to a page without one temporarily increases the page count, as does removing all commas from a page.

Once per day, the page count is resynced with the actual page count, (although not at the same time as the special-pages cache update)

Disambiguation pages are also counted towards the page count, and moving them out of the main namespace does not immediately reduce the page count, although it is also later synced. (or something like that, I forget the specifics)

There are also some cases of "ghost pages" counting towards the page count.

Both Special:ShortPages and Special:LongPages are good ways to confirm the exact number of pages on a wiki. (...Unless there are non-main namespaces marked as "content", such as on Community Central. Here, those pages only show 53 pages, although the page count counts all blogs and forums posts.)

One of my personal "favourite" glitches is that redlinks in threads which have been "deleted" using the "delete" menu option still appear on WantedPages, as well as in database dumps, and are generally still accessible if you know the actual page URL. Obviously, deleting threads the "old fashioned" way sidesteps this.

"Unfortunately, the parameters of this study don't match your background, but we hope that you will participate in future studies that might be a better fit."


That depends of the goal of the research.

If the goal of the research is to show Wikia's advertisers that Wikia's audience spends money, then it is in Wikia's best interest for everyone who takes the survey to say they spend money, even if they do not.

Saying "I'm sorry, you said you spend $0, therefore you are not eligible to win an iPad mini" all but ensures that those people will go retry and say they spend money.


To put it another way: Wikia knows what the advertisers want to hear, so they only give the chance to win an iPad mini to people who give the answers they want.

It seems like overkill.

If a user is causing a problem, and acting suspiciously like another user who has previously caused problems, then it's time to contact Staff.

User acting normal User acting like another user

Not causing any problems

Do nothing Do nothing

Causing a problem

Block Block + contact staff.

I suggest redirecting the userpages of each sock to his "original" account.

Then you can use WhatLinksHere to see the list, without building him a shrine.

We will drop support for the old 'Video:' namespace (from before videos moved to the File namespace).

I have a funny feeling that this took effect last week.

AFAIK, those old cached template links still appear on WhatLinksHere.

Energy X, could you provide an example?

Maybe I'm remembering it wrong, but I seem to remember that the "identical headings" issue only occurred when editing one of those sections, and then being returned to the wrong section.

Like here: Community_Central:Sandbox?action=edit&section=3

Also: Community_Central:Sandbox#Game_2 < this is the link for "Trivia > Game", but it leads to "Quotes > Game 2"

edit: These Sandbox tests are from December 5, 2012. If there were other identical header problems, then I guess they're fixed

I notice that

Was there a mention of it happening in advance that I missed?

Bob has a hammer. It's a great hammer, and Bob uses it all the time.

One day, Bob's friend Tom decides to improve Bob's hammer by replacing the hammer head with a spade. Tom tells Bob that now the hammer can be used for hammering and for digging, and that Bob should just accept the change.

The hammer is slightly less useful at hammering, but can still be used to get the job done. While it can also be used for digging, Bob doesn't dig that often. But he keeps using the hammer/spade for hammering, because it's the best tool available.

Sometime later, Tom decides to improve Bob's hammer again by replacing the handle with a rope. Now the "hammer" can be used digging and for... stuff ropes are used for.

While Bob's tool now has a larger variety of uses, it's now less useful to Bob, so Bob rarely uses his hammer anymore, and will probably go find a replacement for his current hammer.

This analogy isn't perfect, largely since Wikia owns the hammer in question and can do what they like with it.

But I'm Bob, and Wikia was very useful to me when I first started using it.

But every second time you "improve" Wikia, it becomes less useful to me and thousands of other people who liked the hammer how it was.

Edit: If you want to update your hammer to attract people who like spades and ropes, that's fine, but don't expect the people who starting using the hammer because it was a hammer to accept the change.


  • The notifications section is now less useful, since it is now inside the menu.
  • The header takes up additional screen real-estate, reducing my productivity - both due to the increased height, and being "fixed" and present while scrolling.
  • It is ugly, and does not follow the site style. (Although I notice that the search button on the Destiny wiki is a different colour.)

That's a really good point Tupka217,

I've confirmed it also occurs when clicking a section link, or link in the TOC: Help:Preferences#Email

Here's an example screenshot for anyone who misses the point:

A demonstration of global navigation overlap.png

Yeah, the circle seems a bit silly considering that transparency isn't possible in avatars.

Thanks, but I've already done this and more: User:452/global.css‎‎

Some CSS which others may find useful to improve the look of the header. Add these to Special:MyPage/global.css.

Each of these lines can be used independently, except the final 2 lines.

/* stop the header scrolling */
.global-navigation { position: relative; }
/* height of user menu items */
.AccountNavigation .user-menu > li { height: 2em; }
/* height of notification menu items */
#GlobalNavigationWallNotifications .notification { line-height: inherit; padding: 0.3em 0; }
/* hide redundant notification menu header */
#GlobalNavigationWallNotifications .notifications-header { display: none; }
/* remove unnecessary borders */
.global-navigation * { border: none; }
/* The next 2 lines make the header background match the page width */
.global-navigation { border: none; background:none; }
.global-navigation .page-width { background:white; }

See Help:JavaScript_and_CSS_Cheatsheet for more information about using CSS.

(I've only tested these in Chrome, but they should work in Firefox.)

Short answer: No.

Long answer

The accounts on are there are not connected to accounts on

It is possible to create accounts on and login there, but it is not possible to do a password reset from there.

If you keep the same email address, you can view all of your past requests by logging into

If you change your email address, your next support ticket will contain the new information, and not be connected to previous support tickets. (But Staff may be able to search by Wikia username)

If you have your account renamed on Wikia, the name associated with the account is not updated, unless you change your Wikia email address. (Because it will create a new with the new email address and username.)

However, Staff can CC other users on support tickets, so if you change your email address, then use Special:Contact to tell them "Hi, this is UltimateMegaGeo again, please CC this email address for ticket #1234" then they will probably do so.

Or, you could simply resend the request after changing your email address.

I believe the answer will be "no".

Allowing communities to opt-out would be counter to the stated purpose:

we updated the look and feel of the navigation to be more consistent across all communities, screens, and devices.

I think it's highly likely that they will not even allow the colours to be changed.

But, as always, I hope I'm wrong.

The fact that the wikis are hosted by Wikia is irrelevant to most of our readership.

Which is exactly why they are:

  • Using the term at all
  • Making the term as visible as possible

Although I disagree, I'm going to answer that by quoting:

all changes to global navigation should be confined to personal CSS/JS.

("color change" falls within the set of "all changes")

Which customizations did fluid layout destroy?

Most wikis with customisations had to make adjustments to accommodate fluid width. While Wikia could have made the transition easier by allowing individual users to toggle fluid width on their wiki, they did allow people to set up test wikis with fluid layout in order to make these changes in advance of the full rollout.

  • under "XXX pages on this wiki" and search bar, there is a line, which can be replaced by image.

As far as I remember, the search bar has always been part of the right rail, so the line under the page header has never extended under the search bar.

Could you please show me an example? I do not understand why a fixed-width "line" image was used in the first place, and would like to help fix this issue.

  • Another: local navigation header image:

I'm unsure what "local navigation header" refers to. Could you also please show me an example of this? I would also like to help fix this issue.

  • Tables on pages: wider screens end up having big empty spaces on the left and right of the tables (that's if the table was intended to take the whole width and no text on it's sides).

Solution: style="width:100%", or a class to do the same.

They will look, and be, absent.

You do not have, and have never had, a user page:

The new header is not showing at all on Pokemon and American Horror Story wikis.

Reading the comments would help.

I suspected the border might look something like that.

With all of those tables, I recommend using galleries instead.