I'm curious how SE manages the content of the various sites in their network. With so many sites, they must have a fairly efficient process at this point for spinning up new sites.

I understand that with heavy use of CSS classes or LESS Variables one can change the style pretty drastically, but what I'm more curious about is the management of different page content. I don't mean the questions, tags, etc. That's obviously managed on a database level. I mean the "static" content of pages.

For example, the help FAQ for meta is different than for stackoverflow. Not just the style, but the actual content.

I know from here that they're using ASP.NET MVC as their server side technology, so are they just creating a new Partial View for each site and letting the Controller decide which one to render? Perhaps bootstrapping with an IOC container to resolve at startup different controllers that know which View to display?

I'm also aware of .NET localization with resource files, but in discussions with other developers, I've been led to believe the performance is inadequate. Super heavy use of config files? Seems potentially unwieldy. Store everything in the DB?

  • With so many sites, they must have a fairly efficient process at this point for spinning up new sites. Why does quantity equal efficient? All the beta sites share the same content and it's not like they constantly have new sites leaving beta so it doesn't strike me as there's a huge need to be very efficient at this... Apr 3 '13 at 17:25
  • @SomeHelpfulCommenter all beta sites start out with the same content, but that content changes during the course of the beta as the site grows (especially the FAQ).
    – yoozer8
    Apr 3 '13 at 17:32
  • @Jim do you think changes to the site-specific FAQ's are efficient? Apr 3 '13 at 17:35
  • @SomeHelpfulCommenter I guess I'm making an assumption that if their business model is to create new sites within their framework, and that they've done it for a couple years now, then they would want to make the process as painless as possible. I suppose that could be an incorrect assumption. If someone wants to answer "We start a new site from scratch with a blank txt document in Notepad." Well OK then, that's how they do it.
    – jes
    Apr 3 '13 at 17:39
  • 1
    @SomeHelpfulCommenter I think they are infrequent enough that their efficiency is probably irrelevant
    – yoozer8
    Apr 3 '13 at 17:40
  • @Jesse I found this post on Jin Yang's blog. And this podcast. Maybe they can bring some insight if someone from SE doesn't answer Apr 3 '13 at 17:49
  • @SomeHelpfulCommenter definitely interesting information, and I've actually read the first link before. However the focus on those is the design of the website, whereas the focus of my question is on the content. As both you and Jim have pointed out, maybe there's not enough differences in content to make it a worthwhile problem to discuss.
    – jes
    Apr 3 '13 at 18:43

Here's an example FAQ file, a simple .htm (arbitrary extension) that's made when the site is created (automated) and pretty much doesn't change unless we need to make a specific exception for that site later on:

<div class="col-section">
<h2 id="questions" data-title="What can I ask here?">What kind of questions can I ask here?</h2>
    $SiteName is for <span class="revision-comment">researchers and developers who explore the principles of a system through analysis of its structure, function, and operation</span>.

The WikiPlaceholder is a template that is editable by the mods. If it's not edited, you're seeing the content it'll show initially. After an initial edit it's then a post with revision history, etc. The lower sections are partial views that all sites share (child metas have a different list of these). If we need to edit one of those sections, we edit the razor view, not each faq.htm.

Content like this is stored in a folder dedicated to that site (visible in the sstatic.net path on included resources in a page). 99% of the time there is just a faq.htm and all.css in there. The all.css is generated from an all.less which is converted on-build from a series of shared .less files underneath. For example, the beta sites share a base file, the trilogy shares one, those both share one underneath, etc. We use includes and mixins to reduce code. To be honest, we could do much better than we do, but that means going back and re-doing lots of LESS for old themes we just don't have the dev and designer resources for right now.

The only content left that's different is the img folder, which has an apple touch icon, a favicon, a 48px version, and a logo use for chat, the API, and the site itself except betas (which are html, not images). These images are generated by Jin on site launch, we're still at the volume that it doesn't make sense to automate those yet.


You must log in to answer this question.

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