Admin Forum:Monobook tabs seriously dislocated after 1.19 upgrade

Forums: Admin Central Index → Technical Help → Monobook tabs seriously dislocated after 1.19 upgrade Wikia's forums are a place for the community to help other members. To contact staff directly or to report bugs, please use Special:Contact.

Since the 1.19 upgrade, Monobook display has been seriously compromised. Take a look at this screenshot: You'll note that the background for the article proper has been shifted upward such tht it extends all the way to the control panel. The tabs stay where they were before, but are still z-indexed above the article text, which means that most leads are wholly obscured.

So is this a bug, or is it something we now have to find a workaround for? (For what it's worth, this behaviour exists in the latest versions of Safari, Opera, Firefox and Chrome)  07:45: Wed 15 Aug 2012


 * Your wiki likely has custom CSS that pushes the tabs down. You can push the content down through CSS as well. In your MediaWiki:Monobook.css, you can add a  under  . You will also need to change   to   instead (making it more specific, else it'll be overridden). - Tjcool007 (Talk) 09:39, August 15, 2012 (UTC)


 * Well, yah, my wiki has custom CSS — you can see that just by looking at the picture provided. My point was that this is definitely an effect of the 1.19 upgrade.  Last week Monobook was workin' fine on my wiki; this week it's not.  What I want to know is whether it is a bug Wikia haven't yet dealt with or something I should try to work around locally?   14:25: Wed 15 Aug 2012


 * It's caused by CSS that adds 160px padding to #p-cactions loaded from w:c:tardis:Monobook.css
 * Remove #p-cactions from that declaration and it should look as intended (but only for wide(r) screens - someone should look into that and add a little more padding to the top area - more buttons = overlap). Rappy 14:47, August 15, 2012 (UTC)


 * Personally, I would fix the #content CSS over to div#content (required now for 1.19) and add  to it. That pushes the top down enough to fit the tabs for smaller screens and fixes the colored background for the content area. Rappy 14:52, August 15, 2012 (UTC)
 * Okay. So just to be crystal clear, this change from #content to div#content is what Wikia considers intended behaviour and is not a bug that will get fixed in a later weekly update?  That is, it's a MediaWiki change, not a Wikia change?   15:41: Wed 15 Aug 2012
 * Also the site design really depends upon the content box being level with the top of the search box. Is there any way I can get that top space back?  I desperately need to lower the top of the content box by 160px.  16:06: Wed 15 Aug 2012


 * There was a CSS change from 1.16.5 => 1.19.1 that changed the default CSS from #content to div#content. To ensure that your old CSS still shows as intended, the selector should be changed. Either that, or you'd have to add !important to each property within the statement. As for the 160px, can you elaborate on what you are referring to? Rappy 00:44, August 17, 2012 (UTC)

Thanks for the clarification on div#content. I think I kinda/sorta have it figured out now, but just to answer your question, we use that 160px to situate an expanded logo. More importantly, this is where we put our stub templates as well as links to wikipedia (see tardis:Kate Fisher) and our links to pic libraries (as at tardis:The Mutants (TV story)). But like I said, thanks to this thread and your help, I've gotten everything working again, except that my z-indexes on the stub-like templates is a bit off.

And here I'm a little stumped and could use your help. Take a look at this shot from Firefox's console. Well I guess this is what used to be Firebug. Anyway: What I have highlighted here is the area defined by. I guess that — because it's not expecting there to be this big a gap from the top margin of the page — it's calling the whole area from where the cactions are now to where they nominally "should" be, the area defined by.

What this means is that the little buttons inside this area are z-indexed out of utility. Neither of the two buttons that are wholly within the "PCP area" are clickable. The "locked" button is clickable on the portion that is outside the PCP area.

Obviously there's a z-index riddle to be solved here, but I'm not quite getting it. When I lower the z-index of the PCP, the cactions become unclickable. When I raise the PCP z-index, the stub/wikipedia buttons become unclickable.

Is there a way to just reduce the whole size of the PCP area so that it doesn't extend all the way up to the personal buttons/clock? I don't really see why the area needs to be taller than the bottom of the logo, but I'm not sure how to reduce the size of the area. Anyone got any ideas? 18:49: Fri 17 Aug 2012


 * Let me start by apologizing. I didn't realize the tabs were lowered 160px to show the background (and I didn't take the time to look into it). I can see now why you wanted that gap. As for the z-index issue, I am able to click both the tabs and the buttons next to the logo. Was this a caching issue that is now fixed?


 * To explain why that area looks so big... it's because the top of that box is where the buttons should be. IE: where they started. The CSS has added a padding to move them down 160px; hence the box grows in size up to where they finally rest.


 * If something is unclickable when you reply, please don't change anything so I can see the same issue and reply with exactly what isn't clickable at that time. I will do my best to find out why and resolve it. Rappy 19:11, August 17, 2012 (UTC)