Technical Update: January 10, 2012
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.
New Features
Edit
- We're adding a "Read More" section to articles in the mobile skin, which will be similar to the "Read More" content you see at the bottom of articles in a full browser.
Major Bugs FixedEdit
- Our Game Guides app for Android was experiencing runtime errors.
- Users in some locations were intermittently unable to load the editor.
- The Theme Designer was not accepting images with a .jpeg file extension (normal .jpg files have been fine).
Other Notable ChangesEdit
- We're updating your User Preferences page so that items are grouped and listed in a way that's clearer and more useful (for example: all email notification settings will now be in the same section).
Select Known IssuesEdit
- The Quick Stats section of the Admin Dashboard is showing "0" views.
- Chat kickbans are not showing up in logs for some wikis.
Questions? Comments? Feel free to leave them below. And if you have additional bugs to report, please send them to us via Special:Contact.
Want to be notified about Technical Updates when they are posted? Then click here to follow this blog.
- Showing 20 most recent
- Show all
63 comments
-
yes yes yes i want to read moreee
-
shoudlnt i try it?
-
are comments really that big a deal?
-
swwet commenting here
-
"Chat kickbans are not showing up in logs for some wikis." -- Probably considered a minor issue. Can use user rights management in the meantime. Would still like to see this one get fixed sometime =)
-
this page has too many comments
-
You think this page has too many comments? Take a look at this one. :)
February 6 by Dser -
And if you think that one has too many comments, take a look at this one. Take that, Dser! :P
-
what is love then
-
i do not agree
-
Take a look at this?
See the User Preferences page changed :P
-
Yeah. I noticed that, too. :)
January 16 by Dser -
This was changed a few weeks ago. They grouped all similar items together so they were not just thrown around randomly. Much better imo.
-
Ok then.
-
Where is the "Real name" field now?
-
In the userpage header, which is where avatar changing moved to.
---****--- Roads
January 17 by Roads -
Can you guys prehaps add "Read more" sections to the Wiki features list?
-
The "Read More" section was originally in Special:WikiaLabs (before it became WikiFeatures), but it "graduated" and is now on most wikis (with a few exceptions). If you want to remove it, it can be done with css.
January 16 by Dser -
I want to do it on all the Wikis without .css.
-
You can't just remove it from all wikis. You can add some things to your global CSS, which will make it disappear only for you, but on all wikis.
@Dser: Can we get it to disappear only in a specific namespace?
---****--- Roads
January 17 by Roads -
@Roads: slip .ns-500 or any other namespace number in front of the block of code to make it disappear there only. The body element has these classes, which you can check by viewing the source.
-
Why is the skin option and everything in "Userpage" and not under the nonexistent (here) "Appearance," like it is on standard MediaWiki?
Also, what's the real difference between JPG and JPEG?
And is the "User Masthead Log" supposed to log changes to the header? It doesn't and never has.
---****--- Roads
-
By "skin option", do you mean in Wikia's rearranged Special:Preferences? The skin option is under the "My Info" tab under a section labelled "Appearance"... are you seeing this? The reason given for this rearrangement (from above): "We're updating your User Preferences page so that items are grouped and listed in a way that's clearer and more useful (for example: all email notification settings will now be in the same section)."
JPG and JPEG are different extensions for the same image format. In theory, there should be no difference between using either of them.
-
Can someone tell me the class for increasing the line height of the TOC? Won't we use the property, "line-height" to increase it, then?
-
.toc li {line-height:20px}
20px is the default height for all list elements on a page.
.WikiaArticle lialso works but will affect other lists in addition to the TOC. -
Can someone take a closer look at the line spaces? Some are having a small space per line making the texts look messy.
-
You noticed that?
January 13 by Kata89 -
The release has gone live this morning. As always, we are keeping our eyes out for bugs (including some mentioned below) but everything seems stable at the moment.
The new preferences page is available and working on all EN wikis. Wikis in other languages will be switched over soon.
-
One question: Is this causing a change in the data caching? I've noticed that its about 4 hours (so far) behind when it usually updates (DeadendPages, LonelyPages, WantedPages, etc)
-
I'm seeing a sudden reduction in line height across Wikia. Was this intentional, and if so... why? :P
-
I've noticed that too, but only on the.WikiaArticle li
part, where a fixed 20px value shrinks lists down.Also, it looks like the section headers are given a top margin.
-
It's not just section headers that got an overnight top margin. Bulleted lists also now have more vertical distance between points. Don't know whether that's because a top or bottom margin has been added, or if it's because the line-height for bulleted lists is handled through a different element than that for general article text. In any event, our disambiguation pages are ugly as hell now at w:c:tardis.
Oh, and tables of content seem to have additional line-height as well.
-
RecentChanges and TOC also look quite terrible.
January 11 by TK-999 -
A fix for the section header issue that I've found useful at w:c:tardis is simply:
.WikiaArticle h2 {margin-top:auto}Your milage may vary on the definition you give tomargin-top, but that at least allows you to control the margin.And TOCs, like lists, are handled by
.WikiaArticle li, as suggested upthread. We set theline-heightvalue to 1.2em. But I guess that's basically about 20px in our standard, serif fornt. 20 px would seem a bit huge to me with Arial, but all that's a matter of taste. Point is,.WikiaArticle li {line-height:something}is how you control bulleted lists, numbered lists and TOCs. -
I didn't notice the change in line height since I already have that set to something sensible in Wikia.css, but the added margin above headings definitely looks ridiculous.
-
Yes, sorry, line-height changes are intentional and we should have included them in this update. If it's looking unpleasant anywhere, can you give us links? Thanks.
-
Article content and recent changes are quite clogged.
January 11 by TK-999 -
Hi guys. Yep, the line height was tightened a little bit, more space added before headlines, superscript no longer adds extra line height ([1] reference links) and lists have been changed a bit. By juggling line height and margins for lists, we were able to keep the line height between bullets the same as before, but introduced tighter line height for long bullet points where the text wraps. The theory is that in some cases, it's easier to discern where one bullet point ends and another begins.
Here's the changeset: [1]. User:CzechOut is correct on the selectors. If you want to override the changes, use the same selectors we use: .WikiaArticle li (notice the line height and margin changes) and .WikiaArticle h2. We always load your CSS last so that you can override the default styles, should you choose to. Bye!
-
Thank you Blade for the changeset!
It would be great if we could receive those more often since it saves a lot of time at our end. Thanks again!
-
It says we are going to edit CSS codes manually? I don't even know how to use that CSS thing! A fix should be given to all wikis instead.
-
What if newbie editors would try to add or remove spaces while editing? They might think this "fixes" the problem but no... let's just wait for the code fix
-
Space above headers looks horrible now. Why Wikia must always do such ridiculous changes?
-
-
We're aware of some general issues, but if you can send a report to Special:Contact with examples, the more documentation we have the better!
-
Hmm. Not really sure how to “document” when the bot is not working. All I do know is that someone who has never contributed before, makes a contribution, and yet the bot is not being triggered.
-
Agreed. +1
-
The documentation for that is a link to the talk page of the person who should have been greeted, but wasn't. We can research it from there. Thanks!
-
Can you guys prehaps add "Read more" sections to the Wiki features list?
-
Bringing forward unacknowledged questions from last week's technical update:
- When creating a new page, autocorrect disappears at the bottom of the editing, is this a known bug?
- Why are there now 2 non-removable admin dashboard links on the toolbar
- Blog comments arent linking to the correct place in the wikiactivity sidebar
-
You can remove the admin dash links on the toolbar through JS if you would like
$().ready( function() { $('li > a[data-tracking="admindashboard/toolbar/admin"]').remove(); } ); -
Oh, thanks for bringing these forward, Acer.
1. I'm a little hazy on what you're saying here. Can you give me exact steps to reproduce?
2. I just verified that yes, the second admin link is unintentional. will get that filed.
3. Ah, great point. Were they ever working properly, or is this just a bug we've all learned to tolerate? I'll look into it.
-
Cheers for the code Godisme.
To reproduce the create page thing - click add a new page, (make sure you're in source mode), then do a load of carraige returns to get the cursor to the bottom of the editing window (or, fill the new page with content down to the bottom). Note there is no space below what you are now typing (despite being promised padding down there back in july last year, but I digress). Now type [[ to start a link, and auto complete doesn't come up. Normally, the auto complete would appear above the line you're typing on so you could see it. Ah actually I'll just do some screenshots. this is what it should be doing, this is what it is doing -
Ah, okay, I think I see it now. When you add a category to the bottom of an existing page, the autocorrect appears further up in the editing window so as not to be cut off. When you add a category to a new page, the autocorrect appears where you are typing, and is cut off.
Interesting, I could reproduce this on Firefox, but it seems to be working fine on Chrome.
I'll get it reported. Thanks.
-
Will there ever be a way to customize the mobile skin with css? I'm not very fond of the "Read more" section.
-
The Read More section is below the article content, and meant to give readers a prompt to keep browsing once they get to the end of the page. You might want to give it a chance and see if people use it.
As for customization -- currently, it's limited, and our focus is on developing the features people want and need (with a lot of help from the feedback we get from folks like you). So I'd love it if you could tell me more about what you'd like to customize and why.
-
I'd really like to see a little more color with the skin, as it is currently a little dull.
January 10 by Dser -
More colour? :S No, I think it's fine the way it is. Good design needs to be able to fade into the background of the content. Using more and brighter/bolder/heavier colour isn't compatible with that goal... not too nice on the eyes, either. :P
-
Point taken, 888. Maybe the excess use of color would not be a great idea, but I think links to non-existent pages should be an exception. Perhaps these could be changed to a different shade of blue to avoid confusion.
January 10 by Dser -
I know this is sorta not my business, but, as Sannse said in the admin/vstf changes blog, staff hope to soon to annouce the new VSTF, any updates on that?
-
We do expect some upcoming changes, but I don't have any updates or specifics on this -- sorry.
-
Okay, thanks for the reply! :)
