File a support ticket.

So this turned out to be surprisingly difficult to actually fix. For some reason, the server keeps throwing me either old or 503ing CSS...

@jack Did this ever get fixed?

I've got a number of fixes upstream that I've yet to pull down to ShoutWiki - I believe this might be amongst them?

The outermost div#column-google is now 160px wide, but some of the intermediate nested elements remain 120px.

I found similar issues in other skins.

Should be fixed when rSHWK4162 is deployed.

Now that Sports is a theme of Games, I've pushed that change live and undeployed Sports from Interface Messages Wiki, the only wiki where it was deployed on.

So I added (and self-merged) a new hook point, RefreshedInSidebar, to Refreshed (upstream commit), which allows us to inject 125x125px ads into the sidebar area.

Fixed in rSHWK3876. Already deployed.

Isn't this used on brickimedia production? It shouldn't be too likely to explode.

In T89#1158, @lewiscawte wrote:

so that hopefully there's a bigger audience to test Refreshed

We're not here so you can test your code. Go break some other site.

So this was probably worded a bit badly. I'm sure that @SamanthaNguyen's intention wasn't to have unstable, potentially broken code deployed on ShoutWiki.

My apologies, my intention wasn't malicious (e.g trying to break any of the wikis), just a suggestion. Sorry about that.

so that hopefully there's a bigger audience to test Refreshed

Upstream patch: https://gerrit.wikimedia.org/r/#/c/297114/
Local patch: {rSHWK3895}

#site-logo {
	min-height: 150px;
}

fixes this bug. I'll try to commit a patch later today...

I feel like the ideal solution to this is to deal with it via CSS, even if we just do something where we detect no image we put a blank clear one in there. We can put in as many defaults as we like, but at the end of the day that doesn't stop users deleting the images and having the bug.

Perhaps we should implement a default logo of some kind in the Nimbus skin itself? Right now it uses $wgLogo (i.e. Wiki.png on ShoutWiki), but some skins (such as Quartz) use that skin's custom logo (Wiki_wide.png in Quartz) and fall back to $wgLogo if there's no appropriate, skin-specific custom logo...which actually doesn't handle the "$wgLogo doesn't exist" case at all. Maybe I'm wrong and this indeed is a real code bug that we could and should handle with CSS or something. Thoughts?

There's a document.write in https://phabricator.wikimedia.org/diffusion/EDSN/browse/master/DismissableSiteNotice.hooks.php , what do you think?

So something somewhere is calling document.write, which isn't really supported in MediaWiki anymore and that's breaking things. This results in a warning logged into the browser's JS console: "Use of 'write' is deprecated. Use jQuery or mw.loader.load instead.". This traces back to the file /resources/src/mediawiki.legacy/wikibits.js.
I was able to reproduce the broken ad behavior in Opera 37.0.2178.32 under Windows 7.

div#mw-panel-right {
	top: 120px;
}

might/should fix this, at least for anons. Tested on Opera 37.0.2178.32 under Windows 7. No idea what to do w/ logged-in users, though.

The ad needs pushing further down the page. Overlaying that user menu on top of the ad is just calling for an invalid click activity strike.

Oddly enough, I've gotten several different ad placements, including the correct one. This is on Chrome 51.0.2704.84 on OS X 10.11.4 (El Capitan). Here are some examples:

Sidebar isn't working, after a couple of refreshes here and there - Using Windows 10, Chrome v51.0.2704.84, 1366 x 768

Ads are looking weird on Mobile Chrome too. Samsung Galaxy A3, Android 5.0.2, Mobile Chrome 51. Can anyone check ads with other browsers?

This looks like it could've been a temporary glitch due to whatever JavaScript loading issues or somesuch on Google's end, or missing JS dependencies; more details, especially on reproducibility, would help. There's a possibility that this bug is one that manifests only on certain platforms (Windows, maybe just Windows 7) when using a certain version of Google Chrome.

Some background info on this: a while ago (when? I can't remember and I'm too lazy to look it up) a bunch of system messages (which link to help pages) were changed to point to MediaWiki.org help pages by default. This makes sense (for most MediaWiki users), because MW.org's help pages are "licensed" into the public domain, are guaranteed to be at least somewhat up-to-date and that way users don't necessarily have to copy the pages to their local wiki(s).
Currently (as of MediaWiki 1.26.3) there are 11 matches for Special:MyLanguage and 28 matches for mediawiki.org in /languages/i18n/en.json. Of these, the following are "user-facing" and might need to be customized for ShoutWiki:

So the last time we updated our version of Metrolook was in {rSHWK3754}, in December 2015. I'm not sure if we'd need to update our version for the public launch -- no major changes have been done to the skin and AFAIK it's pretty feature-complete, but it'd be nice to be running the latest version, for i18n and whatnot.

While T49 isn't technically blocking this, it makes sense to do it in one swoop