I notice that when I reference my java scripts and static image files from my templates, they show up in development, but not from the production server. From development, I access them as such:
<img src="/my_proj/media/css/images/collapsed.png" />
but from production, I have to remove the project directory:
<img src="/media/css/images/collapsed.png" />
I'm assuming I'm doing something wrong with regard to serving static media.
I'm caught between a number of seemingly different options for serving static media in Django. On one hand, it's been recommended that I use django-staticfiles to serve media. On the other I see reference to STATIC_ROOT and STATIC_URL in the documentation (with caveats about use in production).
I have small .png files of "plus" and "minus" symbols for use in some of my jQuery scripts. In addition, the scripts themselves need to be referenced.
1) Am I correctly categorizing scripts and site images as static media?
2) What is the best method to access this media (from production)?
You shouldn't keep the URLs hardcoded that way.
If you're running thedev version of Django, you should check this doc.
If you're not, for simplicity, you can use {{ MEDIA_URL }} and configure that variable in your settings for dev and for production.
<img src="{{ MEDIA_URL }}/media/css..." />
Keep in mind that you'll have to use RequestContext, see more here on docs here and here.
Also, you should server all your static files directly trough a proper webserver. You can configure apache or nginx to do that.
Sigh. There is only one way to serve static media in production, and that is to get the webserver - eg Apache - to do it. Django-staticfiles is for development only, and this is clearly stated throughout the documentation.
Related
I’m migrating a website from WordPress to Django/Wagtail. I have all the old WP content in my media directory & it’s all being served appropriately.
It would be convenient to map other URLs (specifically /wp-content/) to MEDIA_ROOT, for the sake of old media URLs that were hardcoded in the content.
So for example a migrated asset now available at //example.com/media/uploads/2017/12/IMG_2120.jpg can also be served from //example.com/wp-content/uploads/2017/12/IMG_2120.jpg
I’m sure there’s some obvious way to do this (in urls.py?) but totally drawing a blank.
I'm sure you already know that static/media files should be served using a frontend server (like Nginx), because it's been mentioned at so many places in the docs.
So, if Django doesn't serve the files, why does it need the MEDIA_ROOT and MEDIA_URL settings?
MEDIA_ROOT is the place where Django stores the images/files you upload.
MEDIA_URL is used by Django to generate file urls. For example, if MEDIA_URL = '/media/', then if you do {{ image.url }}, Django will generate a url like this - /media/image.jpg.
But Django doesn't serve the files. Your frontend server does. So, what you do is, you configure your frontend server like this:
if request path starts with /media/:
map it to <media directory>
Basically, you're telling your frontend server to serve content from the <media directory> for every request that starts with /media/. This way, a request starting with /media/ never actually reaches your Django app, because your server is taking care of them.
What I mean by all this is that you can configure your frontend server to map /wp-content/uploads/ to your <media directory> and it will serve the files.
I have HTML/JS/CSS files provided by a third party (whom I have no control over) that serves as a single page app that communicates with a backend built with Django and django-rest-framework.
I'm wanting to host this on Heroku and thus these static assets are being served by Django. These files contains relative paths to each other. For example, the index.html contains:
<link rel="stylesheet" type="text/css" media="screen" href="styles/css/bootstrap.min.css">
Which leads to a 404 because styles/css/bootstrap.min.css is not routed by django.
The only way I know of to serve the index.html from my domain root www.domain.com is with an url config like:
url(r'^$', TemplateView.as_view(template_name='index.html'), name='home'),
...even though it's not really a template, it's just plain HTML.
The problem arises from the fact that all the urls in the other assets are relative to this index.html and of course Django doesn't work like that. If I was developing this front-end application I'd be using the static template tag and one of the various ways to get urls to javascript.
I don't mind switching from Heroku to another PaaS if they offer a solution to this problem, but manually editing all these files does not sound like a fun job...especially considering the fact that I'll be receiving updates to these files going forward.
I think the way to solve this on a regular old server would be to configure the web server to resolve these urls correctly, but that option doesn't seem to be available on Heroku.
Here's how to set up Django to serve your static files and index.html on / while still having the possibility to use Django views for the admin dashboard, registration etc.
from django.conf.urls import include, url
from django.contrib import admin
from django.contrib.staticfiles.views import serve
from django.views.generic import RedirectView
admin.autodiscover()
urlpatterns = [
# / routes to index.html
url(r'^$', serve,
kwargs={'path': 'index.html'}),
# static files (*.css, *.js, *.jpg etc.) served on /
# (assuming Django uses /static/ and /media/ for static/media urls)
url(r'^(?!/?static/)(?!/?media/)(?P<path>.*\..*)$',
RedirectView.as_view(url='/static/%(path)s', permanent=False)),
# other views still work too
url(r'^admin/', include(admin.site.urls)),
]
I specify urlpatterns as a list, as Django 1.10 requires. The redirects are not permanent by default since 1.9, so you need to explicitly set permanent=True if you want browsers to cache this, though when debugging I find it better to start with False.
This approach allows you to use something like create-react-app or Yeoman frontend generators that package a built, minified frontend app into a single folder (like dist/). You then e.g. use a script to move that into Django's static files folder (e.g. myproject/static/) and serve it from Heroku.
What Ian wrote about wanting to use something like S3 for your static files stands, but sometimes you just want to start simple with one repository, one Heroku dyno and still be able to use Django + a SPA. Also, using something like WhiteNoise makes serving static files from Python pretty OK and allows you to
later on easily put a CDN in front of your static files.
Note: for user-uploaded files you should still use an outside service like Amazon S3 or Backblaze B2 (which is 4 lines of code to integrate).
Serving Media Files
WhiteNoise is not suitable for serving user-uploaded “media” files. For one thing, as described above, it only checks for static files at startup and so files added after the app starts won’t be seen. More importantly though, serving user-uploaded files from the same domain as your main application is a security risk (this blog post from Google security describes the problem well). And in addition to that, using local disk to store and serve your user media makes it harder to scale your application across multiple machines.
For all these reasons, it’s much better to store files on a separate dedicated storage service and serve them to users from there. The django-storages library provides many options e.g. Amazon S3, Azure Storage, and Rackspace CloudFiles.
Note 2: on production with DEBUG=False there are issues, so check out this WhiteNoise issue for a solution.
Note 3: Turned this answer into a blog post here.
Note 4: since writing this, I've been tweaking the solution more and more for frontend routing, so I ended up releasing a new django-spa package suited for simple serving of single-page apps from Django.
I'm creating a website with django. There isn't much static content ( maybe 20 images, and 5-10 css/javascript docs).
I read up on Managing Static files in django. Do I need to deploy my static content on a separate server, or will it work fine since I have very little static content? currently, I'm accessing all my css files and images with the actual path name instead of using "{{STATIC_URL}}".
First you need to use {% static %} to access static files. Please see Django's official docs on this.
Answering your question: you do not need to keep your static files on a separate server but it is highly recommended. The main reason is performance. They will be served directly from HTTP server avoiding additional load on application server. Also, they will be cached by server/client.
You can find a lot of article on this topic. Also check official docs: deploying static files.
You will at least need an HTTP server running on whatever you're running your django project from, and it's highly recommended that you use a separate server for your static files apart from your app logic.
Secondly, it's very bad practice not to use {{ STATIC_URL }} or a similar item. Absolute paths are evil. If the project changes machines, or if it needs multiple versions, etc. These paths could very well change.
I've found plenty of advice for how to tackle static files in Django 1.x. Is there a best practices way to go about doing so?
There are may approaches to serving static files in Django, but Django 1.3 introduced a new option to handle them. Basically, you can define specific directories at a project level or at an app level that contain static media. Then via a management command, 'collectstatic', you can copy all of the static files in your project directory to a separate directory (likely external to your project) that is served by your webserver. This solves a lot of complications of the previous approaches.
1) It allows 3rd party apps to easily include static files in a standard way. No more creating symlinks from your webserver directory to locations inside of individual python/django modules.
2) It gives you more control over where your webserver can host its static files. For example, you can define all of your static media inside of you project under version control, but then copy it all to an external location anywhere on the filesystem. This prevents having to point your webserver to a location inside of your project.
3) Is splits out static media that that will never change from static media that is uploaded by a user using something like a FileField. This is good because you likely want to keep site-level static media in version control (to be installed on your dev servers), but user-submitted content will upload to a different directory (unlike versions of django prior to 1.3).
I think this functionality used to be a 3rd party module that was merged into core.
Here are the docs:
https://docs.djangoproject.com/en/dev/howto/static-files/
Basically there are a few new settings.py variables:
STATIC_ROOT - This is a directory on your filesystem that will be served by your webserver. When you run ./manage.py collectstatic, all of the static files from your project and it's apps will be copied into the directory that you specify here.
STATIC_URL - This is the url that you will set to represent what url base your content will be based from. If you set this value to "/static/", then "/static/" will prefix all urls of static media that included. You will also use this variable in your templates. For example, in your template, you could specify something like:
<img src="{{ STATIC_URL }}logo.png">
The STATIC_ROOT settings variable specifies where static files are copied to, but you also need to provide a location of where static files are copied from. This can be done by creating a directory in your individual Django apps called "static//", similar to what you would do for templates within an app. Upon running the collectstatic command, Django will copy all of the static files from all of the "static/" directories in all of your apps to the STATIC_ROOT directory. You can also use the STATICFILES_DIRS settings variable to define project-level directories to copy static media from.
Though there are many ways to serve static media, I think this is a nice api set in place by Django that will help with better integrating 3rd party modules. The fact that this feature is now included in core could give some indication that this approach may have gained some momentum.
Hope this helps,
Joe
I'm hosting a site on WebFaction using Django/mod_python/Python2.5. I've recently run into the concept of static files (when setting up my Django admin).
From what I understand, serving static files is simply the idea of telling the server to serve files directly from a specific directory, rather than first routing the request through apache, then mod_python, then django, and finally back to the user. In the case of WebFaction this helps especially since there are two Apache servers that your request must go through (your app's server and the main public server).
Why is it that when I setup Django's static files, it only needs the /media folder in /contrib/admin? Is it just that all of Django's static content is related to the admin panel?
When I want to serve my own static content (images, css, etc.) should I include it in the same /media folder or set up another alias for my own content (/my_media)?
Yes, the static files used by Django are pretty much related to images, javascript and css for the admin. All other static content comes from your application. You can keep both sets (yours and the admin) under the same server. Just set the appropriate folders in the settings file.
http://docs.djangoproject.com/en/dev/ref/settings/#admin-media-prefix
http://docs.djangoproject.com/en/dev/ref/settings/#media-root
http://docs.djangoproject.com/en/dev/ref/settings/#media-url
See this post for a little more information:
Django and Static Files
Django's static files (e.g. js, css, images, etc.) are all in the media folder, and are related to the admin panel.
On WebFaction to save processing power, and more importantly memory, it is better to serve these from your secondary apache server (or even better from nginx or lighttpd) without having to go through mod_python and Django.
I use the following folder setup for my files:
media
css
js
img
etc
admin
css
js
img
See http://forum.webfaction.com/viewtopic.php?id=1981 for how to setup nginx as your secondary server on WebFaction if you are interested.