I was just looking at someone's list of accounts (e.g., here's mine) and noticed that the icon next to the "Meta Stack Exchange" account is showing the "broken image" sign instead of the correct icon (i.e., https://stackexchange.com/content/Sites/stackexchangemeta/img/icon-48.png).

images broken

Whoever took it ... please bring it back! :-)

Same happens with the Stack Apps logo.

Most of the other icons on that page seem to be served from cdn.sstatic.net (e.g., https://cdn.sstatic.net/Sites/wordpress/img/icon-48.png). And indeed, https://cdn.sstatic.net/Sites/stackexchangemeta/img/icon-48.png does bring up the correct image:


  • Whoops. Wonder where it went!
    – Catija
    Aug 16, 2016 at 0:02
  • 6
    Meta is murdered? Aug 16, 2016 at 0:05
  • Looks like Nick broke more things ...
    – rene
    Aug 16, 2016 at 8:52
  • You were looking at Patrick Hofman's.
    – Mithical
    Aug 16, 2016 at 9:01
  • Not just network profile, in all of stackexchange.com e.g. sites list. Aug 16, 2016 at 9:52
  • @Oded hope you fixed that for emails too? Marc said he's aware of that so I didn't post a separate bug report. Aug 16, 2016 at 11:25
  • @ShadowWizard - the changeset that caused these was reverted, so it should be fixed.
    – Oded
    Aug 16, 2016 at 11:26
  • @Oded thanks, will see tomorrow. (Getting daily emails) Aug 16, 2016 at 11:28
  • 1
    @ShadowWizard - confirmed fixed email (I change a subscription to 15 minutes, seeing icons in the email now).
    – Oded
    Aug 16, 2016 at 11:51

1 Answer 1


So here's the deal. Our image path code sucks. It's bad. It's no one's fault, it's just the result of years of special cases and new use cases that never got a full rewrite of love they need. I know this code pretty well and still spent today git reverting my changes getting nowhere. This is such a great example of tech debt it's ridiculous.

Ultimately, we need this to work and work well for so many use cases that it's rather complex, some examples:

  • http:// vs. https://
  • Local (where we don't have all the per-site domains, making relative painful)
  • Dev (which we may or may not toggle the CDN, making caching paths painful)
  • Dev (also a problem for testing branches on various dev domains and builds)
  • Prod (which may or may not have HTTPS, making caching paths painful)
  • Meta Stack Exchange (which doesn't use the CDN, in case the CDN is the problem being reported)
  • Emails (which don't support scheme/protocol-relative URLs, or anything relative in general)
  • Images vs. other content like /Js and /Img paths (shared vs. global)
  • Beta sites, which share image paths but not content paths
  • Site settings across all these tiers to toggle various pathing (cache pain again)

It's such a royal cluster of situations we have to support that the code reflects it at this point. I think we can clean that up - and in order to move our meta sites and deploy full HTTPS support, I need to do that cleanup. But this isn't a quick fix and today was an exercise in frustration proving that.

Tomorrow morning I won't be writing any code. Instead, I'll be documenting all of the above and the walls and edge cases of each scenario so we can hopefully come up with something far cleaner and DRYer than exists today. Maybe we can just share that document out to everyone since it's an interesting case of crazy.

Sorry for the breaks today, we'd never do such intentionally. I'm backing away and we'll do heavy analysis before pushing any more code simplifications here. I've already got developer views comparing all of these path variants across all of the tiers as a starting point.

Edit: For the why this broke things. I combined 2 of the use cases, which were covered and fine in one section of emails but alas there was a copy of email code which didn't contain the same logic, so swapping some image properties beneath it hosed that case - and that's what users saw. For the meta.stackexchange.com images, they are relative (for the reasons above), and broke in places not called with a Site.Url() method we have, which has the effect of rendering an absolute URL for stackexchange.com...which does not have that relative image. It was relative to the Q&A site root, a different web application.

  • 1
    Very interesting! And here I thought it was just a minor little glitch, easily corrected. It turned out to be the tip of a very large iceberg!
    – Dave Tweed
    Aug 16, 2016 at 23:15
  • "...absolute URL for stackexchange.com...which does not have that relative image" - so why not just add it to stackexchange.com and be done with? Aug 17, 2016 at 3:54
  • @ShadowWizard - and then, in a few weeks, when we need to tweak something in the paths (say... to enable https everywhere), we have one more special case, making things even worse for the future. This is technical debt and it is time to pay it off.
    – Oded
    Aug 17, 2016 at 9:36
  • @Oded but if paying it means, let's say, 100 hours of work, while maintaining an organized list of "special cases that should be copied when moving things around" will take ~1 hour, isn't it better, though not elegant? Aug 17, 2016 at 9:39
  • @ShadowWizard We would have to duplicate every static resource, and continually do so for every site created, not some finite and small list. Additionally, not referencing the same resource would mean users downloading it twice. That's not a quick fix. Aug 17, 2016 at 9:43
  • @ShadowWizard - it needs to be fixed for the future. If every time someone messes with path code something somewhere breaks and then needs fixing... the mess grows until a simple change can't just be made (this is where we are now). This is when one needs to rethink and re-architect so future changes will be easy and will not break random things.
    – Oded
    Aug 17, 2016 at 9:44
  • @Oded Sure thing, never said that isn't the ideal way, just that sometimes when the debt is so big, maybe less elegant ways can be considered (i.e. "the lesser evil"). Anyway, I trust Nick and the rest of the team to come with a real fix, and wishing you all good luck with implementing it! :-) Aug 17, 2016 at 9:51
  • @Sha - just saying - telling us to continue doing what put us in this mess in the first place...
    – Oded
    Aug 17, 2016 at 9:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .