What is the necessity to do collectstatic in django? Why can't I just copy files to the static folder and make my server refer to that folder? Why does that not work?
Convenience? You can manually copy over the static files and there's no problem with doing that, but when you have multiple different folders where static files are stored and you're deploying to a production server, it's much more of a hassle to go individually to each folder and copy them instead of having collectstatic run as an automated task and do the work for you.
Related
I am running a django application on Heroku, and currently using AWS S3 to serve my static files. We store our static files both in static folders per app, and also in a static/ folder at the root of the directory. The static/ folder at the root is about 40Mb large.
Whenever we deploy our app to Heroku, the static files are included in the Heroku slug, so that
heroku run python manage.py collectstatic --no-input can be run from the Dyno itself, which then copies any changed/new static files to our S3 bucket so that they can be served.
The issue is after we go through this process, we now have a static/ folder on the Dyno which takes up about 40Mb of space, and is seemingly useless since our files are being served from our S3 bucket!
Is there a better way to go about deploying our application, and collecting our static files to our S3 bucket but not copying the static files to Heroku?
One way I was thinking was to add all static files to Heroku's .slugignore file, and then configure a way to upload static files to our S3 bucket without using Heroku at all. I'm not sure if this is the correct way to go about it, however, and would appreciate advice on this.
The reason we have been looking into this is our Heroku slug size is starting to grow far too large (~450Mb), and we need to start reducing it.
After some more digging, I found examples of people doing exactly what I was describing above, which is uploading static files directly to S3 without using any intermediary storage. This article shows how to configure Django and S3 so that running python manage.py collectstatic on your local machine will copy the static files directly to S3.
This configuration, in combination with disabling collectstatic on Heroku (https://devcenter.heroku.com/articles/django-assets#disabling-collectstatic) and adding our static files to .slugignore, would be exactly what I was looking for, which was to upload static files directly to S3 without uploading them first to Heroku.
More reading from Django' docs
I'm exploring using whitenoise to serve static files in a Django application that's packaged in a Docker container. In the documentation it says:
As part of deploying your application you’ll need to run ./manage.py collectstatic to put all your static files into STATIC_ROOT. (If you’re running on Heroku then this is done automatically for you.)
Is that really needed? I'm not running ./manage.py collectstatic and static files are still served.
If it's not needed, is it an optimization? I'm trying to avoid having needless steps in my deployment process.
As that quote states, Whitenoise serves files from STATIC_ROOT. collectstatic collects files from STATICFILES_DIRS and any app-specific static directories and puts them into STATIC_ROOT.
But there are two situations where it will serve files without running collectstatic. The first is if your files are already in STATIC_ROOT. They shouldn't be, but it's a common mistake to set the value of STATIC_ROOT to the directory containing the source files. However, in this case it won't for example find the admin files, which would need to be collected.
The other situation is if you are running with DEBUG=True. Whitenoise inherits this value for its USE_FINDERS setting, which makes it look in the same places as collectstatic itself to serve files. Clearly, you wouldn't want to run in production with DEBUG on, but you can set this setting explicitly. But as that docs link points out, doing so will disable the caching and compression features of Whitenoise.
I am new to Mezzanine and not an expert in Django. I am trying to make changes in the default Mezzanine theme. I am doing these steps to override default Mezzanine theme,
python manage.py collectstatic
A new static folder is created which stores all the static files across the project in this folder (STATIC_ROOT). This includes Mezzanine default static files as well from virtualenv/lib/python2.7/site-packages/mezzanine/core/static/
Then I run
python manage.py collecttemplates
A new templates folder is created which stores all the templates across the project in this folder.
Now when I make changes in files from /templates directory I get to see those changes in development server.
but when I make changes in /static directory files I do not see those changes in development server.
to make changes to css files I have to go to
virtualenv/lib/python2.7/site-packages/mezzanine/core/static/ path and then only I can see the changes in development server.
I want to know what am I doing wrong. I do not want to make changes in mezzanine css files, I want to overwrite them form static_root.
In mezzanine and in django sites in general, you should not edit files in the /static folder directly since these will be overwritten each time you use the collectstatic command.
Each of the templates Mezzanine provides can be found in the templates directory of each Django app that Mezzanine is comprised of. E.g the base template in mezzanine/core/templates/base.html.
To edit the templates you’d like to modify, copy them into your project’s templates directory and modify them there. You can also use the collecttemplates command to copy templates over automatically. Run python manage.py collecttemplates --help for more info.
The mezzanine template lookup system is described here. This post may also be useful
OKay, After some research I realized, This is not the way to overwrite templates. You want to copy static folder from Mezzanine package and paste it in an app where you want to use it, then edit that copied files. This is written in documentation for mezzanine, I missed that part.
I'm having an issue with static files piling up on S3 since i'm using the ManifestFilesMixin mixin to give static files a unique name (so clients are forced to load the new content). Since the name is different on each version (duhhh) it's written next to old version of the same file.
Then also i don't like to use the --clear flag on collectstatic since this will (i expect) remove the current files even when deployment has not succeeded yet.
I thought to manually run: python manage.py collectstatic --clear but this seems to not remove the old versions from the bucket?
Anyone thoughts on this?
Paul
I have a very simple question which I was not able to find an answer. Using Django staticfiles app, I call the statics collect routine by typing this command line : python manage.py collectstatic.
My problem is that I've several applications serving statics + a media directory containing user-uploaded files. Django copies all the files to the static directory, including media files!
I just would like Django to not copy user-uploaded files to the static directory when I call python manage.py collectstatic. Does anyone have an idea? Tried --ignore option but without success...
Thank you in advance.
That was a problem of django.contrib.staticfiles.finders.DefaultStorageFinder, try removing that from STATICFILES_FINDERS.
So what exactly doesn't work if you use --ignore?
Though the real solution is not to mix user generated content and static files.
If you keep both types separated you can easily put your static files under version control and don't have to deal with excludes on this front as well. And in fact the separation from media (user generated) and static files is the rationale behind staticfiles:
In previous versions of Django, it was common to place static assets
in MEDIA_ROOT along with user-uploaded files, and serve them both at
MEDIA_URL. Part of the purpose of introducing the staticfiles app is
to make it easier to keep static files separate from user-uploaded
files.
The docs on this topic are really comprehensive: https://docs.djangoproject.com/en/dev/howto/static-files/