Django -- Can't get static CSS files to load

Question

I'm running Django's development server (runserver) on my local machine (Mac OS X) and cannot get the CSS files to load.

Here are the relevant entries in settings.py:

STATIC_ROOT = '/Users/username/Projects/mysite/static/'

STATIC_URL = '/static/'

STATICFILES_DIRS = (
'/Users/thaymore/Projects/mysite/cal/static',
)

STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
#'django.contrib.staticfiles.finders.DefaultStorageFinder',
)

INSTALLED_APPS = (
# other apps ...
'django.contrib.staticfiles',
)

In my views.py I'm requesting the context:

return render_to_response("cal/main.html",dict(entries=entries),context_instance=RequestContext(request))

And in my template the {{ STATIC_URL }} renders correctly:

<link type="text/css" href="{{ STATIC_URL }}css/main.css" />

Turns into:

<link type="text/css" href="/static/css/main.css"/>

Which is where the file is actually located. I also ran collectstatic to make sure all the files were collected.

I also have the following lines in my urls.py:

from django.contrib.staticfiles.urls import staticfiles_urlpatterns

urlpatterns += staticfiles_urlpatterns()

I'm new to Django so am probably missing something simple -- would appreciate any help.

Solution 1

Read this carefully: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/

Is django.contrib.staticfiles in your INSTALLED_APPS in settings.py?

Is DEBUG=False? If so, you need to call runserver with the --insecure parameter:

python manage.py runserver --insecure

collectstatic has no bearing on serving files via the development server. It is for collecting the static files in one location STATIC_ROOT for your web server to find them. In fact, running collectstatic with your STATIC_ROOT set to a path in STATICFILES_DIRS is a bad idea. You should double-check to make sure your CSS files even exist now.

Solution 2

For recent releases of Django, You have to configure static files in settings.py as,

STATIC_URL = '/static/' # the path in url

STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),
]

and use it with static template tag,

{% load static %}
<link rel="stylesheet" href="{% static 'css/bootstrap.css' %}">

Solution 3

Another simple thing to try is to stop, and then restart the server e.g.

$ python manage.py runserver

I looked into the other answers, but restarting the server worked for me.

Solution 4

Add the following code to your settings.py:

STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),
]

After that, create the static folder at the root directory of your project.

To load the static files on templates use:

{% load static %}
  <img src="{% static "images/index.jpeg" %}" alt="My image"/>

Solution 5

added

PROJECT_ROOT = os.path.normpath(os.path.dirname(__file__))
STATICFILES_DIRS = ( os.path.join(PROJECT_ROOT, "static"), )

and removed STATIC_ROOT from settings.py, It worked for me

View more solutions

Comments

[tchaymore]

Yes, django.contrib.staticfiles is in INSTALLED_APPS (I edited question above), and DEBUG = True, and I've started server with --insecure parameter, but no luck.

[GDorn]

Try loading one of the static urls directly. Is it a 404 or a 500?

[tchaymore]

Yes, I can navigate to the css directly: 127.0.0.1:8000/static/css/main.css. Loads just fine.

[tchaymore]

Well, it's working now. Not sure what happened, but I'll give you the check.

[GDorn]

Watch the output from runserver when you load the full page. There should be a request for /static/css/main.css and it should have a status code of 200.

[GDorn]

I'm guessing that your browser cached an older, possibly blank, copy of the CSS file, and navigating to it directly forced the browser to reload it.

[Alasdair]

I think you mean --insecure is required if DEBUG=False ;)

[Alireza Farahani]

I have the same problem and I get 404 not found. what can I do?

[Viktor]

And what if we need to run server in production?

[AdamY]

Then you'd want to use DEBUG = False

[CosmoRied]

This worked. The django server cannot find and serve the static files in my local environment without serving them through a URL. adding this url pattern allowed the server to find and serve the file that lives in a directory in the project. I then added {{STATIC_URL}} and the file path - that lives in my app directory/static/appname/css/sass folder. I'm actually using this together with amazon s3 that I use in production, but need to alter the css in a local environment and have the static version displayed before pushing to the server with collectstatic.

[Alex Daro]

Thank you. I had no idea about the --insecure parameter.

[Ryan Efendy]

Worked for me! +1

[John Pang]

$ python manage.py runserver --insecure works for my local server with Google App Engine

[Andreas Bergström]

This answer helped me figure it out

[Pavel Vergeev]

Same for Django 2.0

[Rexcirus]

@GDorn What is the correct practice in production, without using "--insecure"?

[GDorn]

@Rexcirus Don't use runserver in production. It's not made for that. Use gunicorn, mod_wsgi on apache, or uwsgi. Also avoid serving static assets via python at all if you can help it - use a webserver for that. If you absolutely must serve via python, use a library specifically for that purpose, such as whitenoise.

[GDorn]

Don't use runserver in production. It's not made for that. It's not hardened, it's single-threaded, it's inefficient. Use a proper appserver, like gunicorn, uwsgi, or mod_wsgi, and serve your static assets from a proper webserver.

[Cullub]

Could you explain why this works? That would make this a better answer.

[Fatemeh Asgarinejad]

Worked for me! If you have multiple pages which are extended from one main html page you need to add these to all pages.

[help-info.de]

Welcome to Stack Overflow. Before answering an old question having an accepted answer (look for the green ✓) as well as other answers ensure your answer adds something new or is otherwise helpful in relation to them. Here is a guide on How to Answer.

[Jeremy Caney]

This was answered nine years ago by @GDorn. That answer was not only accepted, but has also been validated by the community. Since then, eighteen other people have contributed additional answers—including another highly rated answer from @all-Іѕ-vаиітy which references the same syntax. What does your answer contribute to the conversation? Why might someone prefer this approach over other approaches discussed? Please edit your answer to help readers understand why this is different.