To avoid having the separated css includes in zamboni templates and fireplace's index.html let's point to fireplace's index.html via nginx instead. Note: there are hard-wired /media/* urls in the index.html template we'll need to make sure we don't clash with other /media urls. Maybe try_files will work for this, but we should avoid introspection of referer headers at all costs, as this has proved to be a royal pain to maintain.

For reference fireplace index.html is here: https://github.com/mozilla/fireplace/blob/master/src/index.html

If the nginx stuff becomes too much, an alternative is to copy the index.html files into a git-ignored folder within zamboni (i.e., mkt/commonplace/templates/commonplace/project_templates) where each file is named after the project (fireplace.html). If settings.DEBUG, then serve with those. Then update those files each time the server is re-run or in a task runner. Something like that.

I looked at this as it was related to bug 1052130. The problem of pointing to a static file is that you suddenly need a bunch of rules to be able to send some requests to Zamboni and some to marketplace. This would mean we'd be replacing one maintenance issue with an other one. I'm thinking a simpler approach would be that fireplace generates a single roll-up CSS file and we can point at that instead of separate files. For bonus points we should generate both minned and un-minned files and then control which is served via the zamboni settings. If we go this route we can then make this part of the CSS and less part of the page so the configuration will all live in fireplace.

Yeah, I can make it generate something like include.max.css. We'll leave this until after I upgrade the Commonplace projects to use Bower/Gulp.

Ok going to close this and raise new bugs for generating and pointing at a roll-up CSS file.