WIP For Initial Review: Feature/cdodge/alpha microsite

[chrisndodge]

This feature is to support domain branding (e.g. 'foo.edx.org') as required for some B2B launches soon (mid-January).

I wanted to get together a pull request so that some people can start taking a look at the diffs. In particular, @sefk can someone from Stanford look at this and make sure it'll be compatible with your theming.

Test writing is TBD, but wanted to get some eyeballs on this main implementation.

[sefk]

It feels like this is undoing the good stuff about how we had handled theming before. From my perspective there are three key pieces of what theming does:

1. When you enable_theme, it adds directories to Django's TEMPLATE_DIRS and STATIC_DIRS variables. That way when Django is looking for the templates and static assets to serve, it can find them in another place on the filesystem. If you don't choose to override a template in the theme, Django will fall through and find the default in the search path.
2. The theme is checked out right alongside the edx-platform on the machine, and is a place where we can encapsulate all these custom bits -- css, img, templates.
3. There's a bit of hackery in the toolchain since we need to make both Ruby and Python aware of the theme. (this part is still pretty murky to me). But you need some way to use themed css. The existing theme handles this, but it's a bit hacky (requres a top-level env.json containing just {"THEME_NAME":"stanford"}

I really don't like having all the template changes just wedged into the microsites.py file. This is a bummer place to maintain HTML templates, in strings wedged into a python config file. You lose all the semantics of having HTML in there.

If you really want these overrides to live in a big dict, and not handled with Django loading/handling, then at least could we build that dict at runtime by loading files off disk? But even then it seems like we're working against Django instead of with it -- for example subverting Django's template searching and watching stuff.

So static assets have to be served off machine, templates are wedged into the config. What about CSS? It looks like those still have to be put in the source tree under the microsites directory. And so that takes us down the path of either a) having all the customization files checked into the master repo (yuck), or some other way for those files to get put onto a production machine and stitched into the source repo (yuck). It seems like this takes us back to a "theme" directory, and if you have to do that for CSS, why not for other pieces you want to redirect, like templates and assets.

I wonder if there's some way to keep the "theme" directory idea as it stands now, and then use the middleware you've written to adjust the Django bits to still make it handle different assets per request, instead of per instance.

I assume you tried to get native Django "sites" working and that didn't work? not familiar with that myself, so I presume not.

Sorry to be such a wet blanket. You should let me know how you want to proceed, Chris, especially giving your tight deadlines. If you plan to move forward then I'll try to see if we can recreate what Stanford is doing now with these changes (it's broken now). If you're open to discuss other approaches, then maybe we can find some time tomorrow on the phone? I know it's right before the holiday, but I am around.