

Configuring A Static Asset Pipeline With Django And Heroku - larkinrichards
http://refer.ly/configuring-a-static-asset-pipeline-with-django-and-heroku/c/b439813680dc11e2bfbf22000a1db8fa

======
nulluk
Instead of prefixing everything with {{ STATIC_URL }} in your templates, use
the template tag {% static 'foo/bar/img' %} which will allow you to do asset
time-stamping/versioning,

[https://docs.djangoproject.com/en/dev/howto/static-
files/#wi...](https://docs.djangoproject.com/en/dev/howto/static-files/#with-
a-template-tag)

Edit: forgot to link to the versioning part in the docs:
[https://docs.djangoproject.com/en/dev/ref/contrib/staticfile...](https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#cachedstaticfilesstorage)

Edit edit: ADMIN_MEDIA_PREFIX is also depreciated from 1.4 onwards:
[https://docs.djangoproject.com/en/1.4/releases/1.4/#django-c...](https://docs.djangoproject.com/en/1.4/releases/1.4/#django-
contrib-admin)

~~~
larkinrichards
Good point. Delegating to the storage backend instead of using a STATIC_URL is
a don't-repeat-yourself solution.

It's interesting that the CachedStaticFilesStorage will replace urls inside of
CSS (as part of the time-stamping), but the standard Storage won't do it to
change paths for development/production. As it stands, I use production urls
in CSS so that I don't have to change it when I deploy.

~~~
nulluk
Using relative paths in your css generally resolves that issue, is there a
specific reason that doesn't work in your use case?

~~~
larkinrichards
No, that's actually what I should be doing here. Thanks for mentioning it!

------
arocks
> Unfortunately, Heroku’s guide on using Django and static files has no actual
> details on how you should configure Django to serve static files

This is of course because Django _should not_ be used for serving static files
in production. It is has to be handled before it reaches the Application layer
i.e. by the web server.

Before Amazon S3 and CloudFront, it used to be the job of Apache or Nginx to
serve static content but now that we have cloud based solutions they would be
more robust. So it makes sense not to include such production deployment
details from Django docs. But it is incredibly useful to have a stand-in
functionality while you are in development.

------
route3
Lots of useful information here and kudos to the author for composing a well-
written post: summary of the issue, "here's how we fixed it" (with code
samples) and concludes with some caveats/things to watch for. (Reminder:
quality content like this is how inbound marketing works)

IMHO the official Django docs are some of the best you'll find anywhere of any
open source project. My suggestion, though, is to read and re-read and make
sure you gather all documented information about $YOUR_TOPIC before
formulating your own game plan. For example, here is the chapter on handling
static assets in Django:

<https://docs.djangoproject.com/en/dev/howto/static-files/>

There are a lot of relevant links on that page that are worth following if you
want to make sure you a) get the picture and b) know how you want it to all
come together for your project.

Lastly, on the topic of storing assets: if you want to offer a Django-ready
library for your new cloud storage startup/setup, consider writing your own
file storage handler

[https://docs.djangoproject.com/en/dev/howto/custom-file-
stor...](https://docs.djangoproject.com/en/dev/howto/custom-file-storage/)

