Static files (again)

I am trying to dockerize a django app. It looks like it has not been configured for development / debug mode before so I have added some settings around static content

What I can say is that the application launches ok, and serves pages but I am getting errors in the browser console such as

“Refused to apply style from ‘http://localhost:8000/static/css/styles.css’ because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.”

This is to be expected as the content returned is a 404 page, which isn’t css so I get it, that’s ok.

Here’s where it gets weird. If I ssh into the running docker container and run

python manage.py findstatic css/styles.css

It successfully finds the file! So I would suppose the StaticFile finders are able to understand the configuration.

I am running the server with DEBUG mode turned on. This is confired by a print command in the settings file.

The config settings I have are as follows

STATIC_URL = ‘static/’
STATICFILES_DIRS = [
BASE_DIR / ‘static/’
]

The folder structure of the project is such that

<project_root>
/static
/css
styles.css

So I would expect the django.contrib.staticfiles.finders.FileSystemFinder to be able to use the setting in STATICFILES_DIRS to be able to find the file at css/styles.css

As I say this works on the cli inside the container.

I tried to set logging to DEBUG by adding the following

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
        },
    },
    "root": {
        "handlers": ["console"],
        "level": "WARNING",
    },
    "loggers": {
        "django": {
            "handlers": ["console"],
            "level": os.getenv("DJANGO_LOG_LEVEL", "INFO"),
            "propagate": False,
        },
    },
}

But the logged output does not look any more verbose, e.g.

[24/Jan/2025 16:09:26] “GET /static/css/styles.css HTTP/1.1” 200 4300

Further info

Django 4.5 running on Docker using python:3.11 container image

So, can someone give me some pointers as to how to go about debugging / troubleshooting this?

Welcome @suityou01 !

What app server are you using? (gunicorn, uwsgi, something else?)

What web server are you using? (nginx, Apache, something else?)

This is a frequent topic here - there are many threads discussing this type of issue. Searching for things like “nginx static docker” should bring up some useful information.

For starters:

(There are many more…)

1 Like

Side note: This is correct - this is what you’re hoping to see.

Thanks Ken, glad to be here!

I have this in the settings

WSGI_APPLICATION = 'app.wsgi.application'

I see this his a frequent topic but I could not find anything discussed that covers this specific issue, that is to say that DEBUG is set to true, manage.py findstatic is working and yet 404 pages are being returned.

This is just running in a single docker container using manage.py runserver 0.0.0.0:8000

Thanks

Is this for testing / development purposes being used by a single user?

What is returning a 404? The snippet shown above is a 200, which means the reference worked.

It is just for development purposes.
The log shows 200 but in the browser I get a 404 page.
For example

http://localhost:8000/static/css/styles.css

Returns a custom 404 page

python manage.py findstatic css/styles.css

Returns a successful match

The application (inherited) had two settings files in two separate apps loaded into the INSTALLED_APPS, which were fighting each other.

The first set DEBUG=True
The second set DEBUG=False
My print statement was in the first config file so giving me a false impression that application was running in DEBUG mode.

Is it normal to have > 1 settings files in a Django app?
Can you test Debug mode in manage.py shell for more accurate results?
Can Django idiot proof having > 1 settings file with a warning message? (Is there a way to do this)

Django does not load its settings (by default) from apps. It’s loaded from the module identified by the environment variable DJANGO_SETTINGS_MODULE. (It’s set within manage.py if it isn’t currently set.)

If other settings files are being loaded with the file specified there, then your project is doing something non-standard.

(Note: Non-standard does not necessarily mean “wrong”, “unusual” or “incorrect”.)

In your project? Yes. In an app? No. (I’m not familiar with any development pattern that puts a settings file in an app. That just feels like a very bad idea.)

Yes. You can import the settings:

In [1]: from django.conf import settings

In [2]: settings.DEBUG
Out[2]: True

No. In the general case it’s just an import of a file. (But I’d be very concerned about a system designed around the idea of importing settings files from different apps.)

1 Like

Thanks, I concur. I need to advise them to merge the settings files into one in the project root. Thanks for all your help, nice one. :slight_smile: