Static files is not loading while deploying the project to AWS ec2
Nishant Sagar
Ashutosh Mishra
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANNtL-K_ntgKNAYUd8DHe8wa4bGwHO5da%3DypJfAVN%3DJHj9uCmQ%40mail.gmail.com.
Nishant Sagar
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGDmY64P1vrziiG_%3DX0pMb3YS%2BWv2BqZLLkix2gY%2B4cL3YRsEA%40mail.gmail.com.
Ashutosh Mishra
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANNtL-J6HWZ%3DPk7iYx4nxk%2BYZ_9HXSMQY2kt-FiBa6fDQz2vrA%40mail.gmail.com.
Lakshyaraj Dash
led zee
David Nugent
Django - Statically Confusing
I started learning Django several years ago (and am still doing so today!), and for some time had a real sense of confusion as to how static files worked. Sure, I learned the easy aspects of this pretty quickly, that the collectstatic management command¹ would magically pull all of the static files out of my project and dump them into some other place, where - in the theoretical production model - they would be served by something other than Django. Indeed, I understood this and routinely served static and media content via Nginx or apache directly.
What was often a source of confusion was the magic that made it all happen in Django's settings module. Early in my days with Django, I wondered why files weren't being served as I thought they should - do I need to collectstatic in development or not? The confusion increased when third-party apps produced or processed static content, and there were times when you absolutely did have to run collectstatic to make these files available to the runserver during development. Most other static files did not seem to require this.
Settings
The handling of static content is controlled by a handful of settings, and it is important to be clear about what each setting does. Any confusion simply boils down to not completely understanding these settings and their effect.
The following table details each one and is followed by a brief summary of how they interact and under which circumstances they are important.
STATICFILES_FINDERS
- This is a list of fully qualified classes implementing the Finder pattern (see below).
STATICFILES_DIRS
- This is a list of paths searched for static files (only) by the FilesystemFinder.
STATIC_URL
- This is the url prefix that causes - if enabled - routing of requests to the static files handler, and it only becomes active if configured in your urls.py.
That's all it does. Really.
Please don't confuse this with anything else.
STATIC_ROOT
- This setting determines the target of the collectstatic command.
It is (usually) not useful during development, only at deployment.
Static Files Finders
Static file Finders are the core of Django's static file handling. By default, the STATICFILES_FINDERS list consists of the FilesystemFinder and AppDirectoriesFinder. The first handles static content from paths defined in the STATICFILES_DIRS list (which is empty by default), and the second serves static content from installed apps that contain a static directory.
During development, these Finders handle (or should, some third-party ones do not!) serving static content via Django. In production, they are only used to gather the static content and place it into the STATIC_ROOT where it may be served by your front end of choice (Nginx, Apache etc.).
The Finder pattern supports two primary methods.
• The find() method returns one or more matches against a provided path. This is what the static files handler uses to match url paths requested after stripping the STATIC_URL prefix. If a Finder returns an empty list, no match was found. In this scenario, the all parameter is False, and the function - if successful - returns a single absolute path.
• The list() method returns a list of all static files it knows about, along with the storage associated with each file. The FilesystemFinder associates one storage for each path in STATICFILES_DIRS and the AppDirectoriesFinder allocates one storage for each app with a static folder.
• Access to the files returned is done via the storage object which contains all of the methods required to access static files within its domain.
¹ a management command in Django is issued after invoking the ./manage.py script from the application root directory.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/899a8d1e-8c21-444b-9c9f-215c2a6cd6e8n%40googlegroups.com.
Malcolm MacKinnon
STATIC_ROOT = 'static'
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAE5VhgVL-GpAdeHnf8MWNr6hHZshNECZPWnDFggYbY87U78xXA%40mail.gmail.com.
James
Django doesn't serve staticfiles in production; something that isn't overly apparent. You still need something like apache or nginx or whitenoise to serve static files in production.
Nishant Sagar
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK8W3Xp53j-FKj%3D_160LBSx_tFF7PB0n_jbB_bvDVg9B9dOZCA%40mail.gmail.com.