I have no idea what I can be missing.
Relevant portion of setting.py, running MacOS Ventura|Montgomery,python3.10, django4.1.3
DEBUG = True
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'geographie',
'habitat',
'siteornitho',
'debug_toolbar'
]
STATIC_URL = '/static/' #with or without slash at beginning
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
# STATICFILES_DIRS=[
# "siteornitho/static"
# ]
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'
base.html
<!DOCTYPE html>
{% load static %}
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link type="text/css" href= "{% static 'siteornitho/css/main.css' %} ">
<link rel="stylesheet" href= "{% static 'siteornitho/css/fiche.css' %} ">
<title>Document</title>
</head>
Static Structure populated by mange.py collectstatic
static
βββ admin
β βββ css
β β βββ autocomplete.css
β β βββ base.css
β β βββ changelists.css
β β βββ dark_mode.css
β β βββ dashboard.css
β β βββ fonts.css
β β βββ forms.css
β β βββ login.css
β β βββ nav_sidebar.css
β β βββ responsive.css
β β βββ responsive_rtl.css
β β βββ rtl.css
β β βββ vendor
β β βββ widgets.css
βββ debug_toolbar
β βββ css
β β βββ print.css
β β βββ toolbar.css
βββ siteornitho
βββ css
β βββ fiche.css
β βββ main.css
http://127.0.0.1:8000/static/admin/css/base.css WORKS
http://127.0.0.1:8000/static/siteornitho/css/main.css NOT FOUND
http://127.0.0.1:8000/static/siteornitho/css/fiche.css NOT FOUND
http://127.0.0.1:8000/media/siteornitho/images/2022-10-24-16-03-40.JPG WORKS
How are you running this? (Are you testing using runserver, or some other server?)
What is your DEBUG
setting?
You show your STATICFILES_DIRS
setting as being commented out, why?
@KenWhitesell. Using runserver. As indicated above, DEBUG=True.
I commented out STATICFILES_DIRS after I ran collectstatic to see what difference it would make.
The runserver does not automatically serve static files from where collectstatic copies files. It serves files from the directories that STATICFILES_DIRS specifies. If you want to serve files from your STATIC_ROOT directory, then you need to add STATIC_ROOT to STATICFILES_DIRS.
See The staticfiles app | Django documentation | Django and Settings | Django documentation | Django for more detailed information.
Well, what I uderstand of STATICFILES_DIR as I read again this section How to manage static files (e.g. images, JavaScript, CSS) | Django documentation | Django is that if I donβt have static files outside my apps I donβt have to specify anything in it. Hence I set STATICFILES_DIR=
According to above link:
- I have django.contrib.staticfiles in INSTALLED_APPS
- I have STATIC_URL = βstatic/β
-
- am using the static template tag in my base.html file
- I reorganized the folder structure inside the siteornitho app like the tree below as suggested in bullet 4 of Configuring Static Files section
siteornitho app
βββ static
β βββ siteornitho
β βββ css
β βββ fiche.css
β βββ main.css
In light of all this. as far as it goes for serving my files by runserver it should be ok since DEBUG is true and django.contrib.staticfiles is in INSTALLED_APPS
Regarding your comment about adding STATIC_ROOT inside STATICFILES_DIR, when I do this:
STATIC_URL = 'static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATICFILES_DIRS=[STATIC_ROOT]
it throws an error:
django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:
ERRORS:
?: (staticfiles.E002) The STATICFILES_DIRS setting should not contain the STATIC_ROOT setting.
WARNINGS:
?: (staticfiles.W004) The directory β/Users/mariost-gelais/Documents/programming/python/guidedessites/staticβ in the STATICFILES_DIRS setting does not exist.
Anyway, serving files from STATIC_ROOT directory is not necessary until I can at least serve some css
Ok, letβs take a step back.
First a side note: Serving static files in development is completely different than serving static files in production. As a general rule, STATIC_ROOT should be completely outside your project. In a production environment, Django will not be serving those files and shouldnβt have access to them. As a result, while Iβm surprised by that error message, it does make sense.
In development, itβs the staticfiles app that serves static files. This means that the only settings that matter are STATIC_URL, STATICFILES_FINDERS, and STATICFILES_DIRS (if the finder is configured).
The STATIC_URL is the prefix used for static files. You have STATIC_URL = βstatic/β, which means that any url requested as static/whatever/file.xxx
is going to look for the file named file.xxx
in a directory named whatever
in any of the directories defined in STATICFILES_DIRS (if FileSystemFinder
is defined in the finders) and in the static
directory of each app (if AppDirectoriesFinder
is defined).
So, based on what Iβm understanding from what Iβm seeing so far, you have an app named siteornitho
, with a file in that app in a directory structure static/siteornitho/css/main.css
. If you have STATICFILES_FINDERS configured with the AppDirectoriesFinder
(which I donβt see) along with the staticfiles
app (which I do see), along with the static reference to siteornitho/css/main.css
(which I also see), then this should work. (It works for me using these names in my test system.)
Note, you can test access to static files using the findstatic
command.
1 Like
I took several steps back after reading your feedback. Back to square one, I returned to the django tutorial and git cloned it. The settings in this project are very basic for handling of static files:
βSTATIC_URL = β/static/β and
ββdjango.contrib.staticfilesβ in INSTALLED_APPS
βproject has a folder /polls/static/polls that holds style.css.
This is all working fine.
So I mimicked this on one of the app in my project. Still not working. Then I realized I had DEBUG=False. I donβt recall having switched this to false. So bizarre but pretty much a week-end wasted. On the positive, it forced me to read and read again the docs.
Thanks for your time Ken.