Fandom

Community Central

452

8,322 Edits since joining this wiki
March 19, 2011

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

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.


1451 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: 5 years later, in 2016, 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, 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.


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. :)


Answer: http://community.wikia.com/index.php?title=Forum:Most_visited_pages_gone%3F


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 Fonttest-consolas

  • 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: http://community.wikia.com/index.php?title=Forum:Removing_categories_in_source_mode_with_wide_edit_box&action=edit

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.


+1


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:User452/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.

http://24.wikia.com/wiki/File:CofellAttack.jpg?action=edit - shows a message, but viewing the page http://24.wikia.com/wiki/File:CofellAttack.jpg 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:

Add

http://www.google.com/search?q=%s+site:wikia.com&btnI=I'm+Feeling+Lucky

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 http://community.wikia.com/wiki/Special:WantedPages 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."

http://community.wikia.com/wiki/User_blog:Daniel_Baran/Search_Developments:_Big_Picture

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

Amen.


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.


Cool.

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 community.wikia.com 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.
WantedPages

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:user452/Titles works as expected, redirecting to archive of that page
  • Example 2: User_talk:user452/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:user452/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

Tabindexes

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 http://community.wikia.com/wiki/Special:Chat


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.


Agreed.


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.


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 http://runescape.wikia.com 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.

Excellent!

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 http://runescape.wikia.com 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


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


Why?


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?

edit:

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


http://dev.wikia.com/wiki/Repository

http://github.com/Wikia

also: http://dev.wikia.com/wiki/User_blog%3ARelwell%2FWikia_is_moving_to_GitHub%21


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.


Testing.

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.


Topics!

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: http://shipsandthings.wikia.com/wiki/Special:WikiFeatures


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:

http://community.wikia.com/wiki/User_blog_comment:BertH/New_Forums_now_available_in_Labs/@comment-Kerry_Stapleton-20121203193640?permalink=462615#comm-462615


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

touché


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: http://muppet.wikia.com/wiki/Category:Active_Talk_Pages (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 http://connect.facebook.net/en_US/all.js 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 facebook.com 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 http://connect.facebook.net/en_US/all.js 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 : http://community.wikia.com/wiki/Special:Forum?uselang=qqx

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 https://support.wikia-inc.com/registration 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 https://support.wikia-inc.com/anonymous_requests/new (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.


+1

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?

Yes.


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: http://support.apple.com/kb/dl1531


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.


http://community.wikia.com/index.php?title=Special%3AAllMessages&prefix=User-identity-box-group


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?


*faceplam*

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?


thirded.

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.


Crazy sam10, I noticed the 359px too. :(

But hey, at least the entire filename isn't gibberish!


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?


thanks


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 brieflypopularin2012wiki.wikia.com 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 community.wikia.com/wiki/Special:Contributions/Message_Wall:452 instead of community.wikia.com/wiki/Message_Wall:452

Thanks!


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


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 http://lego.wikia.com/wiki/Special:Contributions/75.108.237.48 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: http://specops.wikia.com/wiki/User_blog:SilenceInTheLibrary/Update_and_Alert_from_Wikia#File_Page_Redesign

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?


Thanks.

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. :)


Special:Top/most_visited


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 youtube.com, 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:

{{youtube|2Lh87pPES1k}}

with Template:youtube containing:

<youtube>{{{1}}}</youtube>

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 http://www.wikia.com/WAM?verticalId=2

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

http://business.ftc.gov/documents/Complying-with-COPPA-Frequently-Asked-Questions

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

http://business.ftc.gov/documents/Complying-with-COPPA-Frequently-Asked-Questions

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.

edit:

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 http://dev.wikia.com/wiki/ShowHide and point out that it's deprecated, but first went to check http://sims.wikia.com/wiki/MediaWiki:Common.js to make sure you were indeed using it, but you're not.

Button.style.width = "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.

http://community.wikia.com/wiki/User_blog:Sannse/December_New_Look_Update

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

Hooray!

"Editing or highlighting a forum thread could cause a user to unintentionally unfollow the thread."

Hooray!

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

__TOC__

=test 1=
1
==test 2==
2
=test 3=
3
==test 4==
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.

Hooray!

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.

Examples:

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.

body.skin-oasis {
 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:

body.background-dynamic.skin-oasis:after, body.background-dynamic.skin-oasis:before {
background-image:none;
}
.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


As Penguin-Pal said, you need to add !important, here:

background-image: url("CherylWall.jpg") !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: http://en.wikipedia.org/wiki/Charles_Darwin‎


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 body.background-dynamic.skin-oasis:after and body.background-dynamic.skin-oasis:before), 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>mark</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"] {
   display:none;
 }

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

Now:

<figure class="article-thumb tright" style="width: 280px">

Previously:

<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 http://d-fragments.wikia.com/wiki/Naganuma


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: http://201405test.wikia.com/


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: http://www.mediawiki.org/wiki/Manual:$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 108.7.75.133 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.

http://www.wikia.com/Wiki_Creation_Policy


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


Acer4666:

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.


http://community.wikia.com/wiki/Help:Galleries,_Slideshows,_and_Sliders/wikitext#Live_example_2

Chevron kittens

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.

Excellent.


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: http://community.wikia.com/Special:Preferences 

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


VE-ClassicEditor

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: http://www.youtube.com/watch?v=jyiH9iAaUqU

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: http://jacktheguy5.wikia.com/wiki/Special:BlockList


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: http://jacktheguy5.wikia.com/wiki/Special:Log/block

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 a.video-thumbnail, .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.

False.

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.

Example1

test thumb


See also: Help:Message_Wall


I'm still not seeing this icon on Community Central.

Example1

Example.


Confirmed, thanks.

This is a table
Example1

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

horizontal example (100px width)

Example1

horizontal example (99px width)

Nice-funny-quotes-thoughts-

vertical example (100px width)

Nice-funny-quotes-thoughts-

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 127.0.0.1 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.)

So,

  • 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: http://www.fcc.gov/openinternet


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, http://disney-junior-sheriff-callies-wild-west.wikia.com/wiki/Special:Unblock/452 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 - User blog comment:Thegoldnguy/A Wikia Star/Bureaucrat is abusing his power/@comment-452-20140916135213
  • 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 http://godzilla.wikia.com/wiki/Special:Log/delete

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 https://mothereff.in/html-entities 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 http://disney.wikia.com has?

On Mediawiki:Wikia.css,

Add something like this:

body{
  cursor:url('http://images.wikia.com/disney/images/5/5c/Mouse.png'), auto;
}
a:link{
  cursor: url('http://images.wikia.com/disney/images/b/b4/Mousehover.png'), auto;
}
a:visited{
  cursor: url('http://images.wikia.com/disney/images/b/b4/Mousehover.png'), auto;
}
a:hover{
  cursor: url('http://images.wikia.com/disney/images/b/b4/Mousehover.png'), auto;
}
a:active{
  cursor: url('http://images.wikia.com/disney/images/b/b4/Mousehover.png'), auto;
}
(Copied from http://disney.wikia.com/wiki/mediawiki:wikia.css 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."

Ha.


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.

Edit:

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.


Specifically:

  • 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

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 http://support.wikia-inc.com are there are not connected to accounts on http://wikia.com

It is possible to create accounts on http://support.wikia-inc.com 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 support.wikia-inc.com

If you change your wikia.com 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 support.wikia-inc.com account is not updated, unless you change your Wikia email address. (Because it will create a new support.wikia-inc.com 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.

  • Notice how the Gallery on the Terra_Formars_TV page changes the number of items on each row as you expand the page?
  • You can use CSS to change the background, borders and margins to make the new gallery looks like the old table - except that the width won't be fixed.
  • Here is a similar problem: Thread:683869. It's not exactly the same, but it has the basics.

I also use a background image in the search box - since there are so many wikis which do, hopefully it will be allowed.


Btw, "code" is like "flour":

  • "a cup of flour" -> "a line of code"
  • "some flour" - > "some code"
  • Saying "a flour" is meaningless.

Special:CloseMyAccount


1. Sorry, I shouldn't have said "ghost pages", I mean pages which are inaccessible, and appear to start with colon. I could never determine their cause.

2. I'm saying that the page counter increases when you add a comma to a page with none, and decreases when you remove all commas from a page, then is resynced to become accurate once per day.

3. Special:ShortPages and Special:LongPages show the exact same information in reverse orders.


I pretty much exclusively use /general for all my support tickets, and I don't remember ever having been asked to use a specific form, so I don't think it really matters.

I think the main purpose of each different form is to ensure they get the information they need - which I tend to provide anyway.

I imagine that the tagging of each separate page might help speed up the ticket triage to assign the ticket to the appropriate staff member. But using a concise subject line probably has the same effect.

I doubt using /bug it speeds it up much, as I've received the copy/pasted "we apologise for the delay blah blah" paragraph many times, without once being told "For a faster reply, be sure to use the /bug page", etc.

BTW, the "Browser type and version" cited in the post is kinda redundant, as that information is automatically recorded and displayed at the bottom of the ticket, along with

  • Username
  • Email
  • Link to userpage on the current wiki
  • Wiki ID
  • Wiki language
  • IP address
  • User ID
  • User language
  • A/B tests
  • Links to Special:LookUpUser

Thank you, I haven't personally seen that happen in a while, so it's good to know that this is still happening.

Unfortunately, Wikia Staff think that the chat problems have been fixed, so be sure to report each and every chat crash via Special:Contact so they know about the ongoing problems.


That thread has nothing to do with the block.

This is the thread regarding the block. The IP was blocked for continually leaving me messages regarding an account issue, despite being told multiple times to use Special:Contact.

Wikia Staff have now removed the block, as I requested that they do once the issue was resolved. (XPanettaa had apparently not linked them to the thread or block log, and not told them that I had requested they remove the block.)


Thanks Sannse, I couldn't have said it better myself! In fact, there are several points in this blog which hadn't even occurred to me, particularly the part about "even if you think they 'deserve' it, it makes the wiki look bad".


Some extra advice:

Obviously, cases of clear vandalism must be stopped ASAP, but for other issues, leave them a message about it, and use a temporary block to halt their edits if they continue without replying, but don't block access to their talk page.
If the problem user is communicative, I think it's important not to block or close discussions too soon. Admins should always be willing to discuss issues, consider different viewpoints, clarify the reasons behind rules which others may not understand, and generally give people a chance - even if you don't particularly "like" what the other user is doing. Especially if they have questions, as I think that admins should always answer questions which relate to the wiki, or their behaviour. (edit: In fact, this is generally true of all users, when asked about something which applies to them.)

  • I recently made the mistake of blocking someone for an hour and also blocking their talk page replies, after that hour was up, the user was quite vocal about not being able to communicate with me during that time, and it would have saved me an additional hour of drama if I hadn't done that.

Everyone gets frustrated sometimes, but you can always walk away for a while. It's important to remember that there's no need to reply straight away if things get heated. You can always just go play with your pets or watch TV for a while and come back to the conversation later. Personally, I cook something, then come back on a full stomach in a better mood.

Regarding being insulted: If someone is using curse words indirectly, I simply pretend those words aren't there. But if they direct them at myself or other users, I'll give them one warning to watch their language before enforcing a "time-out".

One extra piece of advice for admins, or any user, who might one day want to become admins elsewhere: Even if everyone on your current wiki thinks that "swearing at vandals" is okay, other wikis might not agree, and your behaviour with vandals might stop you gaining admin rights elsewhere in future.


+1 to everything Imamadmad has said.

BTW, the way to shorten the "how to add a template" help text is to add "Step 0: First, disable the Visual Editor." :P


Was it intended that all .js edit pages now do not use any site or user CSS?


edit: I'm sorry I replied to this, I hadn't realised that TheSitcomLover said the exact same thing two days ago


I think that this is a really good suggestion.

Since logged in users can use CSS to remove it anyway, I don't see the harm in adding it a show/hide toggle.

However, for branding purposes, Wikia want to make sure you see the Wikia logo as often as possible, so it's unlikely that this will happen.

Additionally, Wikia Staff already do not allow a right-rail toggle, so wikis will not be able to add a toggle themselves.


Depends on how dead you want it.

Multiple people have already posted some CSS examples in the comments: such as myself.

Or there is User:452/global.css which goes a little further.


re: 999+ list count problem - what about lists on non-special pages?


Since the cause is the same, I don't see any reason why I wouldn't be seeing an issue there as well.

The cause in both cases is:

.WikiaArticle ul, .WikiaArticle ol {
  margin: .4em 0 .5em 2.5em;
}

The fix indeed targets only special-page lists: http://report.wikia.net/classchange/index.php/diff/26

Although I didn't mention non-special pages specifically, I think the report I made on April 8th covers it, but here's a new one.


Thank you for posting that Deutschlandkaiser.

To give that response a little more context, what exactly did you ask them?


In the specific case of "I WILL KILL YOUR ENTIRE FAMILY GO TO HELL YOU SON OF A B*TCH 9-YEAR-OLD INBRED!!!!!", I agree that warnings and block notifications are not necessary, and that removing the message with a reason, and blocking with a reason is sufficient.

However, if there was a discussion leading up to that comment, it may be useful to end the thread with a "This user has been blocked for this comment." message, so that anyone reading the discussion in future will know the outcome. (Be it them, you, other admins, other users, or Wikia Staff)

edit: I only mean a factual, neutral, informative message, and not a "I'm blocking you now, bye bye." type message.


BTW: https://en.wikipedia.org/wiki/Flaming_(Internet)


It is my opinion that any admin who issues an infinite block is a poor admin who is not mature or responsible enough to fulfil their role. The blocklist is not score board, either for vandals or for blocking admins.

I have been an admin for 3 years, and have found excessively long blocks to be completely unnecessary, especially for a first time offender, and I do not think it is ever necessary to give an infinite block.

The majority of the time when an obvious vandal is blocked for 1 day, they never ever return. If they do vandalise again after a day, you block them for a week, then a month, as necessary. But this rarely happens.

Now, I'm not saying that I've never encountered a persistent vandal - I'm currently blocking one who constantly returns after month blocks from a variety of different IP addresses to add nonsense about My Little Pony. So I've blocked all of his IP ranges until 2015, hopefully he will have grown out of it by then. If he celebrates the new year by repeating his past pony nonsense, then I will re-block all the same IP ranges until 2016, with the block reason "Extended range block for returning vandal".

Although just blocking him "indefinitely" would probably be worth it - there is no need to do so when a year block will suffice.

Blocks are not "punishment", they are "preventative measures", and should be used responsibly. It is not "preventative" to indefinitely block someone who wasn't going to return anyway.


The word "deserves" is indicative of "punishment".

Blocking is not supposed to be for punishment.

The purpose of an admin is not "to give people what they deserve", and admins should not be judging what people "deserve".

edit: Of course, admins should block people in order to prevent vandalism, and the posting of pornography. But this is to protect the wiki, not because they deserve it.


I didn't know there was a crowd, I came up "infinite blocks without justification are never justified" on my own.

it's safe to assume with most vandals that their sole purpose is to harm the wiki. But it is simply not necessary to use extended blocks for most vandals.

My opinion is based on the fact that the majority of vandals never return after a short block, and that in 3 years I've only seen 2 vandals who remained active for longer than 6 months. Do the majority of vandals on the SpongeBob wiki always return? Even after being blocked for a year?

My main concern is blocking indefinitely for a first offence. In the case of "pornography on a children's wiki", you could still block for a month, or a year, for the first offence, then indefinitely for a second offence, after it has been "proven necessary". If they're persistent enough to return after being blocked for a month, or a year, they're probably just going to go to starbucks and sign up for a new account before the block is over anyway.

When I became an admin, I removed all the infinite blocks the previous admins had made. None of those users ever returned. I highly encourage everyone to remove any blocks which have been in place for longer than a year. (Unless the block log on the unblock screen shows a history of persistence, obviously)

A real life comparison would be the difference between saying "Get out of my store" and "You're barred from my store for life, if I ever see you again I'm calling the police". They both get the job done, but one is unnecessary overkill for a first offence.


In the specific case of unacceptable usernames, such as "User:SpongeBob_Wiki", here's how I deal with it:

  1. Leave them a message telling them that the username is not appropriate and ask them to choose another.
  2. Block them for a month if they edit using it, without blocking the IP.

For the record, I have encountered a user attempting to use the name of the wiki, this is how I dealt with it, and it wasn't an ongoing problem.

edit: More specifically, when they signed up, they made two edits, and I said:

  • "Your username is inappropriate, as it may cause confusion to new users. Please use a more individual username."

I didn't block them, and they didn't edit again until a month later, at which time I blocked them for 1 year and said:

  • "As I stated almost a month ago, your username is inappropriate - please either use Special:Contact to ask for your username to be changed or simply sign up with a new username."

That was 3 years ago, so the block hasn't been active for the last 2 years, and they never returned under that username. I have no idea if they signed up for a different one.


I would love to see some real official statistics on this. (I land on the front page, and have a link to RecentChanges in my bottom toolbar, and the "On the Wiki" tab.)


Now that the navigation is back to how it was previously, I notice that http://disney.wikia.com/ once again has a background image on the top navigation.

Could you please confirm whether adding a background image to the current top navigation bar is permitted?


Yes, I know, that's what they said.

However, not all of them have a header with a custom background image, which is why I am asking about the disney wiki.


It's also largely created by bots.


And even worse: when an actual person tries to improve it, the bots may re-add false information later.

It has been years, so I forget exactly what I tried to do, either renaming a misnamed track, or fixing an incorrect category or something. That sounds like it, removed an incorrect category for a misnamed album then the bot just re-added it because it crawled an external site that said that track was from that album.

Some of the mistakes are unique to certain third-party lyrics sites, so you can tell exactly where the bots are getting their false information.

I complained to an admin about it, they didn't care, so I gave up on it.

They don't care about accuracy. Only size, and eyeballs.


Thanks for the response, but that has nothing to do with my question either.


The word "you" in that sentence refers to Rupert_Giles or any other Wikia Staff member.

As far as I am aware, you are not Wikia Staff, therefore you are not qualified to answer whether something is permitted.


Since they said "Thank you again to everyone for your feedback!", and have left several comments: Signs point to yes.


You're welcome. Unfortunately, nothing anyone can say is likely to change the minds of those people.

With any power comes responsibility. In most cases, responsibility takes the form of knowing when not to exercise that power. Good people should exercise power because they must, not exercise power because they can.

Wikia Staff allow admins to choose how they behave, and it's up to each admin whether they choose to exercise restraint, or to exercise their "power" in each situation.

See also: All of Sannse's posts about being a good admin, and all of the posts about not caring what bad admins do. (Does anyone recall if Sannse has ever mentioned block durations?)


  • It does no harm

I agree that there's no functional difference between blocking or not blocking someone who was not going to return anyway. The only real difference is the length of Special:BlockList.

Both ways get the job done, but being excessive harms that admin's reputation in the eyes of people who care about the difference between "responsible" and "excessive". If all admins on a wiki behave this way, then it also harms the reputation of the wiki. (Thanks to Sannse for that concept)

Good admins should care that they are seen as responsible and not excessive. This applies to good people in general - but it occurs to me that cultural differences may colour many people's opinion of this.

  • most of the users I indef end up getting globally blocked as cross wiki vandals.

Which proves that it was not necessary to infinitely block them - they would have ended up globally blocked regardless of the length of the block.  :)

  • I've been dealing with a serial vandal [...] for at least 6 months

Thanks for the great example. In that specific case, I don't think anyone would think the infinite block was excessive, because he's proven that he will continue to return. Hopefully this is an edge case which you do not encounter often.


I hope that my own 6-month vandal isn't counting down the days to the new year. I should probably just reset it to a year since he last evaded the block, but I want to see if he returns before making a speculative block which may not be necessary.

5 range blocks and 1 single IP block targeting that vandal are set to "anon only", meaning that he is free to create an account from those blocked IP ranges at any time, but hasn't.

The vandal has been effectively prevented from editing, while others from the blocked ranges can still sign up and edit.

While it is likely most people would agree with an infinite block restricting account creation and existing accounts from those ranges - this has proven unnecessary, and therefore it would have been irresponsible for me to do that without cause.

Due to this evidence, I will likely uncheck those boxes when blocking IPs in future.


  • Being an admin for 3 years is cool

Not really. I never wanted it, and for this entire time I've wanted someone else to take over.

The intention of stating that I have been an admin for 3 years was to communicate that I have been experimenting with blocks for that long, so that you would know my opinion is based on facts and not speculation. An admin of 1 month could come to the same conclusion, but it wouldn't mean much.

You mentioned that you have been an admin for 5 years, but you have not shared what you have learned during that time.

I notice that your blocks here are not typically excessive. Well done!


Since experience is more relevant than time, and numbers are more relevant than words, here are some quick stats:

  • I have made 1195 blocks, changed 100 blocks, and unblocked 33 times.
    • 218x accounts, the rest anons.
  • 150x 1 sec/min warnings, 180x 1-2 hour, 354x 1 day. 233x 1 week, 180x 1 month.
  • 66x 1 year - 2 in 2014, 3 in 2013, 15 in 2012.
    • 21x 1 year blocks were accounts, the rest anons.
  • Reblocked anons = 76x
  • Reblocked users = 52x
  • I have made 2 infinite blocks, both of which I removed within a year.

Going strictly by the numbers, this shows: "fewer than 10% of anons re-offend", and "Up to 25% of registered users may re-offend".

A quick visual inspection shows that a few users were blocked several times and threw the percentage off. The fact that I give 1 month blocks for harassment/abuse also inflated the number of those. I'm sure if I processed the log properly instead of just sorting the list, those percentages would go down. It would likely also show that as time progressed, my block durations have decreased.

My overall impression from these has been that blocks longer than 1 day are rarely necessary, and that out of 64 expired/removed 1 year blocks, 0 vandals returned. (Some evaded, but were re-blocked.)


Since my last question was ignored, here's another:

  • Has anyone ever blocked someone for a year and had them return afterwards?

I highly doubt the 500 users infinitely blocked in 2005-2010 would be likely to return now.


I like it, for thumbnail galleries, but do not like the fact that it overrides type="slideshow".

Edit
  • I like the idea of only showing 8 by default and only showing the others after a single button press.
  • I like the idea of reducing the wasted space between thumbnails.

But I do not like the cropping, at all, so I will not be using this.


It does not appear to work inside a tabber on any tab but the first.

Unfortunately, clicking on an image still brings up the incredibly slow lightbox. The mobile lightbox is much more responsive, and features the ability to switch between thumbnails and slideshow. I encourage everyone to add ?useskin=wikiamobile to the end of the page URL and check it out.

Navigation galleries — defined as galleries with the link= parameter set on at least one image — will not have the new style applied.

Thank you for finally telling us what this automated addition is for.
Since I didn't get a response last time I asked, I'll ask again: Since you are automatically making this change and assigning the change to the last-editing user without their consent, does that mean that making other compulsory changes - such as spellcheck - without the user giving consent is also permitted?

And I'm surprised that no-one has asked yet: Will this change eventually be mandatory?


An answer: Thread:744980#4

Rappy 4187 wrote: This is actually a customization that is not allowed. The header and footer area of Wikia are official areas and should only be colored via the ThemeDesigner.

Someone really should tell disney and callofduty about this.


It's 2014, there's no reason to disable something while it is being rebuilt, and there hasn't been for a long time.


DaNASCAT said in Thread:726771 that the issue has been resolved.

Therefore, there are no chat problems.


In reality, the crashes never stopped, they just became less frequent for a while, but the frequency does appear to be increasing. Although it was claimed that "Chat has been highly stable for a week now", I documented multiple chat crashes in that week in Thread:726771#283 but was ignored.

As I've told the 30+ people who I've been seeing pop in during chat collisions: Be sure to report each and every chat crash to Wikia Staff, so they know that the chat is still crashing frequently, and when you do see your messages appear as someone else: be sure to announce "The chat is glitching and merging users, report all errors to Special:Contact." or something, so that others will be less confused.


3cooldog92, in case you missed it, your question has been answered:

When asked the question "Will this change eventually be mandatory?", BertH has said: We do envision a sitewide rollout at some point after the new editor tool is ready, but there's no date set right now.


Now that you point it out, yeah, that cropping is pretty bad, and basically forces the user to click if they want to see what they're missing.


FYI, when (not if) this becomes permanent, all you need to do is add navigation=true.


Azending, please pay attention.

Yes, currently, it is optional.

But it has been confirmed that one day, it will not be.


While I haven't yet seen any examples of this occurring, I use comments such as this from time to time. Mostly following the form field=value <!-- Do not change this! -->

If I notice it, I'll be sure to make a report.


Sirrob01, one alternate way that I already use in some cases is using a dummy parameter, such as:

|description=
|descriptionHelp=Please provide a detailed description of the colour and shape of the object

However, this itself causes problem when using the new visual editor.


My question was not about the new navigation, my question about about the current navigation, which is covered by Rappy 4187's response.


For reference, could you please tell us the most recent change which you did like, TheSitcomLover?


The thing is, the feature is disabled on the Skylanders Wikia, but when one edits, it still goes to Visual Editor and you have to click Classic Editor to use the old visual editor.

I just tested this, and with "Preferred editor: No preference" set in my Preferences, clicking "edit" opens the old visual editor.

I have only found 3 times the New Visual Editor loads when you click edit:

  • When you select "Preferred editor: Wikia's new VisualEditor".
  • When you select "No preference" and an admin enables the VisualEditor in WikiFeatures.
  • When you are logged out on a wiki which allows anon editing.

What gives you the impression that you are permitted to change the colour of it?


I think the blog post would be more useful by outlining the features/restrictions of the new gallery in words, instead of letting the the images do all the talking, because it currently doesn't mention the words "crop" or "square" at all.


Virago a-go-go, I don't think I fully understand what you're saying.

Could you go into more detail about what your problem is with the "No Preference" option going away?


"You will not be able to have both screens available as a side-by-side selection where you can work with one or the other, or both."

I haven't seen that stated anywhere, could you please link to where that has been said?

Source Visual tabs

Edit: And just so we're on the same page, you're talking about this, right:


If you must break apart an edit war, do it by not participating.

Excellent advice. As an admin, I think that this is the golden rule. Unfortunately, many choose to "make it personal".

However, I do not think that protecting a disputed page is necessary, simply inform all users involved that they must discuss the issue on the talk page, and that any users who edit the disputed information while the discussion is ongoing will be blocked, because anyone editing a disputed section after being warned is no longer acting in good faith. (But blocks should not be given without warning.)

As you mentioned, adding references usually settles the matter: if anyone then removes the reference, or changes the information so that it does not match the reference, then that is no longer simply "edit warring", and should be dealt with however "removing valid referenced information" is usually dealt with.

One extra piece of advice: Never use edits summaries as a discussion area, to argue, or to insult.

  • Good: "Undo revision 123 (452) - information does not match reference, see talk page."
  • Bad: "Undo revision 123 (452) - don't add stupid information, moron."

Using good edit summaries is a great way to avoid edit wars.


I like currently implementation on the new search bar on CC with the drop down to choose.

But changing the default to search all wikis instead of the current wiki, or to mix off-wiki results in with this-wiki results both sound like terrible ideas, which will cause much confusion.

edit: Specifically, this may cause users to inadvertently leave the wiki they were viewing, end up on a wiki about a different subject, get confused, and stop viewing Wikia at all.


More info for anyone wondering: Global, user and site Javascript and CSS are blocked on all pages ending in ".js" in the User and Mediawiki namespaces, as well as Special:Preferences. (There may be others pages.)

I had assumed "Security Updates" meant something else, but I've had it explained to me in a support ticket that the "Security Issue" in question is potential malicious admins, who might edit a .js page for nefarious purposes.

Presumably, blocking javascript and CSS when editing a .js page is to prevent malicious admins from preventing other users from removing javascript.


At this time, [...] you continue to have the choice of working simultaneously in both source and visual screens. Going from one to the other is a smooth process using the tabs for each.

And that is not being changed. (at this time.)

The "No Preferences" choice is going to be eliminated.

True.

Which means that the first screen you will get when you edit a page will be either Visual or Source to work from. They won't be available in conjunction.

False.

Those of us who use both screens simultaneously will have to (1) edit with the screen that opens when you go to edit (Source or Visual), (2) edit the page on that screen, (3) go back to profile and select Visual as the preference, (4) go back to edit the page with the Visual screen opened automatically, edit, save final edit.

False.

If that is not what will be the result of taking away the "No Preferences" choice -- Wikia owes us that explanation.

False. And I think you owe Wikia an apology.

Source Visual tabs

Screenshot taken with "Wikia's classic rich-text editor" enabled.

If you choose ""Wikia's classic rich-text editor", right now it will give you the 'classic' editor experience with the visual and source mode tabs: Help:Classic editor."

There was no justification to make this assumption, because it is completely possible for you to test this for yourself.


BTW, The similar Mediawiki:newarticletext does work at the moment.

(Hopefully the others will eventually be enabled.)

Edit: The "You are creating a page which was previously deleted" message also does not appear.


I used the word "owe", because you did. Wikia do not owe you anything either.

The classic-rich editor you select when you choose "No Preferences" in your profile is going to be phased out.

Please don't change the subject. Your original post in this thread was about the "No Preferences" being removed.

"No Preferences" does not mean "use the classic-rich editor": "Wikia's classic-rich editor" means "use the classic-rich editor".

Please go to http://452test.wikia.com/wiki/Virago_a-go-go with your "Preferred editor"set to "no Preference" and click "edit": the New Visual Editor will load, not the old one.

"No Preference" does not mean "Use the old visual editor" - it means "Let the wiki admins choose what is best for me".

All that is going away right now is "No Preference". You will still be able to choose "Wikia's classic-rich editor" right now, and for the immediate future.


Chat does not contain any ads, therefore there is no incentive to enable it by default.  It also would create more work for admins to police.

Achievements do not directly increase ad-views, and may decrease them slightly if more users register, as registered users see fewer ads. It could be argued that achievements == more edits == more content == more visitors == more ad-views, but I do not know whether this is factual. Several editors have told me that they would edit less if I enabled achievements. (It also would create more work for admins to police achievement-spammers)

Does the new Maps feature display ads? I haven't investigated it.

Anyway, Wikia has always been a for-profit company. Someone is obviously encouraging the organisation to increase ad revenue - that's what for-profit companies generally do.

Wikia introducing another feature to increase ad-views is not the end of Wikia as you've known it, it is standard practice.


You are correct, Darth Daron. I do not know why a "Councilor" would give you incorrect information like that.

Wikia Staff enable some "stable" extensions by request. (I am currently unaware of any "beta" extensions that have been enabled, but it is possible that there are some - from memory alone, the majority of extensions I have requested which have not been enabled have been "beta" extensions.)

Your best course of action at this time is to ask Wikia Staff via Special:Contact whether that extension can be enabled, and to ask if there are similar extensions available.

If there aren't, I have a feeling that DPL could do what you describe. Wikia Staff enable this extension upon request... and a promise that you will try to not overload the servers, so be sure to read up on cache parameters.


When enabled, all thumbnail and slideshow galleries use the new format, unless the gallery has "navigation=true" set, which is automatically set if any images in the gallery have "|link="

Edit: I haven't checked whether or not a page needs to be purged after enabling it, but I assume that since the new gallery is javascript-based, that it will not require purging each page.

Edit: I have discovered that when disabling it, all pages which were previously showing the new gallery need to be purged, or no gallery is displayed at all.

Who are you looking to prove something to?

Wikia Staff have enough work to do with real issues, and do not care what happens in the chat - all chat issues are issues for local chat mods.

If the local chat mods are the problem, then take it up with that wiki's admin - who may or may not care, or accept screenshots.


TheSitcomLover, read the "Next Steps" section.


Kirkburn, could you please confirm that everything I have said is true?

Source Visual tabs
"The "No Preferences" choice is going to be eliminated. Which means that the first screen you will get when you edit a page will be either Visual or Source to work from. They won't be available in conjunction."

False. Please look at the see image to the right. This is how it looks under "No Preference" AND "Wikia's classic rich-text editor", and how it will continue to look (for the time being) once "No Preference" goes away if you choose "Wikia's classic rich-text editor".

Source Visual tabs
"My entire commentary has been about the choice of having BOTH the Source Editor and Visual Editor available in conjunction when editing."

And the removal of "No preference" does not change it being available in conjunction. Please see the image, to the right, of the tabs allowing the use of both the source and visual editor with "Wikia's classic rich-text editor" selected in your preferences.

"Those Source and Visual tabs on the top/right that let you flow from one editing screen to the other under "No Preferences" are being eliminated for one, single preferred editing screen: Visual or Source."

Very very False, and this comment tells me that you do not understand my point, so here it is again:

The Source and Visual tabs are NOT going away right now, and Wikia Staff have never said they are.

While they are eventually going away, one day, this discussion is regarding the effects of "No Preferences" being eliminated.

Source Visual tabs

If you think this is incorrect, then read the thread, because 7 days ago, Kirkburn said: "you just need to change your editing preference to "Wikia's classic rich-text editor". This will give you the 'classic' editor experience with the visual and source mode tabs"
Please see the image to the right for an example screenshot of those tabs, taken while using the preference that Kirkburn advised.

"Nowhere in the new visual editor screen..."

What appears on the new visual editor is irrelevant, as this discussion is regarding the removal of "No preferences"

Source Visual tabs
"Where is the return to "Visual Editor" selection on the source screen? Oh! That's right! You have to select "Apply changes" to return to it."

False. Again, look at the image to the right.


Here's how it is supposed to work:

  • If any gallery image contains a |link=, when the page is saved "navigation='true'" is added to the gallery tag.
  • The newfangled gallery script checks for "navigation='true'" in the gallery tag, and doesn't load galleries with the gallery tag.

I say "supposed" to work, because I just attempted to confirm it, but adding "|link=" did nothing.

It should apply to slideshows as well. You can test this yourself by adding "navigation='true'" to a slideshow and using ?gallery=new, or enabling the New Image Galleries in Labs.

I personally don't think that slideshows should be converted into thumbnail galleries at all, and that "type='slideshow'" should also stop the new gallery from loading, because if someone wanted thumbnails, they wouldn't have set it as a slideshow in the first place.


The word "Favorite" indicates bias.

It's impossible to have a objective "Favorite".


Since Sannse is from the USA, she spells it without a U.

edit: thanks Trizam, I did not know that.

Hedgehog12 is correct, it doesn't really matter where anyone is from, they can also spell however they like. (Although it always helps if it's considered correct somewhere in the world.)


You are already aware that all users who have selected "No preference" will have this changed to "Wikia's new VisualEditor", so it makes no sense for you to change it to "No preference", when you have made it clear that your actual preference is "Wikia's classic rich-text editor (where available)".


To copy/paste without a c key:

  • Highlight text with mouse.
  • Right click on Highlighted text.
  • Click copy.

Since you have a v, you can paste normally, but you could also right click > paste.


Tupka217 wrote: However... you're late to the party, the (official) feedback period is over.

BertH wrote: We'll continue to review the feedback given here and elsewhere. Please keep it coming as we move toward a wider release!


Depends on how you define "glitches".

I know of many issues which have not yet been fixed, here are a couple of favourites off the top of my head:

  • Red links in "deleted" threads appear on WantedPages. (Known to Staff since Jan 2012, this is the oldest I can recall without checking my support ticket history.)
  • All users can access threads which are deleted through the normal interface through their long-form titles.
  • My rename has not been completed and half of my edits/log entries are attributed to my old username, leading to the situation where I have apparently been an admin "forever", as there is no record of my this username ever being promoted.
  • Anon users receive notifications of old-style talk page messages, but not message wall messages.
  • NUMBEROFARTICLES is often inaccurate.

Edit: Also, from Feb 2012, previously existing user talk sub sub pages, such as User_talk:452/subpage/sub-subpage are rendered inaccessible with Message Wall enabled. I've long since moved all these old talk sub pages, but it is still a "glitch" in that they did not anticipate, and have no plans to fix. (I wasn't looking for more examples, but came across this problem again while looking for something else.)


Do you know what "long-form titles" means? I guess not.

Wikia Staff know what I'm talking about, and they probably wouldn't appreciate me telling you step-by-step how to do it.


Staff will not give legal advice, will likely just link to http://www.wikia.com/Licensing


No.

If an external site is copying Wikia content then that is an issue for the copyright holder: you. Wikia Staff will tell you to send a DMCA takedown request yourself.

Conversely, if a Wikia user copies from an external site and they contact Wikia Staff, they will tell them the same thing.

The only time Wikia Staff will do anything is if one wikia wiki is taking from another wikia wiki.


Please correct me if I'm wrong, but it seems that "deleting" a map has no real effect - they're still accessible and editable.

Additionally, there appears to be no place to leave a summary when deleting a map.


The tabs are supposed to be gone when you select source, that's how it has always been.

As for your grammar lesson, I can only assume that you are attempting to state "the change is going to be happening in the future", in which case please read the date on the blog post.


Karanmd, the best thing you can do is make sure to report ways in which the old Rich Text editor is "better" than the new VisualEditor.

Such as "I prefer the old Rich Text editor over the new VisualEditor because it is easier to switch to source mode" - which seems like a common complaint.

edit: Wikia Staff want the new VisualEditor to be better than the old one, but if you do not tell them why you prefer to stick with the old editor, then they may not necessarily address your concerns.

If there's anything about the new VisualEditor which specifically decreases your productivity compared to the old one, then they should care about those complaints.

However, they still have not addressed the fact that changing the edit summary to a textarea element instead of an input decreases productivity due to the inability for autocomplete to work, so they may not care about some specific concerns, but it's still better to tell them specifics.


Some previous mentions:


TheSitcomLover, if you think that the Classic editor is better than the VisualEditor, then the best thing to do is list the specific ways in which it is is "better".

Wikia Staff want to make the new VisualEditor to be better than the old one, but if you do not tell them why you prefer the old editor, then they will not know how to make the new one better.


As in the page halfway loaded and you just stopped receiving data, or as in half of the content was missing from the page, but you still received the wikia footer?


In your case, Tupka217, it sounds like the CSS and JS didn't load, is this correct?


As noted in the blog post, use Special:Contact to report issues to staff.

edit: However, since the skin switch button + display clock are addons, and not core features, it's not really an issue for Wikia Staff, it's an issue for the authors of those scripts, so you should talk to them about it.

Edit: What you said in the thread you linked seems to indicate that no scripts at all are loading for monobook, so this may be an issue for Wikia Staff after all.


The classic Rich-Text editor is going away, when the new VisualEditor is "finished". No-one can change that, and it is unreasonable to request that.

The new VisualEditor will be "finished" when it is equal or better than the classic Rich-Text editor.

If you think that the classic Rich-Text editor can do something better than the VisualEditor: tell Wikia Staff so they can improve VisualEditor.

If there is something that the classic Rich-Text editor can do that the VisualEditor can not do: tell Wikia Staff so they can improve VisualEditor.

If there is a reason that you prefer the classic Rich-Text editor: tell Wikia Staff that reason.


No, the way Kirkburn put it implied an opinion: "when the new VisualEditor is judged to have surpassed it in all important ways".

I deliberately reworded it to be objective.

It will be objectively "equal or better" when:

  • It does at least everything the classic rich-text editor can do. (Currently, it cannot)
  • It does everything the classic rich-text editor can do at least as fast. (Currently, it cannot)
  • It does everything the classic rich-text editor can do in equal or fewer steps. (Currently, it cannot)

However, this is probably wishful thinking on my part, as I have absolutely no evidence that Wikia Staff regard those as requirements.

This is why it is very important that you tell Wikia Staff specific ways in which the classic rich-text editor is still better than the new VisualEditor.

You cannot change the fact that the classic rich-text editor is going away.

You can change how good the new VisualEditor is by telling Wikia Staff specific ways in which the classic rich-text editor is still superior.

Personally, I use source, and always will.


"public bug reports" are not guaranteed to get noticed, or fixed.


How can the Classic Editor not be fit for the future?

The Classic Rich Text Editor has always had a number of problems.

I personally know of at least major 2 things which the Classic RTE messed up, but which the Visual Editor does not, and I'm sure that Wikia Staff have a much longer list.


If you want to be helpful, you should tell Wikia Staff specific reasons why you prefer the Classic RTE over the new Visual Editor.


What is the benefit of using commas between each assignment to the rights array?


Apparently the top toolbar change is only the first step in a series of upcoming changes.

(I forget where I read that, possibly in the previous comments here.)


I'm familiar with Javascript, and Shining-Armor's example, but I'm not familiar with Jr Mime's example, and could find no javascript tutorials recommending that particular usage.


The reason I was asking is: why not simply use a semi-colon after each to avoid confusion? (Semi-colons would not work in Shining-Armor's example, but that is not what I am asking about.)

Alternatively, why are you only using commas there - why not also use commas between the other variable declarations?

I commonly just use semi-colons, and recognise that some people prefer to use commas, but I don't understand the inconsistency, and I'm assuming there is a purpose, which is why I am asking what the benefit is.

Each of these work: (I've removed the line-breaks to prove they work minified, since removing the semi-colons also works when line-breaks are present.)

var rights = {}; var admin = "admin"; var bureaucrat = "Bureaucrat"; var staff = "staff"; var vstf = "vstf"; rights['Someone is an admin'] = [admin]; rights['Someone else is an admin'] = [admin]; 
//semi-colons, with var before every variable.
//This is how I normally would do it.
var rights = {}, admin = "admin", bureaucrat = "Bureaucrat", staff = "staff", vstf = "vstf"; rights['Someone is an admin'] = [admin], rights['Someone else is an admin'] = [admin];
//A semi-colon only when required, otherwise commas.
//This is how I sometimes would do it.
rights = {}, admin = "admin", bureaucrat = "Bureaucrat", staff = "staff", vstf = "vstf", rights['Someone is an admin'] = [admin], rights['Someone else is an admin'] = [admin]; 
//omit all vars, and therefore another semi-colon
//I try not to do it this way, because not a good practice: but it works.

Are the three designs going to be randomised for each pageview, user, or wiki?

edit: Also, you mentioned the experiment having 3 version of the nav - what about the control group?

edit: The bug which causes pressing "edit" again to wipe the previous changes still hasn't been fixed. :(


I agree, a scrollbar is definitely needed.

The odd thing is this:

<li id="notificationsContainer" class="scrollable" style="height: 622px;">

They've already got a "scrollable" class there, but no scrollbar appears.

I've implemented one in my global.css which everyone is welcome to copy.

(I've been testing it on tardis.wikia, as there are a bunch of highlighted threads which are over a year old so I know my notifications there are always going to stretch past the bottom of the page.)


Thanks for the info, it looks like I'm in group A, but I'll try clearing my cookies. (Edit: I tried, but clearing my cookies didn't help.)

No, that isn't the issue I'm referring to, as there is no "show changes" button when editing a blog comment.

See tickets #168983, #148724 and #137367 for info about the bug.


Because that's standard procedure for A/B testing. It's not supposed to provide "user feedback", it provides "user performance feedback", because they're monitoring behaviour.

I suggest you read up on A/B testing if you want to know more about it.

It will not be an option for wiki admins, or an explicit option for users: but users can clear their cookies in an attempt to be assigned to a different group.

(In this case it's A/B/C/D testing, but close enough.)

edit: It would appear that I was mistaken. I thought there was a control group using the previous design, but there is not.

It is an A/B/C test, where A - the way it has been on CC for the last 2 months, is the control group.

That is not a real control group, this experiment is a farce.


Energy X, Wikia is not concerned about disk space, or database size.


Now that it's live, I took a look at it on a bunch of differently coloured wikis, and

  • I still think that "white on *" looks terrible.
  • I still think it is too large.

Both of things worsen each other, perhaps if was either smaller or followed the colours of the wikinav, the other wouldn't be as obvious.


That is a good point, it would be better if it was highlighted as before.


Indeed, the only change that appears to have been made is whether it scrolls, which means the majority of the feedback they're going to get is going to be the same feedback from last time.


I did hide the old bar in my global CSS - luckily the user/notification menus were not within the old bar, so completely hiding it wasn't a problem.

With the new one, I have:

[search this wikia] [loooooooooong search bar] [user menu]

Also, linking to the wiki in question might result in a normal user being able to diagnose the problem if it's a local CSS issue.


According to what we've been told - yes, Memory Alpha changing it to black should be considered a violation.

However, large wikis have been known to be given special treatment, such as disney.wikia and callofduty.wikia being allowed to have a background on the old bar.

I notice that wowiki has not yet changed theirs, but I also expect them to be allowed special treatment.


It's not fat, it's festively plump.

To save you having to inspect-element-deleting it on every page, you could instead add:

.global-navigation {
  display: none;
}

to Special:MyPage/global.css


There is still an option to use Monobook.


I agree, and that kind of tracking makes me want to use Wikia less, so I don't accidentally skew their results.

I also would appreciate honesty instead of disguising their goals.

They still haven't released any real results regarding the videos sidebar either. With that, the goal was never to get more editors, it was to get more people to view ads, which has probably been a success, so there is no reason for them to release any results regarding the relationship between video views and edits, if they ever tracked it at all.

A more prominent search bar may result in more page views, which may result in more edits, and they have the power to count exactly how many people edit after using the search bar or viewing videos. But since they wouldn't confirm that they were even measuring that, that gives me the impression that all they really care about is measuring views and not edits.


When my connection is running slow, I usually switch to Monobook since there isn't as much extra stuff being loaded.

I haven't measured exactly how many bytes are saved by using Monobook, but it definitely loads faster.


Facts:

  • The old bar was 34px tall, with a 3px border above it (I still have an old tab open)
  • The new bar is 56px tall, with a 1px border under it
  • 34*2 = 68
  • 34 = "As tall as the old version"
  • 68 = "Twice as tall as the old version"
  • 56 = "The height of the new version"
  • 56 < 68
  • "The height of the new version" is less than "Twice as tall as the old version"

If it is taller than 56px for you, then it is a bug.


Since I've been unable to locate any positive comments, here's one: I like the effort to make the search bar more prominent.

I took part in the search bar test over a year ago and was wondering what ever happened with that, but it seems obvious that this was the outcome.

One suggestion: some kind of "Search" placeholder text in the input field, even though it's already to the left of the field, making it explicitly clear that the blue part is where you type wouldn't go astray.

Edit: Clarification

When I say "I like the effort to make the search bar more prominent", I'm talking about moving it, not talking about the fixed positioning.


Each wiki is free to update their own emoticons at any time.


Although it doesn't really matter now, here's how .WikiaHeader nav { display: none; } looked:

How it looked with the old top bar hidden


Even if 99% of the comments in this thread are negative, the people replying here represent less than 0.1% of the wikia population.


For anyone who hasn't worked it out yet, the class for the category box has changed from "WikiaArticleCategories" to "article-categories".

Changing any selectors for ".WikiaArticleCategories" to ".article-categories" should be sufficient.


Changing emoticons has nothing to do with chathacks.


That is not how it is supposed to look.

When I disable my personal CSS and reduce the width of my browser, that does not happen.

There may be many people who are seeing it like that, but they just don't know it's a bug and not a feature.

I think that this kind of confusion would be avoided if Staff posted more images showing how things are supposed to look.


Feature suggestion: Since all of the avatars in the notification section are round, why not allow actually round avatars by supporting transparency?


Come on now, that's apples and oranges.

The content changes every day, the design doesn't.


Nope, Bane Cane, read Terms of Use instead.

This paragraph: "'Not to intentionally block, remove, or otherwise obstruct the proper functioning and view of advertisements, and/or 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 advertisements and/or user interface and functionality;

Wikia Staff can, and have, said that "proper display of the user interface" is "not having a clock there".


Calling a theory an "educated guess" is like saying it's an "educated guess" to call the sky blue. True, but misleading.

  • A "law" is a fact without an explanation.
  • A "theory" is an explanation about a law, formulated using confirmed evidence.
  • A "hypothesis" is a test derived from a theory, or an unconfirmed theory.

In other words, a hypothesis is a "educated guess". Basing the hypothesis on a theory is what makes the guess educated.

"Scientific Laws" are not "confirmed theories", it's the other way around. Theories describe how a law works.

  • "Things fall down" is a scientific law.
  • The theory of gravity explains why.
  • "Things must fall less in space" is an educated guess, a hypothesis, that was proven true.

Further reading:


I don't see any improvements regarding this.

If the notifications go past the bottom of the screen, it is still not possible to scroll down to see them.


They have said on multiple occasions that both a clock in the header, and a background behind the header, were against the TOU, yet many wikis still had both. While I like to use tardis.wikia as an example of what's allowed, I do that in lieu of other evidence, and this in case Wikia Staff have been explicit.

They have also said that adding links to the "On the Wiki" tab was against the TOU due to the same paragraph because "proper display of the user interface" was "as it is by default".

Digifiend, if you think I am wrong, ask Wikia Staff directly via Special:Contact, and then apologise.

edit: re-added two things which were eaten by a bug.


I'd just like to remind everyone about this part of the post

Our aim from the start is to maintain performance in the most active group while significantly increasing engagement amongst the other groups.

If you think that you are part of the most active group, take the rest of the month off to send a clear message to Wikia.

edit: I've been thinking about this some more, and even if you just hide the thing with adblock or personal CSS - if you continue using Wikia during this test, it will be recorded in Wikia's results as: "This user's editing/browsing habits have not changed, therefore they are okay with the new design"


I can tell you that Tupka217 is the 7th most active user on Community Central. (Who is not staff, bot or admin.)

I can also tell you that this is a public forum, and anyone can comment, so long as it's not the same comment over and over.


I agree that is it "unclear" what will happen, but it will not change to the old one.

http://community.wikia.com/wiki/User_blog_comment:Rupert_Giles/Global_Navigation_Update/@comment-BertH-20141204194147?permalink=765824#comm-765824

Further changes to the new design may happen, but we will not be returning to the old design.

So, apparently they won't just be "turning it off" at the end of the test.

This means that one of four things will happen at the end of the test:

  1. Nothing will change
  2. Everywhere will change to the CC version
  3. Everywhere will change to the one of the three test versions
  4. Everywhere will change to an updated version

The last one is the optimal outcome, and they'll actually change the header in line with feedback - but knowing the glacial pace at which updates are usually made, this seems unlikely.

It seems likely that #3 will occur - whichever way resulted in the most edits/ad-views will be used. (This depending on what they're actually measuring.)

If any further changes happen due to feedback, we probably won't see them until at least February.


I certainly hope not, he's a helpful user here.

As it is, he is already not allowed to talk about certain things since signing a non-disclosure agreement with Wikia.

If he becomes a paid member of staff, he will know more and be able to help users less - not to mention having less time to help.

The same thing happens with video game modders who are recruited by game developers - they stop producing mods, and are legally not allowed to share certain information, even if they discovered the information while "off the clock".


What kind of results do you expect to get out of this "testing phase"

This is a variant of an A/B test, so the results they expect will be in line with the normal results of an A/B test.

As it says in the blog post:

" At a high level, we are tracking total searches and total page views per user. But we’re specifically looking at how each of these metrics move within user segments."

The results they expect to get out of the test are to see if the behaviour of those 3 groups changes, specifically:

  • Whether they search more.
  • Whether they view more pages.

We will likely never know exactly how they boil down the results, whether their report generator just spits out

"More people searched, success!"

or whether they get a more detailed:

"Out of the 10000 most active users, 5001 searched more, 3000 searched less, 1000 stopped searching and 999 stopped editing altogether".

It's also unclear whether they would care if the 999 of the top 10000 users stopped editing altogether, so long as 5001 of them were searching more.

As usual, they do not appear to be measuring whether or not the changes result in more edits, and a member of Staff will likely reply to any such inquiry to copy/paste the standard response of: "If you have more views, then more people might edit". (While true, they have the power to measure it, and apparently don't.)


I'm curious about the statement that this "isn't allowed".

Who says this "isn't allowed"?


Javascript, so User:MeerkatMario/global.js


They have already answered that question in these comments with a "no".


If "scrolling up to search or access profile/notification" was a problem, then the solution was already "press the home key".


There's no way to change it back exactly how it was with using personal modifications. You could try to spend hours in dev tools trying to tweak it to where it used to be, but it will never be the same (the HTML-DOM structure is completely different).

You can easily alter the HTML-DOM structure with javascript. It might be difficult to get it exactly how it was, but it's certainly possible.


Can I safely use Special:Search directly, or will that count towards your "User searched! Success!" tally?


I am not trying to "inconvenience" the experiment, I simply wish to opt-out of being counted.

My normal editing activity should not be interpreted as a "yes" vote.

edit: I worded that poorly. I should have said: "I do not wish for my normal editing activity to be incidentally counted as a positive result."

edit: Also, it does not inconvenience me to stop editing altogether.

edit: I have already been deliberately contributing less due to videos sidebar, and the total number of both edits and editors has fallen since it was enabled.


At a high level, we are tracking total searches and total page views per user. But we’re specifically looking at how each of these metrics move within user segments.

My actions contribute to the results in my user segment.


I checked the 4 wikis linked in your profile header and don't see what you've described, 523.

Could you please link to the wiki, and upload a screenshot of what you're seeing?


It's Wikia's content. If you mean "The content belongs to Wikia", then this statement is false.

When you contact Wikia regarding third-party sites copying the content without attribution, they very clearly tell you that it is not their content, and that they cannot sent DMCA requests on the behalf of authors of the content.

You could also mean "It is the content that is on Wikia" - but that seems like a redundant statement to make.

Regardless, Wikia is under no obligation to take the content down, but this is not because they "own" it.


I'm confused, what is the point of this script?

How is this any different than just adding

.AccountNavigation.active > li { background-color: #000; }

to global.css?


Last time I checked, the style wasn't aplied.

I just checked, and it works fine.

Add least while using javascript.

That's possibly because it is CSS, not javascript. It belongs on a CSS page, not a JS page.


It draws the eye away from content too much

Response from branding team: "Success!"


I would still prefer that banner notifications not auto-hide-remove at all, as it hinders multi-tasking.

Edit: Also, you shouldn't call it "auto-hide" when you're not hiding the message; you're removing it from the DOM.

If you were simply hiding it with CSS, then I could simply override it in my personal CSS.


Or, since mine and Digifiend's main problem is it disappearing before being seen: perhaps not starting the countdown until the tab has focus.


Yes, there is a particular reason, but there does not need to be: in general, it is bad form for server feedback to automatically disappear.

Web designers should not expect the user's attention to be 100% fixed on the site, and websites should not have Quick time events.


Removing the Right Rail

In the example image, it looks very much like the ad is now placed above the infobox.

For many wikis, the infobox contains vital introductory information about a subject.

Both on Wikia, and Wikipedia, my eyes immediately focus on the infobox when opening an article, so the presence of an ad... oh, nevermind, I now understand exactly why you're putting an ad there - well played.


edit:

The intention behind removing the right rail is to bring your content front and center

I call complete BS on this.

The intention behind removing the right rail is clearly to bring the ads front and center by embedding them in the content.

You are obviously mixing the ads in with the content in the hope that more people will either accidentally click them, or mistake them for content and deliberately click them - this is a standard practice, and it's abhorrent.

Attempting to disguise this motive by claiming that the intent of mixing the ads with the content is to highlight the content is deceptive doublespeak.

For the record, I like (edit: some of) the nav changes, but no amount of "good changes" could ever make up for a site inserting ads amongst the content.


Thank you for posting about Gallery type="slideshow" not working in monobook.

I always test my own changes in monobook for compatibility, but I don't commonly test whether Wikia's changes have broken something.


Thanks for the info, John Titor.

I've tried to use the global search in the past, but I find Google to be faster and to give more useful results.


I guess I'm nobody, because I've always liked the right rail.

  • The recent activity module let me quickly check recent edits without having to check my email or switch to my RecentChanges tab
  • The photos module let me easily see if there were any photos being uploaded - and made it easy to spot vandalism images
  • The chat module let me easily see who is in the chat.

The Sponsored-Videos module messed up the right rail a bit for me, but I made it disappear, so it wasn't a big deal.

I've always liked the clear delineation between content and non-content, and I think that mixing non-content (ads and more ads) in with the content is a major step backwards.

Since the goal is "Make the ads more visible", my complaint "The ads are in the way of the content" only confirms that the goal has been achieved.

Edit: I think that "Nobody likes ads in the middle of content" is more true than "Nobody is a fan of the right rail".


The changes will eventually be forced on everyone, although an "opt-in" Wiki Feature to display more ads in certainly an interesting idea.


I think it is safe to say that any users who are alienated are not their target audience.

I started using Wikia because I liked how it looked and functioned at the time. There have been many improvements since then that I have approved of, but easily just as many which I find perplexing.

I have come to terms with the fact that I am not their target audience, and "the shit I liked about them" was merely a coincidence.

I don't know what their target audience is, and given how they're made many changes over the years, I doubt they do either.


Because they were not making enough money from only having ads at the top and bottom and sides and background.

Here's how the meeting probably went:

  • Boss: "Team, we're not making enough money from ads."
  • Team: "But we have an ad at the top, an ad in the top right, the must-watch-because-these-are-paid-for-video module in the middle right, more ads at the bottom right, more ads at the bottom, ads in the middle of galley slideshows, and sometimes ads taking up the whole background"
  • Boss: "Well, that's just not good enough - find somewhere to place more ads!"
  • Team: "But the only other place is in the middle of the article!"
  • Boss: "Fantastic idea, you get a raise! But to pay for the raise, you're going to have to find another place to add another ad."

Wow, you're right, I zoomed out and there's no more Fluid. :(

That's one more fact to make me think that this whole thing is an unfunny practical joke.


This++.

I stopped looking at the other features once I realised this whole thing was designed to put ads in the content, but you're completely right.

There are far too many things hidden away in menus now. Productivity is going to plummet.


I agree, many of the comments are very reminiscent of the switch to Oasis, and it wouldn't surprise me at all if a few more Wikis forked due to this.


Being an adblock user, I see no ads ever. But I'm not just a user, I'm a heavy contributor and an admin, so I have to be aware of how other people view the wiki.

I already have to deal with the widespread notion that wikis are inherently wrong because "anyone can add anything they like", and I try to dispel that as best I can.

I'm already aware that many people don't think very highly of Wikia due to the existing ads, and I've made changes to the wiki skin to highlight the difference between the "content" area and the "navigation and ads" areas.

These changes undo a lot of what I've tried to achieve, and really undermines my contributions as a whole.

Whether or not I personally see the ads isn't the issue, because I thought I was contributing to a site that was better than other sites who mix ads with the content, but this change is basically a bait and switch.


They make no money from chat, so there is no reason for them to complete it.

If they did listen to your feedback and spent more resources on the chat, the first thing they would do is to add ads to justify the development costs.


I remember how Fluid didn't have a useskin parameter - the reason behind that was because Fluid wasn't a separate skin, it was a compulsory change to Oasis.

The fact that Venus wasn't designed from the ground up as a separate skin with a useskin parameter seems to indicate that it will be also implemented over Oasis.


I'm a little rusty on my Wikia history.

Did the outrage and the forks due to Monaco and Oasis actually cause Wikia to change a single thing?


that's one of the many things that makes Wikia special.

Well said.


I've been thinking of a few ideas - mostly consisting of ugly red borders and

.ad:before {
  content: "This is an ad, not content.  We're sorry, we're so sorry.";
}

But I have a feeling that the rules for customisation are going to keep become more restrictive.

I also have a feeling that fewer people will bother giving their feedback about this after having their feedback largely-ignored regarding the global nav.


It is not supposed to blend in, so they will regard your "complaint" as a positive result.


I feel the wikia is trying to change too much at once. It would probably be better if we got to try each change individually and see how well they work.

They're throwing everything at us at once deliberately, so that they can later remove some of it, and claim they have "compromised".

It's like with haggling, the seller will always set the first offer way too high, so they can "compromise" by reducing the price to what it should have been in the first place.

edit: If you want haggling sellers to quit this nonsense, you tell them they have lost a sale and walk away.


Gcheung28, you already had overwhelming feedback that the global nav was "too big" and "too white", but for some reason you ignored that feedback and chose only to address "too scrolly".


BertH, you didn't answer Lord Aevum's question.


It might be a good idea to find a better analogy than milk, since milk has a limited quantity and goes sour with time.

And cows get fed by the farmer. Editors don't.


Is there any progress regarding fixing reverse-sorting tables?

edit: For anyone who doesn't know, you can work around the bug by holding shift.


Thanks Cqm!


I don't know about anyone else, but I'm still waiting for answers to the questions in the comment immediately above this one.


2 weeks, still no answer.

My answer stands. The new design, after being finalised, will be forced upon everyone, and not just volunteer wikis.


The fact that this "prototype" is Wikia's "best effort at an holistic, integrated design" is the problem in a nutshell.

The fact that Wikia thinks that any collaborators would want accept ads in the content is insulting.


That is a very good point Gloweye.

The more they try to force ads into people's faces, the more people will simply block ads.

I'm frankly surprised that even mentioning adblock isn't against the TOU yet.


"the community was not fully ready to showcase the prototype"

I had read that the Disney Wiki was volunteered by an admin acting alone without consulting the community and other admins.

I applaud that community standing up for itself, and hope they also decide to remove the rogue admin.


stop letting marketers tell web devs how to do their jobs.

I think you've hit the nail on the head.

Some "marketing" person has convinced Wikia that identity is not as important as following the latest trends.


I wasn't here for that, so I don't remember it, but I've read some of those old discussions, and what I see is people who joined Wikia because they liked how it was. I also notice a lot of those people are no longer here.

Wikia, then and now, gambles that following the latest trends will attract more people to make up for those that leave.

Unfortunately, since the number of people online, and on Wikia, is constantly growing, they will always see "There are more people this month, therefore what we did last month as a good idea".

edit: And when I first read those discussions, years ago, I thought "Well, I'm glad I wasn't there for that, but I think Wikia looks okay as it is, so I think I'll edit here."

I thought that the changes away from monobook was just Wikia establishing it's identity, and assumed that they were just about done. I was obviously wrong.

If Wikia had looked like the new prototype when I first saw it, I would not have started editing here.


This new "layout," means that all of those people were wrong. All of them. And so were your studies and research.

Well said. I would have more respect for the changes if they simply admitted that.

Someone else also mentioned that the new layout also undoes the "Fluid" changes, which were much more recent, and so much stranger to abandon.

Thanks for the link to the "new look FAQ". As they said, their goal is to "encourage new users to join the site." - not to keep existing users.


Since Lord Aevum asked, it must not be obvious to all.

It was a binary choice: "everyone" or "volunteer", and you and I both know the answer is "everyone". Wikia Staff could address the question on their terms, but they usually choose not to do so.

While they would certainly never say the words:

"Yes, we will force this change on everyone"

I don't understand why they cannot simply say:

"Once it is complete, the new design will be implemented on all wikis"

This would confirm "everyone", while not using the given terms.

I've never been able to work out if "giving vague answers which don't address the question" is something Wikia Staff do deliberately, or if it's a coincidence that almost all of them avoid questions in the same way.


As a heavy editor, I would not characterise this glitch as "common", especially as it is happening on every edit.


NewMarioFan65, you do not have to go back and click publish again. If you check Recent Changes after clicking publish once, you will see that the edit went through the first time.


What happens with that bug?


I do not experience that.

Edit: Additionally, what do you mean by "old" source? Is there a new version?

Edit: I even tried ?action=edit&usesitecss=0&usesitejs=0&allowusercss=0&allowuserjs=0, and I still do not see what you're referring to.


You have misunderstood me, I am telling you that *I* used them to eliminate the possibilities that my customisations were stopping the bug from occurring.

Could you please outline the steps required the replicate this bug?

Edit: My editor preference is set to "source editor", when I edit a page, the textarea is scrolled to the top, as shown here:

Source not opening at the end of the page

Seriously though, outline the steps? Click Edit, done.

I have followed these steps, and have not been able to replicate the problem, see screenshot above.

"With the queries, click Source after you click Edit. The new Visual Editor is not used."

I do not understand what you mean by this.


I know what URL queries are.

"Edit: My preference is Wikia's classic rich-text editor using AdvancedOasisUI to open Source on initiation of an edit session."

Thank you for finally providing the vital piece of information required to replicate the bug.


edit: There is no need for me to make a new comment, as this discussion has gone on far too long already.

For the record: I had no idea that this problem involved the "classic rich-text editor", the only suspicion I had was that it might have been browser related.

"Source" was mentioned several times, leading me to believe that DEmersonJMFM's editor preference was indeed "source".

I was asking for information, so there was no reason for me to guess what the cause might be. The only thing I could have possibly done differently to make this "quicker" would have been to say "Could you please outline the steps required the replicate this bug?" initially instead of "What happens with that bug?".


Is this continuing to happen to you, Energy X?

This only occurred for me for about 8 hours, then went back to normal and hasn't happened since.


The 31st 29th is still "in January".

Additionally, they stated "Our intention is to re-evaluate the nav performance and the experiment results in January and make any necessary adjustments "

They stated their intention, they did not state that they would, or make a "promise".


There is, when you click on them, a lightbox pops up with the image in it.

Well, I say "with the image in it", but it actually pops up with no content at all, then after a few seconds the image details and image are loaded.

I told Wikia years ago that it would make more sense to display the link to the file page immediately, but they apparently don't care about site responsiveness.


Speaking of WAM, is there any progress on graphing the WAM score history for each wiki?

And still kinda speaking of WAM, what ever happened to wikis getting more detailed stats since Special:WikiStats broke?

We're making some great progress on a new metrics tool that will give admins better access to traffic stats about their wiki. More updates on this coming soon!

Dopp, Technical Update: April 26, 2011

WikiStats is going to be replaced not too far down the road ... and we are going to introduce some exciting analytics tools soon.

Support Ticket #42239, 2012-08-20

A reminder for anyone who does not understand how the "No preference" preference worked.

Visual Editor setting in Special:WikiFeatures
Enabled Disabled
New Visual Editor New Visual Editor New Visual Editor
Classic Rich-Text Editor Classic Rich-Text Editor
(with 2 tabs)
Classic Rich-Text Editor
(with 2 tabs)
Source editor Source editor Source editor
No Preference New Visual Editor Classic Rich-Text Editor
(with 2 tabs)

The removal of "No Preference" means you can no longer choose "Let the wiki choose for me".


For anyone else who didn't quite understand what 2Actimv was referring to:

When you visit a wiki in a different language than you have set in your Preferences, and a wiki in your preferred language exists, there is now a notification at the top of the screen.

Examples:

(I imagine, but have not verified, that this only works when the other wiki is language-linked)

I think this is a pretty cool feature, and should definitely help bring attention to inter-language wikis.


Great idea, and very timely since a user just removed one of my messages an hour ago.

Is it possible to alter rights on one wiki to prevent users from removing threads on their own Message Wall? (As in, was it implemented as a "CanRemoveThreadsOnOwnWall" right, or was it hardcoded as "if (CurrentUser.hasRight(CanRemoveThreads) OR Wall.Owner == CurrentUser) then: allow"?)

"Regular users are not able to revert actions performed by moderators or admins (remove, restore, close, reopen), even on their own Message Walls."

Does this mean they cannot remove/close threads opened by mods/admins, or does this only apply when mods/admin first does a remove/restore/close/reopen?

As you know, many users attempt to remove admin messages from their walls, and I think "don't remove admin messages" is pretty standard, so it might be worth having it as "can't do anything to mod/admin messages" by default.


Feature request: Email notifications of thread/reply removals, both for my own messages, and replies in threads I've participated in.

This is somewhat mitigated by these rights changing, but if users can still remove threads I create from their Message Walls I definitely would still like an email notification of that. I think that other users should also get a notification when an admin removes their post.

At the very least I think there should be a "There has been a change to a Thread you have posted in" email, similar to the "There has been a change to this page" or "There has been a comment to this blog post" email.


Feature request: Splitting and merging threads, including moving Message Wall threads.

The most common Thread removals I perform are closing Threads left in the wrong place, such as posted as a new Thread instead of as a reply. The ability to "Merge this into Thread:X" would be an incredibly useful admin/mod function.

As Threads often meander, the ability to move off-topic comments into a new thread would also be very useful.


(I've requested both of these privately in the past, but I do not know whether my suggestions have made it to the eyes of voldevs)


I agree, in light of the existence of "chat moderator", it would make more sense to name the new group "forum moderator" to match.

Edit: I should have checked page 2 before replying this this one, since this has already been mentioned.


Saved images (from Wikia to your device) will no longer use a generic name like 'latest.png' instead of the normal filename. Note, this change will roll out gradually.

Excellent.


Looking at it from the perspective of an good administrator trying to deal with a bad user who removes valid messages, I agree.

Looking at it from the perspective of a good user, who is having valid messages removed by a bad administrator... not so much.

But hey, bad administrators are going to be bad administrators no matter what "rights" they have, but it's still good to have the tools as a good administrator.

Feature suggestion: Stop calling them "rights" and start calling them "abilities". ;)


I agree that mods might as well have the power to delete - after all, admins can easily undo abuse.


Clear as crystal.

If they remove a message once, and I restore it, they will not be able to remove it again - thanks.

In brings up quite a few questions about what happens to replies, etc.

This is definitely why "split and merge" are needed hand-in-hand.

While I would be happy with a one-by-one approach, I can see that others wouldn't, so I suggest a "split and merge" mode: When you enter it while viewing a thread, there's a message "Select messages to split into separate thread and press Split" there are checkboxes next to every message, and a Split button at the bottom. Obviously it's an admin/mod-only function.

I haven't actually ever looked into how the source handles the relationship between messages in a Thread, so I probably should do that sometime.


"In both features, there are no changes to the options available for the admin user group or rollback user group."

Then someone messed up.

As an admin, I'm only seeing "edit, history, view source" on someone else's Message Wall comment.


Wikia allow admins to block for any reason, or no reason at all, even if they do not have policies.

(As DEmersonJMFM mentioned, the exception is if the admin violates the TOU.)


From day 1, I've disliked the ability for any user to remove other's posts, so I see this as a feature that should have been there from the beginning: something being fixed, not something being changed.

While I agree in general that loss of basic rights is a bad thing, in this case I think of it less as "loss of rights" and more like "gain of protection".


You know, I've never looked specifically into it, but I believe that instant delete is possible through the Message Wall API.

I mean "thread" delete, not the "page" delete.

So I think it might be possible to write a script that adds an "instant delete" option to the drop-down. I'll add this to my to-do list and look into it later.


At the heart of this issue is whether users "own" their Message Wall and profile pages: they don't, and have no inherent rights regarding them.

  • Fair admins are allowed to set policies regarding Message Walls and profiles, including granting users rights over their own Walls.
  • Unfair admins are allowed to to whatever they want (within the TOU) to other users' Message Walls and profile pages.

edit: I've been on both sides of this issue:

  • As an admin who is enforcing existing policies, only to be told "It's my wall, I can do what I want with it"
  • As a user who has had my profile deleted without any policy regarding the content, only to be told "I'm an admin, I can do what I want with it"

Thanks, I see "removed" for thread replies now.


Dragonknight86, that is false.

If it were true, then why would they have to fix it and post this?


You say "bad few" as if people abusing the ability were in the minority, but in my experience, there have been more users who abused the ability to remove threads and replies than people who removed threads and replies for valid reasons.

This update only partially addresses users who think they "own" their messages walls: those users will still attempt to remove messages they don't want, but at least they will not be able to remove the again after an admin restores them.


Silent Mocker, perhaps if you outline a hypothetical scenario that this change would negatively impact, we can all better understand your point of view.

For instance, if someone leaves spam on your Wall, you can still remove it - so you can still effectively manage your wall.


If the primary goal of the rules update is to increase the helpfulness of the chat, then I think that Wikia needs a dedicated central "socialising" chat, and a dedicated central "help" chat.

People who want to help and people who need help can join the "Helpdesk" chat, and everyone else can use the other one.



Removing and deleting a thread (using the normal menu) does not remove it from being publicly accessible, and never has.

Edit: here's an example.

An admin has always been required to fully delete threads, and most admins probably don't even know how to do that. (Of course, most users don't know how to view soft-deleted threads, but if it were my identity, I would not want to risk it.)

(I've been reporting "Threads marked as deleted are publicly accessible" to Wikia staff for a very long time, but it has still not been fixed.)


As it says in the post

Regular users can - Remove, restore, close and reopen threads on their own Message Wall

If a spammer posts something on your wall, you can still remove it.


Admins are intended to have all the abilities of moderator, and to grant/remove the moderator right. (This should be fixed now, if not, report it.)


Yeah, I spotted that too, perhaps it was to allow rollback users the ability to remove vandalism before they decide to make moderator.

Although it's strange that they hardcoded it as "If you can rollback, then you can also walledit", and not just add walledit to the rollback group.

They may remove that part in future, now that moderator exists.

Edit: I checked Special:ListGroupRights, and the only group that has rollback and not walledit is the rollback group.


Friends don't copy/paste the same canned response when you tell them something useful.


I generally don't care about SEO, but one thing I do do is create lots of redirects for search purposes, and use those redirects as links whenever that term is more relevant in context over the actual page name.

Question: Is there any negative effect on SEO for using redirects?

People have claimed this in the past, but I think that it's a load of malarkey. I've confirmed through monthly googling that using redirects for alternate titles definitely improve google results for those alternate titles, but I did not witness a negative effect for the actual page title in the results.

As far as I can tell, the Canonical_link_element should overcome any problems of a search engine confusing the redirect with the real page title.

Images: the importance of description

Question: Has your research indicated any significance of using a descriptive filename?

Examples:

  • 1234567890.png
  • Queen_of_England.png
  • Queen_of_England_at_a_the_opening_ceremony_of_the_Olympics_in_London.png

it's always better for SEO to have it set up correctly the first time.

Please define "correctly".

I'm talking about creating redirects for valid alternate names for the subject.

  • "Steve Rogers" and "Captain America" are the same person.
  • The Marvel wiki names the article "Captain America"
  • And has many redirects to it, including Steve Rogers and Steven Rogers.
  • These redirects are actively used, with 64 and 309 links respectively. So Google is definitely crawling those links.
  • These redirects are valid alternate names for him that people may search for, it is not a question of having it "set up correctly the first time."

This exists: Special:Top/most_visited. It doesn't say how many visits, but it is ordered by most visits.

The first few pages from that list are also displayed in the "Top Pages" box on Special:Search.


For example, infoboxes are the first thing on most wiki pages, but you never see them or their content in google page descriptions when searching.

I just specifically searched for something that was only in the infobox and not elsewhere on the page, and the google summary included content from the infobox.


How about this?

The order is slightly different, but appears to be legit because the pages I would expect to be near the top are still near the top.

And since you did ask about specific pages:

edit: It would appear that this is the most popular of all time, and only counts total page views, while Special:Top is obviously "recently popular"

edit: Some pages created months ago do not appear in that list, even when using wkpage - so it looks like this isn't going to help much.

Here's the limit for Fallout

edit: It's more out of date that I first assumed:

  • Articles created before 2012‎-09-01 are listed
  • Articles created after 2012‎-09-28 are not listed.

The strange thing is that the "last edit date" is current for all articles, it simply doesn't list articles created after a certain date.

Edit: Those dates weren't for the fallout wiki specifically, I tried to download the fallout database dump to verify, but it is truncated and does not contain all articles.


Facebook plugins, such as the Like Box, are not displaying.

20px-Facebook_logo_thumbs_up_like_transparent.png 2 people like this.


I think it would make sense to extend the rights of the moderator group to include all blog and article comments.

edit: I would also want to let them edit blog posts, so they can moderate better everywhere, and so there's less that requires admin attention.

(I see the moderator group as a "half admin" group.)


It's ridiculous that a single thread post can't be deleted from public view. Even "deleting" the thread won't take it off maintenance reports.

I agree that it is ridiculous that the standard "delete" in the dropdown menu does not really delete it.

However, it is possible to "really" delete it: see Thread:788622 for an explanation.

Edit: for the record, I asked if it were possible to assign certain rights to a specific namespace, and it's not.

So you couldn't just enable the moderator group the right to "really delete in the Board_Thread and Wall_Thread namespace"


Edit: I agree that it looks pretty shoddy.

  • In addition:

Agreed, the vertical alignment is messed up, the background is unspecified, and the change in colour for the games hub from #8ca038 to #94d11f makes it harder to read on a white background.

Compare: games / games

Or better still:
Games hub logo changes

Before, the base of the [] was aligned with the base of the word wikia, now, it looks like the logo says wikiagames


If it was the same issue that DEmersonJMFM was reporting, then I wouldn't need to post anything, as he already reported it.

I've added a preface to my previous comment to make it more clear that I was agreeing, AND making additional comments as to the shoddiness.


This part:

 
/* Changes to Wikia Positioning due to Removal of Hubs Entry */
.wikia-logo {padding: 0 20px; !important; }
.wikia-logo img { margin-top: 4px !important; }


Yes, you can already modify the new skin using CSS.

edit: But I don't see what this has to do with this week's tech update.


I'm not a wikipedia editor, but:

It is difficult to assume or acknowledge all religious beliefs as being correct or possibly correct.

I don't think wikipedia assumes or acknowledges anything as true. Ideally, it simply describes.

if you think about it religiously there is no middle ground.

If you look at wikipedia from a religious point of view, then it is you that is not being neutral.


I heard back from Wikia Staff, apparently that was disabled in Sept 2012.


Some progress, but I think I'll just keep it hidden completely.


How exactly would you like it to look and behave?

edit: If you, or anyone else, describes how they would like it to look, or posts an image (mspaint, photoshop, ascii, scan of a drawing), of how they would it to look - I'll make it happen.

(Incidentally, it's completely possible to put a search bar back where it was.)


"There should be an option to toggle whether or not the nav bar follows the screen when scrolling (it still doesn't look very integrated, even if it does go transparent)."

Agreed.

There's always .global-navigation { position: relative; }, but I think all users should have the option in their preferences, not just those who want to add it to their CSS.

"...colour..."

It used to be a white logo on a black background. Now it's a black logo on a white background.

Did anyone ever complain about the black bar clashing with anything? Black goes with everything, white doesn't.

Both the intention, and the problem, is for the bar to stand out more - so there is no possible compromise.

"There should be an option for all users whether to use the square frame or a circle frame for your profile picture."

Yeah, that circular avatar is kinda weird - I checked and avatars still cannot have any transparency, so real circular avatars still aren't supported.

While many avatars just have "background" in those corners, the content of mine goes all the way to the corners.

And it just doesn't make sense to make it circular in the header - because my avatar has nothing to do with wikia's branding.


Y'know, I didn't notice that at first, but you're right. That's going to result in a lot of mis-clicks.

I thought the intention of this bar was to be more like other websites - but doesn't just about every site have the login link as the last thing in the nav?

Maybe having the login link as the second last element is Wikia's way to prove they're not just copying youtube.


Ah, I had noticed the 70k fewer views yesterday and wondered what was up - thanks for mentioning it.


I agree.

  • Q: Why not just cite pixels?
  • A: Because citing percentages is a well-known trick to make your numbers look more impressive.

Compare:

  • The number of editors on the wiki this week has increased by 100%!
  • The number of editors on the wiki this week has increased by 1. There was 1 before, and 2 now.

If "We reduced the height by 9 pixels." is accurate and not just an example, then the reason for saying "17%" instead of "9 pixels" is because 17 is bigger than 9, so looks more impressive.

It's marketing 101.


Wait, redirects don't show up in the link suggest any more?

Tested. Yep.

I have mixed feelings about that.

  • It will stop people from linking to redirects which were created for searching purposes. = good.
  • It will also stop people from linking to valid redirects. = bad.
  • It will cause confusion for people who don't know the name of the article. = bad.

How about display both, but display the article first? That way, if they didn't know the exact name of the article, it is presented to them, but if they wanted to link to the redirect, it is also suggested.

For the case of search suggestions, I agree with just showing the redirect name - showing a completely different name will only cause confusion. If they cannot be implemented differently, then the solution of displaying the article first and the redirect second works here too.

This also solves the problem of "the article name doesn't link to the section", because the user can select the redirect itself if they want to go to the section.


Example:

On a video game wiki I contribute to, all missions have an opening and closing cutscene, which both have names, so all missions have 3 names associated with them, which are displayed prominently on the screen in one of the games, and are listed elsewhere in another.

So, we have the article named after the mission, and two redirects to it for the names of the cutscenes. (edit: Which ideally link to a section regarding that cutscene.)

Because the name of the first cutscene is displayed on-screen before the name of the mission is, this leads to a little confusion about the name of the mission, so people would often search for the name of the cutscene instead of the name of the mission, and may not even know the name of the mission. The cutscene and mission names are usually puns or other wordplay, and have little relation to each other, so typing one phrase and have another appear is confusing to someone who doesn't know what's going on.

I've also created a range of other redirects to improve searching, but which shouldn't be used as links, in most cases these do resemble the destination title, so having the destination name listed before the redirect should be a good prompt for people to use the "correct" title instead.


In summary: Yes, it's helpful to suggest the destination, but not everyone searching for a term will recognise the name of the destination, so listing the redirects after the destination would avoid confusion.


It's a standard ploy when haggling: make the first offer more extreme than you would accept, so you can change the offer so that it seems you have compromised.

There will still be people who preferred the old style, or who want it to be smaller, but now Wikia can, and will, say "But we compromised". "We listened to your feedback, and made adjustments accordingly."


Well, recent Wikia changes mean that it's "impossible" to apply CSS or JS to the preferences page. (And JS is required to add options to the preferences page)

I say "impossible" because it's not really impossible. It's just impossible by default. I worked around that restriction and my preferences page loads site and user CSS and JS for any user who wants it to.

Still, what would be the point of that? If I made a CSS/JS solution to change the navigation, why would you want an option in preferences? That's an unnecessary complication.


edit, in response to the image:

Do you actually use the hubs menus? Part of the reason for the change was that the hubs have changed from 3 to 7.

I can do everything in that image except change it back to 3 hubs.


I have noticed a tendency recently for many sites to not have placeholder text in their search boxes.

I personally find blank search boxes harder to locate - not so much of a problem with huge-search-bar-at-top-of-page deals, but I still think "blank by default" is a bad design choice.

Youtube, for example, currently doesn't - I don't know if they ever did. But the difference with youtube and google is that they are search-centric sites, and the search bar is focused by default, so there's no need for the user to "look" for the search bar.

  • Q: "Can we do that with this too?"
  • A: Not currently.

Jspoelstra, it is rather far down in the comments now. It may help to start a forum thread asking for feedback.


User:Energy X linked to Special:AdminDashboard for a reason.

The same number is sent in both of the the daily views emails.


"...will only confuse users searching for something they've actually spelt correctly in the first place."

Which is exactly my point, if the user has typed a valid redirect correctly, such as a cutscene or minor object name, it will only confuse them to show them the destination title instead of suggesting what they have actually searched for.



You can read why here: User_blog:Daniel_Baran/Search_Developments:_Big_Picture

edit: and here: User_blog:Dopp/Updates_to_How_We_Search

My assumption at the time was that they wanted people to see the ads on the search page, and it also increases raw pageviews, which is good when advertising wikia to advertisers.

We had to fight to get them to just add the option to let us keep Go search at all.


Technically, maybe. Special:ListGroupRights lists the rights assigned to each group.

The "moderator" group has these rights:

  • forumadmin (forumadmin)
  • notifyeveryone (notifyeveryone)
  • wallarchive (wallarchive)
  • walledit (walledit)
  • wallmessagemove (wallmessagemove)
  • wallremove (wallremove)

Too bad they don't have real descriptions. I imagine that "wallremove" is "remove" and "wallarchive" is close - but that's just a guess.

Ask Wikia Staff to give those rights to the "users" or "autoconfirmed" group.

If not, then yes, there's no reason why an admin couldn't just give everyone the moderator right if they wanted to do that - you should probably mention to Wikia Staff that that is your Plan B, it might help persuade them to just re-assign the rights to all users.


Customers? Customers are people who pay for goods or services.

You pay Wikia for neither.

Wikia's customers are the advertisers, they pay Wikia to show you ads.


It is completely possible to re-add the old search bar. Of course, it helps if you copied it before they took it away.

"...javascript..."

Try this:

  • Disable javascript in your browser. In Chrome you can click the icon in the address bar and disable it in the menu there.
  • Go to any Message Wall page
  • Click in the "What's this about" box.
  • Witness that the placeholder text is not javascript based.

The placeholder attribute is a HTML5 feature.


There's no deception if you know what the value was before a change.

And most wouldn't. I don't.

17% and ~9px is not the same information.

I didn't say it was a conspiracy, I said it was marketing.


Is the "edits" column insanely high for anyone else?

If not, then I think that null edits are being counted in that column... I'll do a test.

Edit: Confirmed, null edits are recorded in the edits column. (I made 158 null edits to my test wiki)


"For me, the Go-search as you call it is clearly the standard. You just have to type 3 characters and there's already a result."

We call it that because that is the name of it. Look in your preferences: it's called "Go-Search" there. (Mediawiki:wikiasearch2-enable-go-search)

You appear to be under the impression that "Go search" refers to "Search suggestions". It does not. "Search Suggestions" refers to "Search Suggestions"

Go-search refers to typing the exact name of an article or redirect, pressing enter and going directly to the article/redirect instead of Special:Search.


The problem I've always had (and which you'll probably find me saying in the comments of the blogs I linked) is that I type much faster than the search suggestions return results, so it's much faster for me to "type the entire name of the article and press enter" than it is for me to "type half the name, wait up to several seconds, press down, press enter."

I agree that - if Go-Search were the default - there should be some way to easily "search" instead of "go" - this could easily be solved by having the first suggestion be "search for X", because "It's not difficult to click on the (search link) in the dropdown if that is what you really want."

However, if we make the assumption that Wikia want users to view the Search page at all times due to the ads there, then there's really no point discussing which is better for us.


Yes, I realise that that is the scope of the user rights changes that this blog post is about.

Completely separate to that: thread deletion should be improved to be more like actual deletion.


I finally remembered where I left this:

$('#WikiaRail').prepend('<form id="WikiaSearch" class="WikiaSearch" action="/Special:WikiaSearch" method="get"><input type="text" name="search" placeholder="Search this wiki" autocomplete="off" accesskey="f" value=""><input type="hidden" name="fulltext" value="0"><input type="submit" style="display:none;"><button class="wikia-button"><img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" class="sprite search" height="17" width="21"></button></form>');

Unfortunately, that doesn't attach the suggestions trigger, so it's a little less useful that it used to be. I should probably look into enabling that somehow.

But if all you want to do is type a word and press "enter", then that'll work.


Thanks for the reply.

How do we change the placeholder text?

edit: Mediawiki:global-navigation-local-search-placeholder, which will be live tomorrow.


Again, Wikia will make the changes to it we want, but only if it doesn't affect their intentions.

Well said.


I believe that this is good evidence for linking to redirects when appropriate.

Personally, I've found that even deleting unused redirects effects google results, but I wonder what would happen to that google result if they removed all links to the Darth Vader redirect.


For anyone wondering, the global nav update does includes changes which may break any custom personal CSS - this is entirely dependent on what CSS you're using.

Amongst other things, the new style for ".global-navigation .table-cell" is more specific than addressing only an ID, but prefixing all existing selectors with ".global-navigation" will fix most of them.

Here's the changes I made, other people's required changes will likely be different.


Wikia apparently really want the avatars to be round, so have replaced this:

.AccountNavigation > li .avatar-container { border-radius: 50%; }

with this much more specific selector:

.AccountNavigation .account-navigation-first-item .avatar-container.logged-avatar { border-radius: 50%; }

There is still no scrollbar in the notifications panel:

  • Before, this meant you just couldn't access notifications that were too far down until you viewed the top notifications.
  • After tomorrow, the "Mark as read" button will be at the bottom of the notifications, and inaccessible if there are too many unread notifications.

This will enable the scrollbar, now and after the update:

#GlobalNavigationWallNotifications #notificationsContainer {
  width: inherit; /*inherit required due to <1023px change */
  max-height: 650px !important; /* inline style periodically reverts to auto */
  overflow: hidden;
}
#GlobalNavigationWallNotifications #notificationsContainer>ul {
  overflow-y: auto;
  height: inherit;
  max-height: inherit;
}

You will still need to "scroll down" to access the button, but that's better than it being completely inaccessible.


You said: "By removing this feature it seems to indicate to me that Wikia distrusts non-admins/non-moderators judgement."

BertH said: "A common feature request, especially from very active communities, has been for a better way to moderate forum activity."


No.

Yesterday:

<div class="avatar-container">
<img src="http://vignette4.wikia.nocookie.net/common/avatars/7/77/3403151.png/revision/latest
/scale-to-width/36?format=jpg" width="36" height="36" class="avatar" alt="452"></div>

Today:

<div class="avatar-container logged-avatar">
<img src="http://vignette4.wikia.nocookie.net/common/avatars/7/77/3403151.png/revision/latest
/scale-to-width/20" width="20" height="20" class="avatar" alt="452"></div>


Apart from shrinking, I'm seeing:

  • The "Start a Wikia" button is moved
  • The Wikia logo does not trigger the Hubs menu
  • The "Search this/all Wikia" label is gone and replaced by a dropdown on the magnifying glass.
  • There is now placeholder text in the search field.
  • The "mark all as read" button is at the bottom of the list (and inaccessible by default if there are too many notifications)

(edit: apparently the "editing a blog comment twice in a row causes it to lose the previous changes" problem has still not been fixed.)


If by "as before.", you mean "before today's update", then my response is:

No, there was not a scrollbar yesterday.

If by "as before.", you mean "before the nav header was changed at all", then my response is:

I don't remember there not being a scrollbar then, so there either was a scrollbar in the old notifications list, or the smaller notifications meant that this was not so much of a problem.

I wish there was some way to temporarily view the previous nav and verify, but there isn't, and although I had been attempting to keep one last tab open with the old nav, my browser crashed a few weeks back.

I already reported this, you already replied, and I already told you there was no change:

I am not the only one who has reported this:

(It's kinda hard to find people talking about it, since most uses of the word "scroll" are regarding the behaviour of the nav when you are scrolling the page, and most uses of the word "navigation" are talking about it being in the user menu.)

Edit: I checked in firefox, and this is not just a Chrome issue.


A couple more comments regarding this:


Here's the link: User_blog:Rupert_Giles/Global_Navigation_January_Update


MediaWiki:Global-navigation-local-search-placeholder


Sorry, I hadn't realised that laptops weren't welcome on Wikia: I don't use a mouse, I have a touchpad, the only way I can scroll is by clicking a scrollbar, or using arrows/home/end/pgup/pgdn - and those don't work in the notifications panel, they only scroll the page, but scrolling the page is no help: because the header is fixed.


And I see all of the CSS and MediaWiki has been unchanged

That isn't true.


However, please also remember that only you see the avatar in this presentation

Others see my avatar as round in their notifications.


you still didn't give us any option on changing the bar's background color

Wikia's goal is for the bar to stand out, allowing wikis to change the bar's background color would not meet this goal.

it is kind of distracting for me

If it is distracting, then it is a success.


Admins have access to really deleted pages, either through Special:Log/delete, or Special:DeletedContributions.


(I'm not singling out the person directly below, I've seen this coming up multiple times)
tl;dr: If I wanted my avatar to appear as round in other users' notifications, I would upload a round avatar.

I've noticed a few people requesting the avatar rounding be reduced, but to keep some of the rounding. I don't see any reason for there to be any rounding at all. If you want to mess with the the Wikia logo, fine, but leave people's avatars alone.

Personally, mine has a tiny bit of a rounded border anyway, so could survive up to 20% before being noticeable, but there's really no reason to do it at all: if someone wanted their avatar borders rounded, then they can round their borders themselves.

I think it should be "border-radius:0" = no rounding at all, as is the case with avatars displayed all over the rest of Wikia.

What you should do is support transparency in avatars, to allow people who want to have round avatars, or rounded corners, to do it themselves it a way which wouldn't clash with the background of other wikis.

"What's the big deal, it's just round for you personally in the header, it's not like we cropped your avatar everywhere."

I am not the only one seeing my avatar being rounded. If I leave someone a Wall message, or reply to a thread they are following, they see my avatar as rounded in their notifications.


Yes, I can, and have, fixed it for myself: User:452/global.css.

I'm sorry that I was unclear that my concern is how other users see the avatars of others. (I've edited my post to make that more clear from the outset.)

I suggest you continue reading the comments to find out "how to change the name of the wiki in the search bar", because I've linked the appropriate mediawiki page at least twice.


A few other people have mentioned something similar, and I suspected something was wrong, but your comment all-but-confirms it.

That does not describe the behaviour I am seeing. The notifications panel shouldn't be hard to move the mouse to.

Could you take a screenshot of the expanded notifications?


also, we are now prone to hover mishaps when opening notifications. the whole menu closes before my cursor even reach the notification it was supposed to click....

Please upload a screenshot of the expanded notifications menu, I expect that you're not seeing it in the correct place.


Thanks for the screenshot Dragonjet, I see what you mean now.


How about link text?

Back in the old days, it was pretty important that links used meaningful text, but I'm not sure if it still is.

I see a lot of instances of random links in sentences, such as "Following on from the [[Name of previous mission|previous mission]]".

Is it still better for SEO to say "Following on from the previous mission, [[Name of previous mission]]"?


The fact that they cannot please everyone does not mean that people should not give their feedback.


edit: I read that wrong and mentally switched the words "increase" and "decrease".

Either way, I agree that how it currently works needs work.


I snuck a look at the preview yesterday, and noticed how clunky the change looked, but I figured it was some issue with the preview, but I'm still seeing the same behaviour live.

For me, it isn't even changing to transparent right now: the Wikia, Hubs and Start buttons are disappearing (but reappear on hover) and the search and user menu are still visible.

The bar is staying white and only sometimes turns transparent, and right now isn't doing it at all.

I don't understand the mechanics of this failure at all.

(the link I'm using - my user customisations are not to blame. - and the same thing happens when I'm logged out with adblock off)


And he's she's asking that instead of a compromise, to simply allow two options, "light" and "dark", because the compromise doesn't satisfy either group.

edit:

Example time.
  • Person A order a glass of milk
  • Person B orders a glass of cola
  • The well-meaning waiter (who does for fully grasp the needs and desires of the people he is serving) brings them a pitcher containing both milk and juice, and two empty glasses.

Not all compromises are like this, of course, but this serves as an example that when two people want different things, it is not always a good idea to mix them.

If the waiter, Wikia, simply serves each group both what they individually want - a glass of light milk header, and a glass of dark cola header - then both groups would be individually served better than serving them a mix of both.

A compromise entails mutual concession. There is no need to make a compromise between milk and cola.


Is anyone particularly surprised that the view counter is 0 again today?


Is this why the images in Template:Cc-by-sa-3.0 are broken wikia-wide?

edit: fixed url.


I never knew about "600x200x10-imageName.jpg", and "v,000000,600x200x10--20,600,10,100-imageName.jpg"

In what circumstances were these used? Are these documented anywhere?


Special:ShortPages confirms that there should be 64 pages. I suggest waiting a while. The count usually syncs a few hours before the daily SpecialPages update. (edit: for me, but apparently it syncs at different times on different wikis, completely unrelated to the daily SpecialPages update. In any case, it probably syncs once every 24 hours on every wikis, so "waiting a while" still works.)


No, you are not.

I reported this earlier, and Wikia Staff have confirmed that they're working on a fix.


Here's the exact same link again: Template:Cc-by-sa-3.0


Community.wikia.com Template Cc-by-sa-3.0

Each of these say "Unrecognized request path! See https://github.com/Wikia/vignette for documentation."


I'm not quite sure I understand the problem.

I use JS to change the vignette URL in order to adjust the size and it works perfectly. In fact, it's even easier than the old URLs, due to the ability to specify the height in the URL instead of just the width. (Exotic URLs I never knew about notwithstanding)

Could you give an example?


I agree. I don't recall ever seeing a thumb rendered like that.

Luckily, some wikis still use the old format, so we can check:

http://img2.wikia.nocookie.net/__cb20140402145704/villains/images/thumb/4/4c/Mr_Blonde_Reservoir_Dogs_Video_Game.jpg/180px-Mr_Blonde_Reservoir_Dogs_Video_Game.jpg.png is supported, but I don't see where that would be used.


I also encountered a few errors similar to this when moving pages yesterday, as well as a few others when editing. But these kind of errors have become so frequent I've just started ignoring them.


Community.wikia.com_Template_Cc-by-sa-3.0.png << example image, content is irrelevant.

Open your browser console, and paste this:

$("#comm-text-797391 img").attr("src", $("#comm-text-797391 img").attr("src").replace("/100", "/300"));

Obviously, this is just an isolated example, but if you give me a specific example which does not work for you, I will make it work.


Thanks for the advice, but I've reported it to Wikia several times in the past.

I'm a vocal proponent of "reporting all errors", but the thing is, we shouldn't even need to in this case: the fact that there is an error message being displayed means that it should be logged. (I checked the source on github, and it doesn't appear that it is logged.)

Unexpected behaviour without an error is one thing, but when an error message is shown, the software is obviously aware an error has occurred, so there is no reason for not logging the error.

When there's an error as a result of a form submission, as this particular form of error always is, the software also has access to all of the relevant information to tell the techs exactly what the user was doing at the time of the error, meaning that there is no information that the user can provide that the software does not already have access to.


Great suggestion, 5678!


Before and after


Before:

<img src="...scale-to-width/20" width="20" height="20">

After:

<img src="...scale-to-width/50?format=jpg" width="30" height="30">

Thanks SuperSajuuk, that solution works for me.

(I had already noticed that moving the cursor away from the bell and back again worked, but hovering over "loading notifications" takes less time) Apparently when I was moving my cursor away, I was hovering over the "loading notifications" message for a split second, and triggering the notifications to load.


As there was a "loading notifications" message in the previous iteration, I believe that the current behaviour is a bug.

The reason the bug is resolved by hovering (either over or out) is because the focus is being changed, and the script is checking (again) whether there are notifications available.

Without looking at the source, I assume that the reason it is not being automatically updated when they are loaded via a callback function is because the callback function is using the former DOM order, and someone forgot to update it with today's changes. (Off with their head.)


After looking at the source, I was (mostly) right, the update event is attached to the wrong element. (I don't have a copy of yesterday's DOM to compare.)

HTML Before:

<div class="account-navigation-container table-cell">
  <ul id="AccountNavigation" class="AccountNavigation table-cell active">
	<li class="account-navigation-first-item">
	  <div class="links-container"> [...] </div>
	  <ul class="user-menu subnav">
            <li id="notifications">

Before, the very first element in the navigation menu was named #notifications

HTML After:

<div class="account-navigation-container table-cell"> ... </div>
<div class="notifications-container table-cell" id="notificationsEntryPoint">
  <div class="bubbles">[...]</div>
  <a class="notifications-entry-point"></a>
  <li id="notifications" class="notifications-container ">

After, #notifications is a subelement, #notificationsEntryPoint is the top element.

Javascript, now:

this.$notifications = $('#notifications');
this.$notificationsEntryPoint = $('#notificationsEntryPoint');
this.$notifications
  .mouseenter( this.proxy( this.updateCounts ) )
  .mouseenter( this.proxy( this.fetchForCurrentWiki ) );

BZZZZZZTT, WRONG.

Once someone changes this.$notifications to this.$notificationsEntryPoint, and then tests it to make sure it works properly before it goes live it should work as it should.

edit: Yep: https://github.com/Wikia/app/commit/82e33187e0bdcb7823ecc0bb2431181fef4a7bc7


This CSS will simulate the correct behaviour for now:

.notifications-container.active #GlobalNavigationWallNotifications {
  display: block;
}
#GlobalNavigationWallNotifications.show {
  display: none;
}
.notifications-container.active #notifications {
  margin-top: 0;
  height:0;
}
#notifications {
  height: 36px;  
  width: 72px;  
  display: block;  
  margin-top: -36px;
}

What it does is expands the area of the #notifications element to cover the bell icon, simulating the mouseover event being in the correct place.


It's not just happening to you, I've seen this since it was first introduced.


Because youtube uses a bell for notifications, and almost every aspect of the global nav redesign is based upon copying youtube's header.

It is mostly less of a direct copy since the updates, but they just couldn't help copying youtube's bell also.


When you have unread notifications, fetchForCurrentWiki() is called on init, and does not rely on the mouseenter trigger.

if (data.count > 0) {
	this.$notificationsCount.html(data.count).parent('.bubbles').addClass('show');
	this.fetchForCurrentWiki();
	this.$wallNotifications.addClass('show');
} else {
	this.$notificationsCount.empty().parent('.bubbles').removeClass('show');
}


Special:MostimagesInContent has appeared on Special:SpecialPages and Special:AdminDashboard, but the search can find absolutely nothing about it.


I'm sorry that Rupert Giles ignored your original question and responded to the unrelated issue that the rest of us were having.

I've left you a message on your Wall to test your notifications:

  • Do you get a number on the bell?
  • What happens when you put your mouse cursor over the bell now?

For anyone who doesn't like the bell, here's the previous icon:
 
.notifications-container .notifications-entry-point {
    background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABYAAAAUCAMAAAC+oj0CAAAA8FBMVEX///+srKyoqKiwsLClpaXHxsbZ19fDwsK5uLjZ19fX1dXZ19fZ19fQz8/DwsLX1dXZ19fMy8u+vb3Qz8+1tLTMy8vHxsa1tLS1tLTZ19fZ19ewsLDU0tKwsLDDwsLZ19fDwsLDwsKsrKzX1dWsrKy+vb2+vb2oqKioqKioqKi5uLi5uLilpaWlpaW1tLS1tLS1tLS1tLS1tLTU0tKwsLCwsLCwsLC5uLisrKysrKysrKysrKy1tLSoqKioqKioqKjHxsalpaWlpaWwsLCsrKzX1dXMy8u+vb3Z19e5uLi1tLTU0tLDwsLQz8+oqKjHxsYZoMgpAAAAQ3RSTlMAAAAAAAAAmeTP56ISlpZLRZaWSxJLludLSEuHlpbe+T8AloFgaQADpSdOAAafTuqiAwBLD8k2exXV+Qm6G+HMUSSBzIFtOQAAAKhJREFUeNp9zcUCglAURdGDGIjd3d3dLdj1/38jep/Km7iGe7Lxn92WOn5Z3WByOz0ZTPzCAeO4cWAmnj0HEetrEg0+OJDfD5fzygEtet4DB7TwjU56EmgR8M/PP6EwaLE2MTFFURIAaJG0kHQmq6p5APyqUCyV7xUAEveq1lBvQNNs6V7tThdEFPsDbTMUGRBBEMYTdToTGBCDZrFcGT5AjC+brfGD6hM7GEgV8an3twAAAABJRU5ErkJggg==");
}

(Thanks to User:RyaNayR for posting this 6 months ago.)


Also, the line-height is set to equal to the height, which is why there is a huge gap above the date, and why when the title stretches to 2 lines, then date overlaps the next title.

However, there's no way something that obvious could have gotten through testing without being noticed, so I've concluded that this is exactly how Wikia want it to look.


When I click "create a new interwiki request" I get "You do not have permission to edit pages in the Community_Central namespace.", but someone else was able to edit it 2 days ago


At the time of my previous comment, it was empty, but it's now populated.

Basically, it's Special:MostLinkedFiles for content namespaces only?


Sorry I missed your reply earlier.

Replacing that image works exactly the same.

$(".AccountNavigation .account-navigation-first-item .avatar-container .avatar-container .avatar").attr("src", $(".AccountNavigation .account-navigation-first-item .avatar-container .avatar-container .avatar").attr("src").replace("/50", "/100"));

And requires these additional steps to set the dimensions:

$(".AccountNavigation .account-navigation-first-item .avatar-container .avatar").attr("height",100);
$(".AccountNavigation .account-navigation-first-item .avatar-container .avatar").attr("width",100);
$(".AccountNavigation .account-navigation-first-item .avatar-container").css("height",100);
$(".AccountNavigation .account-navigation-first-item .avatar-container").css("width",100);

Yes, removing the extra / fixes it on a single wiki.

As these /s are there by default, obviously fixing them one by one is not the optimal solution.

There are many wiki problems that can be fixed on a single wiki, but that doesn't mean there is not an underlying global problem which needs to be fixed.


Great suggestion, but it is Wikia's intention for the search bar to be as "in-your-face" as possible.

So, to them, your comment just says "Success!".


A lot of the problems would be mitigated by allowing Mediawiki:Mobile.css to style, or hide, unruly elements.

If you're concerned about bandwidth, limit the maximum allowed bytes.

edit: Incidentally, the mobile stylesheet already includes .hidden {display:none;}


Tupka217's suggestion is great.


Help:JavaScript_and_CSS_Cheatsheet


The chat "doesn't support other skins".

You can get around this by going to http://community.wikia.com/wiki/Special:Chat?useskin=oasis

I don't see why they don't just have the chat ignore the user skin preference and just automatically use the oasis skin by default instead of needing to specify it.


Forum is graduating from Wikia Labs

Does that mean all usability issues I've reported are firmly in the "don't care" pile?


So long as Wikia gets enough ad revenue, it will continue.

And putting ads in the content will likely increase their income. If fewer users use the site, they will likely just add even more ads to offset it.


We should stress: this is a beta product

Yes, you should. Thanks for the warning.

Hopefully by the time it comes out of beta, it won't look so much like Venus.


When someone is giving feedback about a beta feature, informing them that it is a beta feature and things may be changed is... redundant at best, and likely to discourage people from giving their feedback at worst.

The common response of "it's a prototype!" to the majority of people giving their feedback regarding the prototype venus skin is 33% of the reason I haven't given any feedback about it other than my first impressions, and is 100% of the reason I'm not giving any feedback on this beta header.

edit: And I'm getting really sick of blog comments reverting when editing them, and I really wish that long-standing bugs like this would be fixed.


Woah, the edit summary box is an input again! Better late than never! (I was just looking at those comments just a few hours ago, weird.)

...however, it's not autocompleting for me in the preview right now, maybe it will work correctly tomorrow.
It's a problem with one of my scripts: When an Option element has a value of over 1024 characters, autocomplete stops working.

Anyone using any variant of the "Standard Edit Summaries" or "Standard Preloads" scripts should remember to collapse the right rail and update their CSS accordingly after this update.


...remember to collapse the right rail and update their CSS accordingly after this update.


Speaking of which: someone didn't test section editing with the right rail collapsed. I've been experimenting, but can't find a good place to put the section comment.

Although an edge case, this can happen: http://preview.community.wikia.com/wiki/Community_Central:Sandbox?oldid=1445180&action=edit&section=5

Since it's uneditable anyway, it would probably be best to just hide it completely - it shouldn't be a surprise to anyone to find that the name of the section they were editing is displayed in the edit summary. However, I notice that the maximum number of characters in the edit summary is not reduced due to the number of characters in the section heading, which might cause summaries to be truncated. (I personally hit the limit at least once per week.)

That last paragraph may be irrelevant - currently the section comment isn't added to the saved summary - I'll test it again once the update occurs.

Yep - the the update is now live, and NO automatic comments are added to the summary, including section comments, as well as the standard "Undo revision 1445328 by 452 (wall)"


Additionally, there is a typo in MediaWiki:Wikia-editor-preview-type-tooltip.


Show changes button

I think the "Show Changes" link would look better as a button:


You're right, it does look like cheap advertising, they should replace it with an auto-playing video.


Where are there links to talkpages in the global navigation?


Thanks,

So... it doesn't happen all the time, but it's not just naruto.


I figured it out: When the new forum is enabled, the link points to Message Wall.

It's what each of those wikis have in common, and confirmed on my test wiki.


I agree with this - however, I assume that they were deliberately more 'in your face' than the other buttons because they want people to use them.

Try this in your personal CSS:

.EditPage .module_page_controls .preview_box h3 {
    float: left;
    width: 34%;
}
.editpage-sourcewidemode-on .module_page_controls .preview_box h3 {
    width: auto;
}
.EditPage .module_page_controls .preview_box .preview_icon {
    height: 40px;
    padding:5px 0 0 0;
    margin:5px 0 0 0;
    display: inline-block;
    width: 33%;
}
.EditPage .module_page_controls .preview_box .preview_icon svg {
    height: 24px;
    margin-bottom: 6px;
}
.EditPage .module_page_controls .preview_box .preview_icon p {
    display: none;
}

or even more minimal:

.EditPage .module_page_controls .preview_box h3 {
display:none;
}
.EditPage .module_page_controls .preview_box h3:after {
    content: ":";
}
.EditPage .module_page_controls .preview_box .preview_icon {
    height: auto;
    padding:0;
    margin:5px 0 0 0;
    width: 50%;
    border:none;
}
.EditPage .module_page_controls .preview_box .preview_icon svg {
    height: 24px;
    margin-bottom: 0;
}
.EditPage .module_page_controls .preview_box .preview_icon p {
    display: none;
}

Edit: Good idea, Fewfre.


Kuopiofi, here's your option to remove it:

#EditPageDialog.preview .modalContent .preview-modal-msg {
  display: none;
  height:0;
}

The preview buttons look nice in the classic visual but poorly in the classic source.

I, literally, do not see a single pixel difference between source only, classic source and classic visual.

I each open in different tabs, and they're identical.


You didn't specify that you had the right rail collapsed in source mode.


Well spotted!


The preview button works, but it loads the new preview style: and it's not wide enough for the main page.


Does anyone else notice a change in the font used in diffs (It looks "thinner"), or is that just a side effect of me clearing my browser settings?

edit: Just me, idkwtf is going on. Apparently my Arial font is corrupt or something.

edit 2015‎-07-06: Incidentally, this issue went away when I next updated my browser.


Well, here's the cause of it disappearing anyway: http://report.wikia.net/classchange/index.php/diff/44


You can currently edit a main page to see how it used to look.


Ah, I know that one: File:Strange_gaps_when_editing_blog_comments.png (2013-05-01)

This CSS will fix it:

.WikiaArticleComments .article-comm-form textarea {
  width: 100% !important;
}

But you should also send some words to Special:Contact, so staff will know it's a problem that effects people other than me so they can go ahead and fix it. Tell them to look at Tickets #113129 and #169761


:(


The photos module notifies me of new photos being uploaded, in exactly the same way the recent activity module notifies me of recent edits.

I suspect the reason behind the removal has something to do with the Venus skin.

edit: I also suspect the interaction rate dropped significantly after it was moved below the videos module.


Special:Mostpopularcategories


Do links in other languages currently point to the help page here on the english CC?

edit: Nope, in french, it points to http://communaute.wikia.com/wiki/Aide:Bonnes_pratiques_wikitexte

And adding a link to [[Aide:Bonnes_pratiques_wikitexte]] does not turn red on a french wiki.

So there is no problem there.


SpikeToronto, instead of

http://vignette2.wikia.nocookie.net/central/images/b/b9/Carousel_-_zoom_crop.jpg/revision/latest/scale-to-width/185?cb=20150211232738

have you tried

http://vignette2.wikia.nocookie.net/central/images/b/b9/Carousel_-_zoom_crop.jpg

I don't know if this will work, please let me know if it does.


Does it use "latest" as the destination filename?


The technical reason is because that when your mouse goes over the popup menu, it "leaves" the notification bar.

I agree that it is annoying and that they should change it.

I assume you're right-clicking because you want to open each link in a new tab, if this is correct: try ctrl-click.


Not an issue, still occurs with http://community.wikia.com/wiki/User_blog:Kirkburn/Technical_Update:_March_3,_2015?usesitejs=0&usesitecss=0&allowusercss=0&allowuserjs=0

I'm using Chrome, how about you two?

edit: Confirmed that this also occurs in firefox, but that the notifications menu doesn't disappear until the mouse is moved over the context menu, as the context menu in firefox appears 1px away from the cursor.


Special:ListGroupRights lists what rights they have.

Edit: Since I was beaten while typing, here's the list of what specific rights they have:
  • Can display background tasks (taskmanager)
  • Can manage global blocks and spam filters (phalanx)
  • Delete and undelete specific revisions of pages (deleterevision)
  • Delete many pages at one Wikia, or one page on many Wikia (multidelete)
  • Exempt from Phalanx rules (phalanxexempt)
  • Limit actions that can be preformed for some groups for a limited time (protectsite)
  • Remove a user's avatar icon (removeavatar)
  • View IP actions across all Wikia (multilookup)
  • View private data in the abuse log (abusefilter-private)
  • View the checkuser log (checkuser-log)
  • View user edits across all Wikia (lookupcontribs)
  • achievements-exempt (achievements-exempt)
  • editprofilev3 (editprofilev3)
  • imagereview (imagereview)
  • mcachepurge (mcachepurge)
  • multiwikifinder (multiwikifinder)
  • powerdelete (powerdelete)
  • promoteimagereview (promoteimagereview)
  • quicktools (quicktools)
  • unblockable (unblockable)
  • welcomeexempt (welcomeexempt)

In addition to that:

  • When local admins delete a page which shouldn't be deleted, the community can vote to remove the admin, and Bureaucrats can block them.
  • When a member of VSTF deletes a page which shouldn't be deleted, the community has no say, and they cannot be blocked.

The context of "the community has no say" is in contrast with "the community can vote to remove the admin".

As in: "The community cannot vote the VTSF member off the island".

Staff did not deal with the situation, their response was "These sort of things happen from time to time when people make mistakes trying to quickly resort issues.", and VegaDark has never apologised.


When I go to that page and click an image, only the 8 images on that page are displayed in the lightbox.

edit: Oh, I clicked the arrows, I see what you mean.

I had always assumed that the lightbox was just "dumb" and was retrieving all of the images on the page - which happened to include those in the photos module - but it looks like the lightbox is intentionally retrieving newly uploaded files which aren't even on the page, which is... still dumb.

Here's how it's getting the images: http://runescape.wikia.com/wikia.php?controller=Lightbox&method=getThumbImages&count=30&format=json&inclusive=true&to=20150306101150

I second the request to remove those images from the lightbox, as they make the lightbox less relevant. I personally avoid using the lightbox, because when I want to browse the images on the page, I don't want to see unrelated images like that.

For now, I'm going to try adding *getThumbImages* to adblock. (Yep, that works perfectly.)


This sounds like an awesome feature! Thank you for planning to make it optional via user preference.

Initial feedback before even using it: The CSS-style font-color highlighting looks a lot better than the wikitext background-color highlighting.

Related suggestion: I don't know if it's feasible (due to the extra communication with the server), but marking red links as red in the editor would be handy.


It be might better implemented as part of Link Suggestions.


I've noticed something similar to this, and just sent similar screenshots in via Special:Contact.

Good to know it's not just me!

For me, it happened when I was editing a file embed. (Also, it was inside a template, unsure if that's related.)

The problem in my case is that the highlighting isn't scrolling correctly, which is similar to what your screenshots show: I don't know if you noticed, but the highlighting is in the same pattern on each, just not over the correct words.


We've been working on some tweaks to the Chat feature to improve stability and prevent situations where users could end up appearing as another user - this work is ongoing, but please do send us bug reports if you run into trouble on Chat, as this will help us gauge the success of the work.

Ah, that explains why the accepted format of models.ChatEntry became more strict.


I see no highlighting on that page - is this what you're seeing?

If so, the known issues list says:

  • If an article does not start with highlightable wikitext, or is a subpage, highlighting may be missing.

That article starts with a blank line. A blank line is not "highlightable wikitext". Removing the blank line makes highlighting work normally.


edit: that editor problem is caused by this:

.WikiaArticleComments .article-comm-form textarea {
  width: 569px;
}

I have reported it in the past, and no explanation has ever been given as to why it's not just set to 100%, or why they don't just fix it.

I suggest that you, and anyone else who sees that, report it to Special:Contact.


I haven't experienced any problems over the last few days - but it's a little hard to for me to tell, as the majority of people who used the chat before the constant problems abandoned the chat entirely due to them.


I support the return of the Recent Photos module, but you don't have to type special:NewFiles into the URL to upload photo.

You could instead:

  • Choose "Upload a photo" from the contribute menu on every page.
  • Click the "Photos" link in the "On the Wiki" menu on every page.
  • Add Special:Upload to your toolbar. (Click "Customize", then type "Upload")

Customizable options for this are definitely a great idea. There is most definitely going to be people who want to completely customize this asset

I second this. I looked into customising it with CSS, but unfortunately each of the highlights is completely dynamic.

Instead of using a class for each colour - the way CSS is supposed to be used - an individual class is created for each highlight - this causes a massive amount of duplication.

A basic example

The highlighting for [[{{{1}}}]] is rendered as:

<span id="s0"></span><span id="s1"></span>

With the CSS:

#s0:before {
  background-color:#d9eaf6;
  content:'[['
}
#s0:after {
  background-color:#f5e0d8;
  content:'{{{1}}}'
}
#s1:before{
  background-color:#d9eaf6;
  content:']]\A '
}

How it could be done to allow for easy customisation:

<span id="s0" class="l"></span><span id="s1" class="p"></span><span id="s2" class="l"></span>
#wpTextbox0 .l {
  background-color:#d9eaf6
}
#wpTextbox0 .p {
  background-color:#f5e0d8
}
#s0:before {
  content:'[['
}
#s1:before {
  content:'{{{1}}}'
}
#s2:before {
  content:']]\A '
}

This particular example uses 60 more characters to allow for customisation, and each additional block would require 17 additional characters. My quote template has 36 highlight blocks, so the increase in size to allow block colours to be customised would be around 900 characters. (Or more, I'm unsure how many differently coloured blocks there are.)

I'm unsure whether that's a factor into why it was done the way it was - I don't know whether Wikia attempts to minimise browser memory usage.


Confirmed for both undo and section editing.

Are there any plans to re-attempt the separation, or has that idea been scrapped completely?


"They've" repeatedly, ad-nauseum, stated that Venus is only a prototype. (Even when people are giving their opinion of the prototype, someone always comes along to say "It's only a prototype", despite the fact that the purpose of the prototype was to get people's opinions.)

As it is a prototype, there is no need to "get your wiki ready for it", yet. It would probably be a waste of time, as the design will hopefully change before the next stage of the prototype.

You don't need to worry about getting your wiki ready for it until it's a beta in Special:WikiFeatures - hopefully by that time the ads will be out of the content - otherwise a lot of people won't be "getting their wiki ready for it", they'll be "looking for a new place to host their wiki".


I don't see what uploading has to do with it.

Special:WikiActivity still shows exactly 50 when I set "Number of edits to show by default" to 500.

That number applies to Special:RecentChanges, Special:Log, Special:Contributions and ?action=history (edit: and Special:WantedPages and probably all other "normal" maintenance pages. The reason Special:WikiActivity doesn't use this number is because Wikia invented it.)


Kuopiofi, does this happen on all wikis, or just certain wikis?


I'm primarily talking about the ads before each section heading.

The top right ad has always been there, the ads mixed in with the content have not.

Although I do agree that pushing the infoboxes down is stupid: but, as I said in the comments on the announcement blog post, the fact that people are used to looking for an infobox there is exactly why they are putting the ad there.


Not mentioned in this blog post:

This means that anyone who previously had MediaWiki:Chat.js and User:(you)/chat.js loaded through hacks now has them loaded twice, and all bindings are set twice.


I can't take the credit for that one, User:Digifiend mentioned it last week.


Hey cool, I'm listed as one.

The inconsistency is weird, indicating that it's a per-wiki flag instead of a per-user flag.


edit: https://github.com/Wikia/app/search?utf8=%E2%9C%93&q=poweruser has some info.

* Maintenance script for adding poweruser_frequent property
* for users that have made more than 140 edits in the last 60 days.
const MIN_LIFETIME_EDITS = 2000;
const MIN_FREQUENT_EDITS = 140;

edit: somewhat related, I've been de-personed on http://community.wikia.com/wiki/Special:ListUsers

Mystery solved: I am also a poweruser here: and since there is no "poweruser" in the listed rights, no-one who is ONLY a poweruser is listed when you select all. You have to deselect all in order to display users who are only powerusers.


For anyone who wants to sidestep the problem by adding a "Power User" checkbox:

if (wgCanonicalSpecialPageName == "Listusers") $("fieldset.lu_fieldset tr:last-child").prepend('<td valign="middle" style="padding:0px 2px 0px 1px;"><label for="checkBoxForpoweruser"><span style="vertical-align:middle"><input type="checkbox" name="lu_target" class="lu_target" value="poweruser" checked="checked" id="checkBoxForpoweruser"></span><span style="padding-bottom:5px;">Power Users</span></label></td>');

Which chat, MichiRecRoom?


If it was a chat script problem, then it wouldn't be happening on all wikis.

edit: I've just loaded that Chat.js without a problem, in a chat that was clean.

Are you getting any errors in your browser's javascript console?


Yes, I understood that. My test wikis also have no-one in the chat.

One other thing that you may or may not be aware of is that both Chat.js and the welcome message are cached, so you might be better off testing on a fresh wiki.

Since you mention that the issue is related to chat hacks, it obviously doesn't occur on all wikis, as not all wikis have that enabled. Feel free to enter http://452test.wikia.com/wiki/Special:Chat - No scripts are loaded there by default, so it should work fine for you.

Edit: Good idea checking the loaded scripts via the networking tab. inspector. I personally found the networking tab useful when debugging this yesterday because I could see when each scripts was loaded.


It sounds like you've proven the problem is with third party scripts.

Part of the issue is likely to be that Chat.js is now loaded much earlier than it used to be - as you noticed, it's now doing things before the welcome message appears - and the people who wrote those scripts weren't expecting that, so had their scripts executing immediately instead of waiting for the rest of the chat to finish loading.

I had one such issue in one of my personal scripts, because I was adding a hook to mainRoom before mainRoom was defined. Luckily, that was only effecting me, and the same thing didn't happen in any of my other scripts, because they don't load and run until the chat is fully loaded anyway.


It looks like this MediaWiki.


Link Suggestions still does not display redirects, and so continues to make editing difficult for me: when I'm trying to link to a redirect, Link Suggestions doesn't tell me whether or not there is a "s" on the end - like it used to - so I end up linking to a singular term that doesn't exist instead of the plural redirect which does.

Yes, I could just preview and confirm the link isn't red - but the point is that Link Suggestions used to mean I didn't have to.

At this point, I should probably just turn Link Suggestions off and confirm all links manually so that mistakes like this don't happen again.


Personally, I prefer knowing when I'm in a special statistical group. I assume there was a similar method used to select who received the "Wikia's Top Admins" emails a while back.

I think it's a useful tag for users, and admins, to be able to quickly see who the top recently active contributors are. It could even serve as a convenient short-list for admins who want to promote other users.

Sorting by edit count alone is not always useful as the top contributors by edit count may have been inactive for years.


Yes.


After writing in with this particular aspect, and the question "When will this be fixed", I received this response:

We're planning to work on it this year, but we don't have a date for when it'll be fixed.
(emphasis mine.)

Thanks a lot, Volunteer Developers!


If it didn't state that on that page, ZeroTigress would not have needed to ask that question.

I second (or umpteenth, depending on how many others have asked in the past) the feature request of additional user options such as this.


Work on the stability and performance of Chat is ongoing. Happily, our data has shown a significant all-round improvements. Please do let us know if you run into any new issues!

All chats down.

Ah, and since Chat.js is loaded before the chat finishes italialising, scripts are loaded even though the chat doesn't work. Cool.


Moving the On the Wiki tab from first until last was the one truly positive thing the Venus prototype had going for it.

But the fact that you've said "having two different styles to maintain" makes me hopeful that Venus will not be mandatory, which is fantastic news.


I see what you're seeing.

  • If you load the page with the right rail collapsed, that gap appears, and stays when you expand it again.
  • If you load the page with the right rail expanded, all is fine, but if you collapse it, that gap appears, and stays when you expand it again.

I'm also seeing the new preview images not being centered vertically in the same situation.


Benefits yes, but the bugs are much clearer there too.

  • I don't like the second search box, especially it being mandatory so it's impossible to search using the default search.
  • I don't like how when you click on something towards the edge of the editor window, in centers on that spot: because if you're trying to double-click there, well, try it.

Since Special:CSS was introduced, I've avoided using it, so I don't like the same format being applied to all CSS and JS.


Are you actually logging crashes, or are you still relying on eyewitness reports?


Thanks, I guess Venus has nothing truly positive going for it after all.


2.101.61.147, the source for syntax highlighting is on https://github.com/Wikia/app

SlyCooperFan1, which of Wikia's modifications are not available on github?


I liked them so much I made them my background

#wpTextbox1 {
  background-image: url(http://vignette2.wikia.nocookie.net/452test/images/0/07/Rwp6DxQ.png);
  background-size: 100% 100%;
 }

It's automatically activated on wikis they have paid content for.

So apparently, SpikeToronto, the video ad hosts that wikia has agreements with don't have any videos relevant to the subject of the wikis you use.

Not that it needs to be relevant, video game wikis get videos regarding different franchises. :(


Pages on the same wiki? To my knowledge, they're not page-specific, only wiki specific. I believe they're just randomised.

For instance, this should be the full list of videos for the DC wiki: http://dc.wikia.com/wikia.php?controller=VideosModule&method=index&format=raw - same list is loaded for each page. It's conceivable that the script which picks which ones to display does an analysis of the page content, but I doubt it.

edit: I think that's part of the reason they changed it from "Related Videos" to "Must Watch Videos".


Incidentally, you can get around it by renaming your scripts from .js to .javascript since importarticles doesn't care about the extension.

I did this briefly when they stopped loading site+user CSS+JS for .js pages, until I figured out a workaround.

edit: obviously, wikia.js, common.js, and chat.js can't be changed. ... and it doesn't help for CSS.

And adblocking ace.js prevents the editor from loading.

Well, there's always monobook!


That has happened in the Classic visual editor for a long time. Forever, as far as I know.

The most common cause I've found is when there is a template in a template.


More people have been noticing that Vignette does not support the URLs in the default templates deployed wikia wide: Thread:813175

When will this problem be fixed?


It doesn't matter how great the special search box is:

  1. Open http://community.wikia.com/wiki/User:452/global.css?action=edit
  2. Immediately press ctrl-f: the default browser search opens.
  3. Paste .WikiaBarWrapper

Nothing found, because only the currently visible content of the edit area is actually being rendered.

Note: If you're using a incredibly high resolution monitor, the entire content of that page may already be visible on your screen.


In this update, in classic editor, it is not letting me to go to visual mode!!
~ Shivuraghav5, in the parent comment.

See also: http://en.wikipedia.org/wiki/Workflow

edit: and http://en.wikipedia.org/wiki/Interaction_design (Took longer to find, is more specific to user interfaces.)


wikia != wikipedia


mw.loader::execute> Exception thrown by site: JavaScript parse error: Parse error: Unexpected token; token ] expected in file 'MediaWiki:Common.js' on line 5 Error: JavaScript parse error: Parse error: Unexpected token; token ] expected in file 'MediaWiki:Common.js' on line 5


On one hand, I think that the Visual Editor probably shouldn't fail due to unrelated javascript errors which have been there for years in some cases.

On the other hand, this Visual Editor update is certainly bringing a lot of years-old javascript errors to light, and I kinda approve of causing already-broken things to catastrophically break things in order to call attention to them and get them fixed.

Naru2008, while there is certainly many things that Wikia does make harder, do not blame Wikia for your wiki's common.js mistakes.

edit: btw, I don't see the login box issue in Chrome, so I can't suggest a cause/fix there.


It would be easier to diagnose your problem if you stated who "our" refers to.

edit: If you're talking about http://ouran.wikia.com/, then I'm unsurprised to discover that there is a bug in that wiki's javascript:

mw.loader::execute> Exception thrown by site: createNavigationBarToggleButton is not defined ReferenceError: createNavigationBarToggleButton is not defined {stack: (...), message: "createNavigationBarToggleButton is not defined"}

Oh, I had assumed that Syntax Highlighting would be in Special:WikiFeatures. I hope the user preference is expanded to disable it on CSS/JS pages, as those are the ones I'm finding my workflow slowed the most heavily.


Feedback which I think I've said before, but want to repeat since it's now being activated everywhere:

  • I think highlighting the font-color in the CSS/JS but background-color in articles is confusing, and I think it should be consistent.
  • I think the background-color is more distracting than useful. I've never used this method of highlighting before, but I was willing to give it a chance, but I don't really think it's helping me, and I would personally find it more useful if it was more like CSS/JS highlighting.
  • The ability to customise the colour of each highlight would be nice, and it is not currently possible to do via CSS, because you're specifying the colours inline instead of using classes for each type. As I type this I realise that there may be a hack in the form of .highlight whatever[style*=background-color:#123] { background-color:#452 !important;}, but it would be nice to not have to do that. (edit: hey, for that matter, I could use this to background-color:transparent !important;color:#452;, but it would be still nice to not have to do that.) Ooops, all of that was wrong. I forgot everything I had previously learned about it: you're creating new classes for every single highlight-node, which makes it impossible to use CSS tricks to override them. I could possibly use javascript to detect when each class was updated, and change them, but that would be a lot of overhead, and probably wouldn't play nice with the highlighting script.

New feedback:

  • The debugging comments on the left side sometimes do not update after fixing a problem, and repeat the same error for every line.
  • The debugging comments are often irrelevant, it would be nice if there was an error/warning/advice toggle.
  • Auto-completing quotes sometimes makes mistakes, slowing me down.
  • Updating the highlighting for subsequent lines based on what I'm currently editing creates flashing colours, it would be smarter if the subsequent lines were not updated until I've finished typing the line I'm currently working on.

Unless you wish to turn it off for JS/CSS pages, which you currently cannot.


Kinda like MediaWiki:Edittools?

(Wikipedia's MediaWiki:Edittools contains far more symbols)


I too prefer advance notice, although I recognise that the "Looking Ahead" section kind of addresses that.

But it makes it confusing where people should look for the information, and I believe this will cause many duplicated discussions between "this" and "last" week. (Not that this doesn't occur already, but this makes it worse.)

For instance, when a user notices something change on Tuesday, they will have no place to post about it except last week's blog post, and may receive an answer. Then, when the new post is posted, mentioning Tuesday's changes, it is likely the question will be asked again. Duplicate discussions aren't always bad, but it would be easier to follow - both for users and Staff - if all the discussions about each week's changes were in the same place.

A Tuesday blog post about "Today's updates which just went live, and Thursday's planned updates" (then an edit when Thursday's update occurs) might work a little better - but I'm not sure how convenient that would be for you. I imagine there is probably a reason behind moving the blog post from Tuesday to Wednesday.

The "Looking Ahead" section for big updates would still be a good idea in that case too.


Are the updates still rolling out? Will there be a "All current updates to the Visual  Editor have been rolled out" update to this blog post when they are?

(I'm trying to determine whether a "This bug is still present" report is necessary, or whether I should wait until next week.)


Thanks Kirkburn.




The word "lag" implies a "noticeable and unwelcome delay", but a "when a user types the opening characters of a highlightable section, assume the sentence the user is currently typing is going to close the same section, until they press mouse-button/u/d/r/pgdn/pgup/end/home/tab and then update the highlight" would probably help this situation.

In other words, typing [[ or any other recognised symbol sets state "has opened something", and waits for "]]/mouse-button/u/d/r/pgdn/pgup/end/home/tab" before refreshing any highlighting.

Edit: This would still "highlight the rest of the page" for a multiline template, but would solve it for the common cases of links/bold/italics which are going to be closed very soon.

It would be technically possible to "keep note of what has been typed since opening the element" and extend the functionality to "don't highlight until the cursor is placed outside of the new content", and through that allow for the enter key to be pressed when adding a multi-line template - but that would be a little more complicated, and be useful to fewer people, whereas just addressing the behaviour for links/bold/italics would be useful to everyone.

Edit: additionally, every time the highlight update runs, it uses cycles, and lags on large pages, reducing the number of times the highlight is refreshed is a good thing.


That's a good idea regarding the parameters, that would help more easily notice the problem of using text with = signs, such as youtube links, in unnamed parameters.

For instance:

{{TemplateCall
|https://www.youtube.com/watch?v=dQw4w9WgXcQ
|link=https://www.youtube.com/watch?v=dQw4w9WgXcQ
}}

Incidentally, this is the error from the javascript console on zcrushersstrikeforce:

mw.loader::execute> Exception thrown by site: JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:Common.js' on line 5

Dear everyone and anyone,

If Visual   Editor gets stuck on the "loading" message, then there is an error with one of your site or user scripts. The script probably hasn't been working for some time, and there has been an error message in the javascript console for as long as it has been broken. You should check your javascript console for more information, and then fix it.
The error message will look something like "Uncaught Error: JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:XXXXX.js' on line YYYYYY", where X and Y may be different, and tell you where to go to fix the error.
-Love, 452

OnePieceNation, while it is clear to me that you are expressing your opinion using expressive language, others may not understand that, so in future it may be a good idea if you worded your opinions to just speak for yourself, to avoid people attempting to "refute" your opinion, as if it's something up for debate.

I, for one, representing myself, expected this to be added to Special:WikiFeatures, and do not personally think it was made clear that it would be made active on all wikis in two weeks. If anyone does not agree with this opinion, good for you, it does not make my opinion any less valid.

I am a user who edits CSS and JS frequently, and I personally find the highlighting there to be a nuisance which slows me down, and have send in a request to Special:Contact to disable it where I had previously volunteered to test it, until such time as the user preference is expanded to disable the entire feature.

(edit: reworded "As a user who edits CSS and JS frequently" so that this is not misinterpreted as a statement that I represent all users who edit CSS and JS frequently.)

I would like to hear the opinions of less experienced editors, and find out whether it actually helps them.


Thanks for the link, I had no idea you could specify actual sizes for print like that, that will definitely come in handy the next time I want to print a specifically sized template.


"as it is" == without the ability to turn it off on JS/CSS pages.


I just realised that there was one thing missing in my recap:

Currently:

static public function isCodeSyntaxHighlightingEnabled( Title $articleTitle ) {
	global $wgEnableEditorSyntaxHighlighting;
	return self::isCodePage( $articleTitle ) && $wgEnableEditorSyntaxHighlighting;
}
static public function isWikitextSyntaxHighlightingEnabled() {
	global $wgEnableEditorSyntaxHighlighting, $wgUser;
	return $wgEnableEditorSyntaxHighlighting
		&& !$wgUser->getOption( 'disablesyntaxhighlighting' );
}

Better:

static public function isCodeSyntaxHighlightingEnabled( Title $articleTitle ) {
	global $wgEnableEditorSyntaxHighlighting;
	return self::isCodePage( $articleTitle ) && $wgEnableEditorSyntaxHighlighting
		&& !$wgUser->getOption( 'disablesyntaxhighlighting' );
}
static public function isWikitextSyntaxHighlightingEnabled() {
	global $wgEnableEditorSyntaxHighlighting, $wgUser;
	return $wgEnableEditorSyntaxHighlighting
		&& !$wgUser->getOption( 'disablesyntaxhighlighting' );
}

A good idea in theory, but not all "detected" errors are actually errors.

Perhaps a running counter below the Publish button to say "3 errors, 18 warnings, 123 suggestions" would address this?


Unbearable is right, I keep loading JS pages, pressing ctrl-f, typing a word and wondering the search doesn't work: because I pressed ctrl-f before the "special" search was loaded (and the focus isn't in the highlight area by default anyway), so pressing ctrl-f brought up the browser search, and for some reason the highlight area on JS/CSS pages "hides" content not currently visible, so you cannot search for what you cannot see with your own eyes. (I don't even know where it goes, I tried searching with the inspector, but the hidden content is apparently not even in the DOM, so I guess the page content is being stored in javascript variables or something)

Either that, or after I switch to using the custom search I keep accidentally replacing the term I'm searching for because pressing ctrl-f twice unceremoniously switches to replace mode.

Or, I want to replace variable with "string", so I highlight variable and type "string", which results in: "variable"string". *facepalm*

I'm sure the highlighting is great for beginners to help them understand js/css, but I've long since passed the point where syntax highlighting helps me, so I'm personally getting +0 benefit, +1 lag loading the page, +1 delay any time I want to search, +1 second-guessing myself as to whether I'm even on the right page, and +1 triple-checking that what I typed is actually what I wanted to type.

When I am editing site CSS/JS, the entire wiki suffers when I make a mistake, so it's not just me who this is effecting.

Also, my CSS/JS tabs have been crashing a lot recently, and I'm getting tired of losing my progress.


Monobook is the last place I can edit JS/CSS without being forced to use highlighting+autocorrect+customsearch, so I certainly hope it's left alone.


That pic doesn't load for me, can you give me a link to the wiki?

edit: Found it, http://narutooriginals.wikia.com/, the error is "Uncaught Error: JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:Common.js' on line 538"

I'm a little confused too, line 538 looks fine. edit:... for CSS.

Line 534 onwards is CSS, you need to remove from there to the end of the page.

(Luckily there are line numbers now, but the section I'm talking about begins with "REQUIRED to hide the non-active tab content.")

Or, just undo the last edit to the page


As I said, not all "detected" errors are actually errors.

In addition, I often find that the error marker doesn't go away after I fix an error, and sometimes repeats all the way down the page with the same error, even after it is fixed.

So, preventing me from saving the page after I've fixed the error because the error-detection thinks there is still an error would not be very helpful.

But hey, Wikia already prevents MediaWiki:Wiki-navigation from being saved when it falsely detects a width issue, so maybe they'll implement your suggestion despite the occurrence of false positives.


It must be a problem wtih your template, because embedding the file normally works fine: http://touken-ranbu.wikia.com/wiki/User:452/sandbox

edit: and the problem with your template is that you're linking to "Media:"

As http://www.mediawiki.org/wiki/Help:Images states, "The alternate Media: namespace prefix is also usable to reference the original media file content (for rendering or downloading it separately, out of any MediaWiki page)."

The same thing happens when you link to an image like that: Media:Example1.png


Not a lot of point pinging everyone about something only a few may understand or use.

I often see global notices which are irrelevant to me, asking me to take some quiz, or take part in a competition on a wiki I have no interest in.


Additionally, the following javascript variables are set for me:

wikiaIsPowerUserAdmin=true,
wikiaIsPowerUserFrequent=true,
wikiaIsPowerUserLifetime=true;

Anyone can check these by pasting this into their javascript console:

console.log("PU-Admin:"+(typeof wikiaIsPowerUserAdmin != "undefined"?wikiaIsPowerUserAdmin:"false")+" PU-Frequent:"+wikiaIsPowerUserFrequent+" PU-Lifetime:"+wikiaIsPowerUserLifetime);

Last week the Recent Photos module in the right rail was removed. We apologize for the failure to note this in last week's technical update.

— Rappy_4187 http://community.wikia.com/wiki/User_blog:Rappy_4187/Technical_Update:_March_10,_2015

At this time, there are no plans to restore the right rail Photos module ahead of further changes to the right rail, and even then its presence (or the presence of something similar) in the rail is not assured.

— BertH, http://community.wikia.com/wiki/User_blog:Kirkburn/Technical_Update:_March_3,_2015

See the March 3 post for a lot of discussion about it.

I also started a thread about it, and apparently not many people actually miss it.


I'm sorry that I didn't spot your reply sooner.

You're correct, if I edit on a french wiki with my preferences set to english, example, and press preview, the link indeed points to http://communaute.wikia.com/wiki/Help:Wikitext_best_practices, which does not exist.

That's an interesting problem, because it's attempting to link to the help page in my language, but the wiki doesn't have that page in my language, only in the language of the wiki.

It might be possible for it to be changed to point to the corresponding help page in that wiki's language, but that wouldn't be very helpful to me.

While I agree in principle that any help pages should link to shared help pages hosted on the wiki, the only way for that wiki to direct me to a page I can read would be to link to me Community Central in my language.


It was announced that it was a feature they were developing, it was not announced that it would be rolled out so soon.

You can always turn the highlighting off in your preferences if you don't like it. :)

Unless you don't like it on CSS and JS pages, in which case you're stuck with it.


function isProfessionalCodeEditor(whatWeAreTalkingAbout) {
  if (whatWeAreTalkingAbout.ProfessionalCodeEditor == true ) {
    whatWeAreTalkingAbout.SyntaxHighlighting.Obvious = true;
  }
}
test = new WikiaCodeEditor();
isProfessionalCodeEditor(test);

test.SyntaxHighlighting.Obvious evaluates to false/undefined, why? because wikia isn't a professional code editor.


Why does Recent Wiki Activity look like shit ... sorry, I can't think of a better word than shit. Awful. Appalling. Atrocious. Direful. Dreadful. Frightful. Ghastly. Horrendous. Nasty. Painful. Terrible. But none of these words communicate anything that isn't communicated by using the word "shit".

Specifically:

  • It doesn't match the rest of the right rail, completing breaking consistency, and making it look like it's from the 90s. UI design fail.
  • It has been enlarged without adding additional information, meaning more work for the readers eyeballs, as they have to move further. UI design fail.
  • The bold headings make it difficult to read, specifically to differentiate between each heading. UI design fail.
    • The titles
      User blog comment:Kirkburn/Technical Update: March 25, 2015 User blog comment:Kirkburn/Syntax highlighting - helping you read and write code
      just blur together into a big bold mess.
  • It looks like you're sneaking parts of that god-awful venus prototype in one element at a time so we won't notice.
    • I assumed since there has been no more posts about that "IT'S-ONLY-A-PROTOTYPE!" that you'd trashed it.
    • How long before you start inserting ads inside the content?

But you don't care about this feedback, if you cared about how your User Interface looked, you would hire a professional User Interface designer.

If this is supposed to be an April Fool's gag, you jumped the gun a little.


People who want feedback shouldn't care about the wording of said feedback.

OnePieceNation obviously feels strongly about this, so he is communicating how strongly he feels by using strong language.


What's better?

  • A bunch of people successfully communicating "I don't like this"
  • No feedback at all, and people just leaving Wikia entirely without saying a word?

Not all feedback has to be "constructive". OnePieceNation did not rant... in fact, my comment which breaks down the reasons why I think it looks bad is more like a rant, because part of the definition of a rant is the length.


Thanks!


We've always been allowed to make font/margin/border/background/color changes to the WikiaActivityModule in the past, so it would be a jerk-move if they suddenly said that customisations which were allowed yesterday are no longer allowed today.


See this comment: http://community.wikia.com/wiki/User_blog_comment:Kirkburn/Syntax_highlighting_-_helping_you_read_and_write_code/@comment-ChaoticShadow-20150326232432?permalink=816524#comm-816524

If it's distracting for you, you can turn off syntax hi... oh, that's a CSS page, you can't turn off Syntax Highlighting, nevermind.


+1

Additionally, the implied violence is against the Wikia TOU, so I think you should report that immediately, along with any other insults. Wikia Staff will likely tell you to just avoid those users, but it's worth filing the complaint now in case things escalate further.

Unfortunately, they're allowed to lie about you and accuse you of hacking, and to block you for made up reasons. I don't want to make light of the situation, but they would even be allowed to block you for "wiping out the dinosaurs".

That said, that's Wikia's policy. If other admins on that wiki have a problem with the behaviour of those admins, then perhaps they can do something about it.

Edit: I notice none of the users you mentioned are bureaucrats there, so you may be able to get them to listen to reason.


"what's wrong " = A large number of things which I've listed elsewhere and I'm not going to repeat here.

The most important points are:

  • Professional IDEs don't have the bugs this one does.
  • Professional IDEs have options to customise the colours.
that since syntax highlighting is so much liked by coders using better tools

There's a big difference between the statement "syntax highlighting is the standard in any professional code editor" and "syntax highlighting is so much liked by coders using better tools" because real coders don't need syntax highlighting. (inb4 "no true scotsman")

My editor of choice has the option to turn it off completely for each file type, and the only part of the syntax highlighting that I rely on is my customised colouring for comments, so I know to ignore them.

To be clear, I still think adding Syntax Highlighting to Wikia is a great idea. It would be a much better feature without the bugs, with the ability to customise the colours, and the ability to turn it off completely.


  • 2015-03-31 17:15:34 -