Using elastic beanstalk, I run the command manage.py collectstatic in a .config file during deployment. The config file is located in the .ebextensions folder.
In settings.py STATIC_URL = '/static/' STATIC_ROOT = 'static' https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create-deploy-python-django.html On Sat, Nov 5, 2022 at 7:15 PM David Nugent <dav...@uniquode.io> wrote: > An article I wrote on this topic last year for fellow developers at work > who were similarly confused. > > HTH! > > *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. > > On Sun, Nov 6, 2022 at 11:03 AM led zee <prasanna.k...@gmail.com> wrote: > >> As a recent Django new user I was having a lot of trouble with static >> files as well. Basically couldn't get Admin CSS to work. >> >> We are using whitenoise now. Apparently that is helping solve the problem. >> >> On Saturday, November 5, 2022 at 12:35:31 AM UTC-7 nishan...@gmail.com >> wrote: >> >>> Hi all, >>> >>> I deployed the django project to AWS ec2 instance using nginx and >>> gunicorn but the static file is not loading at all. >>> >>> Can someone suggest where did I do wrong? >>> >>> Note - I've not created Profile before deploying >>> >>> Here is my settings.py file >>> STATIC_URL = 'static/' >>> STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') >>> STATICFILES_DIRS = (os.path.join(BASE_DIR, 'static'),) >>> >>> Project URl - http://54.242.38.208/ >>> Github- https://github.com/Nishant-Sagar/BaskinSolar >>> >>> Thank you for your help, >>> Nishant >>> >>> >>> >>> >>> >>> >>> >>> -- >> 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+unsubscr...@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 >> <https://groups.google.com/d/msgid/django-users/899a8d1e-8c21-444b-9c9f-215c2a6cd6e8n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAE5VhgVL-GpAdeHnf8MWNr6hHZshNECZPWnDFggYbY87U78xXA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAE5VhgVL-GpAdeHnf8MWNr6hHZshNECZPWnDFggYbY87U78xXA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. 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.
