Use Django staticfiles

[jaylett]

Currently we don't, resulting in string concatenation to create URLs. We may be able to address #72 at the same time by building a proper asset pipeline.

[georgebrock]

This is work in progress on the george/static-files branch.

• Remove FIXED_STATIC_URL settings, they're redundant.
• Stop directly using STATIC_URL and MISSIONS_STATIC_URL to build asset URLs.
• Configure django.contrib.staticfiles.
• Only collect built CSS, not SCSS source.
• Only collect mission images, not all mission files.
• Use CachedStaticFilesStorage, but somehow preserve permanent URLs for assets we pass to the open graph (anything that used to use FIXED_STATIC_URL)

[georgebrock]

Once all of this is finished, it'll require some changes to the img-origin.spacelog.org virtual host config:

• All of the static files will be collected in one place, so there'll be no need to configure /missions separately.
• Everything will be in a new collected directory (or similar), rather than serving directly from the static directory.

[jaylett]

I strongly recommend not using CachedStaticFilesStorage; it has a poor deploy/rollback experience. The Manifest variant is better, although still not ideal. I plan to fix this properly, but I can't commit to a timeframe.

I wonder if we should have a (local) variant of {% static %} which allows us to specify which of a number of storage backends should be used, or just an unhashed variant of {% static %} to use for the fixed URLs. That way we could have un-hashed URLs and hashed URLs served (from the same URL & file spaces, since collectstatic first copies unhashed then post-processes to generate the hashed versions).

[georgebrock]

We're currently on Django 1.4, so CachedStaticFilesStorage is the best we have without an upgrade. The answer to this might be an upgrade.

[jaylett]

An upgrade is a good idea anyway, since 1.4 is pretty old now. If we can get onto 1.8 we get a lot of time before we have to upgrade again.

Alternatively, we could probably suffer through the problems with cached in the short term given we don't often need to roll out changes to the static files. I assume you were thinking of using a redis-backed cache? (The implementation is pretty good from what I remember.)

[georgebrock]

I've solved the SCSS problem by adding a make target to run collectstatic with --ignore=*.scss. I've also re-defined the STATICFILES_DIRS entries for the missions to point to their images directory, since those are currently the only static assets a mission has.

There might be more elegant options, but this will work for now. The consequences of getting these bits wrong aren't really all that serious, we'll just that we have redundant URLs that aren't linked from anywhere serving files that are already under a public domain license.

Just the cached or manifest file storage to go.

[jaylett]

Doesn't that mean that mission assets are going to be flattened? Actually, I think that was true beforehand, so I suspect this will only work for one (probably the last in lexical order?) mission. I should have caught that sooner, sorry.

[georgebrock]

It should be fine: I'm giving each mission's STATICFILES_DIRS a prefix (e.g. ('missions/a8/images', '/path/to/missions/a8/images')) which seems to work. I see working images for all the missions on the development server, and when I run collectstatic I get a collected/missions directory with a subdirectory for each mission.

[jaylett]

Ah, cool. I'd forgotten about prefixes for STATICFILES_DIRS :-)

[georgebrock]

Closing in favour of #232