I put static files under a app directory which is related to the static files.
for example,
image.jpg is used for templates under exmapleapp. so I locate image.jpg file in a directory /project/exampleapp/static/image.jpg
In Debug=True settings, Dajngo finds static files automatically by django.contrib.staticfiles. If you put static files projoject directory /project/static/, you can set STATICFILES_DIRS = []in settings.py or add like urlspatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT) in urls.py(if you want to serve static files manually)
so far, is nothing problem in development right? but you want to deploy, you need to do collectstatic. I am confused from now.
This is what I thought initially.
step1 : you work and test your code in local with DEBUG = True in setting. you continously save your code in git repo.
step2 : you are ready to deploy your code in server. you clone your repo and set apache server for running django framework properly(Alias static, WSGI Daemon process). you do python manage.py collectstatic to serve static file with apache server.
step3 : you keep work in local to improve your code and apply this improvement into your code in server with test.
I got confused and got questions.
Q1 : if you do collectstatic for deployment, there will be static folder(according to STATIC_ROOT settings) with all static files which is spread around in each app folders.
do you do collectstatic in local and send only the static folder which collects all to server? or do you do collectstatic in server according to Static Alias setting in Apache server?
Q2 : Do you change DEBUG = False and ALLOWED_HOSTS =[server IP] in local and save code in git repo and pull it in server??
well, now I am confused with working during development with github and deploying it to server with github with Django settings.
Tell me if you can't understand my question clearly please.
You are using static(settings.STATIC_URL, document_root=settings.STATIC_ROOT) for serving static files in development mode. But in production, (means DEBUG = False) it will be empty list. (static returns empty list). Then collectstatic, in you can use development or production.Its intention is to copy all static files to STATIC_ROOT.So
Q1: Everyone do collectstatic on production to serve static files through webserver(Apache, Nginx)
Q2: For production and development write different settings file. You can see here for ex How to manage local vs production settings in Django?
Related
With django (python server) is possible to add more that one path to serve static files using STATICFILES_DIRS = ("C:/some/path/static_two",) on settings file, and works fine, but on production server, in my case IIS, is that possible?
I tried adding two virtual dirctories each one whit different paths/locations, but doesn't works, the static file from the second directiry "C:/some/path/static_two" doesn't shows.
Someone can help me on how configurate IIS two serve static files from more that one location.
thanks in advance.
You are confused about what that setting does.
STATICFILES_DIRS is the place(s) where static files are copied from when you run manage.py collectstatic. The place they are copied to is STATIC_ROOT, which is a singular directory. You need to set up your web server to serve files from there, not from STATICFILES_DIRS.
I have a Mac running OS X 10.9.3. I am trying to setup a Django application backed by a PostgreSQL database served by gunicorn, with static assets served by NGINX. I'm an old hand at Django with MySQL running with the developement server (manage.py runserver). But I'm new to setting it up with virtualenv, gunicorn and NGINX. So I'm following the instructions here.
My Django Project is being served successfully at localhost:3026. As a test of the database connectivity, I wanted to take a look at the Django Admin interface. I visited localhost:3026/admin/
I have included a screenshot below.
Why does this admin page look so ugly? It lacks the neccessary graphical interface and css that it is supposed to have? It looks like NGINX is not properly serving up those static assets. How can I troubleshoot and fix this issue?
EDIT:
After I posted this question, I did python manage.py collectstatic. That went and successfully copied all the static files to where they were supposed to (I think?) live in /opt/myenv/static. You can see the output of that command here. I then re-started gunicorn and nginx. I thought that would fix it. But unfortunately it didn't. The issue remains. In my Django settings.py file, I have configured the STATIC variables as follows:
STATIC_ROOT = "/opt/myenv/static/"
STATIC_URL = '/static/'
Try run command,
python manage.py collectstatic
If the commands executes successfuly, the static file would be generated in your project path, and then if you config the right static path, the web page will be correct.
From the Django Docs:
Deployment django.contrib.staticfiles provides a convenience
management command for gathering static files in a single directory so
you can serve them easily.
Set the STATIC_ROOT setting to the directory from which you’d like to
serve these files, for example:
STATIC_ROOT = "/var/www/example.com/static/"
Run the collectstatic management command:
$ python manage.py collectstatic
This will copy all files from your
static folders into the STATIC_ROOT directory.
Use a web server of your choice to serve the files. Deploying static
files covers some common deployment strategies for static files.
What's the purpose of copying the files, why not just serve them from the directory they live in within the app?
Why not just serve your static directory? You might use more than one app, and some of your apps may not be under your control. Before the staticfiles app existed, you then had to either manually copy the static files for all apps to a common directory, upload them to your CDN, or symlink them to the document root of your web server.
The staticfiles app established a convention: put static files for each app under a static directory and let Django do the work for you.
The STATIC_ROOT can be on a different machine than the application, so copying your static files to the static root means that you can serve your static files from a different server (CDN FTW!) which you wouldn't be able to do if those files where only located within their respective app directories.
I created a new django app (with dj-static), enabled the admin app, started the server and to my surprise, the css files in the admin were available even though i did not run collectstatic.
So, I created a few static files in my static directory and then when I ran collectstatic, the CLI showed the admin static files being moved to the static root folder along with my other static files.
How does the static files for admin work without collectstatic? And if it works without collectstatic, why move it to static root?
Thanks.
You don't need collectstatic for any app when you're running under the development server. collectstatic is for moving apps' static files into a central location so that they can be served with the asset server.
I have a Django app on Heroku, with staging and production environments. Static files are hosted on S3. I'm streamlining my deployment process and plan to set up fabfiles once I have things working manually.
How can I configure collectstatic to push to multiple places? If I run it locally, it uses my dev settings (with a local STATIC_ROOT). If I run it on one of my Heroku apps (heroku run ./manage.py collectstatic), then it can't grab the files (since .slugignore ensures they're never pushed to Heroku). The same applies if I include collectstatic in my Procfile.
I'm also using django-pipeline, though it's not yet doing much since I'm stuck on the collectstatic bit.
UPDATE
In response to Marat's question, I tried passing a settings file as an option to collectstatic: ./manage.py collectstatic --settings=project.settings.prod, but got an error: Unknown command: 'collectstatic' I checked on the server though and Installed Apps does include django.contrib.staticfiles and I can also run collectstatic remotely, so I'm not sure what would cause that.
You can set the environment variable DJANGO_SETTINGS_MODULE so you don't need specify --settings everywhere:
heroku config:set DJANGO_SETTINGS_MODULE=project.settings.prod
First, if you are going to serve static via CloudFront, you can use custom origin and always use local STATIC_ROOT. Actually it has some advantages over S3 source, eg gzip support.
Another good thing you can do is to have environment dependent settings in a separate file and then import it in settings.py, eg:
local_settings.py (not in project repository, yet you can have local_settings.py.example):
#environment dependent settings
DATABASES = { .. }
CACHES = { .. }
STATIC_ROOT = 'your_path/static'
settings.py:
import local_settings
I've just replied a similar question on Upload Media from Heroku to Amazon S3. If you customise your settings to take in account environmental vars, you can use filesystem storage backends locally and S3 storage backends when pushing to Heroku. This will collect and upload your static files when your slug is compiled.