Static Files in Django

So if you’ve read my earlier post, you’ll know that I’ve had problems with my static files before. But I thought my troubles were over. Then today, I decided to add a few things to my Django blog project, went into the admin to test some stuff and there was no CSS! My blog itself still had the CSS I wrote, but the admin had none. I then went and quickly looked at the live version, but that was fine. I’m honestly not sure what I’ve done that could have affected the admin CSS not showing, but I guess it was something. So, it was Google time!

I first browsed a few Stack Overflow posts, but none were particularly helpful. I usually find all kinds of useful information there, but it wasn’t working out for me today. Then I found this: Django Static Files.

I’d read about the collectstatic command before but not in any context that made it seem like it would help me. But it explains a lot.

So I ran this from my project folder: collectstatic

I was informed that this would overwrite existing files but I have version control so I said ‘yes’! Of course, it didn’t really overwrite my files anyway since it was just adding Django’s admin folder. This solved my problem, but I was still curious about what exactly I was missing about static files to begin with.

I read Django’s official documentation on the matter here:

I thought I looked at that when I was having trouble with uploading my static files to Heroku, and maybe I did, but didn’t know enough to understand what I was reading, or something. It happens.

So I tried to adjust my static file situation to follow Django’s instructions. I’d originally had my static folder within my ‘blog’ folder, ‘blog’ being a Django app. That was how Django Girls had me set it up. I guess if I’d run collectstatic it would have put those folders in a static folder in my main directory, so that Heroku would have seen it. I’d ended up making that folder manually in order for my deployment to work. But Django Girls never mentioned using collectstatic. They also had you putting your CSS folder directly in the static folder, while Django recommends using appname/static/appname/css/style.css so that if you have multiple apps with static folders, and some have CSS files of the same name, you won’t run into the problem of only one of them working. So I adjusted my folder structure accordingly.

I then ran collectstatic again, and my newly created blog/static/blog/ folder with all my blog app’s static files was added to the base static folder. I deleted my manually added files, which were in the static/css folder. This broke my CSS but I was expecting that. I had to go to my style declaration to specify that my CSS file was now in blog/css/. This is what that line looks like now:

<link rel="stylesheet" href="{% static 'blog/css/style.css' %}">

I then edited my Procfile so that Heroku would run collectstatic:

web: python collectstatic --noinput; gunicorn myblogsite.wsgi --log-file -

Now was the real test – deployment! I was scared. But it worked, sort of. Heroku did indeed appear to collect a bunch of static files, and my live site wasn’t completely broken. But it didn’t have CSS. Only the admin side did.

I found out that I can access my files on Heroku by going to the terminal and running:

heroku run bash
cd static

The first line is to connect, the second line will list all files in the base directory, and the third changes to my static file directory. If you’re reading this I’ll assume you have at least a basic understanding of how to use the terminal and leave the explanation at that.

My project files such as were there in the base directory, as well as my static folder. I went there and checked it out and sure enough, the only folder that was inside was the admin folder. So for whatever reason, my blog files weren’t being collected even though they were when I ran collectstatic on my local project. I even double checked by deleting all the collected files from my blog app and rerunning the command. Yep, they got created. So why doesn’t it work on Heroku?

So it turns out I’m dumb. I had gone and added my static folder to .gitignore now that I knew I was supposed to be building that folder on my server (and it was in the original .gitignore file that Django Girls had me create). But I’d written ‘static/’ as opposed to ‘/static/’ so that was making it ignore all static folders in my project, instead of just the static folder in my project directory root. So Heroku didn’t have my blog/static files at all. When I changed it to ‘/static/’ my blog folder’s static files were uploaded properly so Heroku was able to find them when it collected my static files. And then, yay, CSS on my live website!

Apparently Heroku is supposed to run collectstatic without having to tell it to, but I’m done messing with it for the moment. I’d like to get some real updates on my project so I want to try not to break anything else today. Well, at least not anything else involving static files.

Key takeaways from this experience:

  • Read the docs! I need to get better at that. Honestly, especially when I was just starting, I often found the docs confused me more than they helped. But now I’m starting to understand them better and I realize just how important it can be to read them properly.
  • Double-check your .gitignore. Additionally, your code editor may have a simple way to see which folders and files are ignored. I use Visual Studio Code, and all my ignored stuff is grayed out in my file explorer.
  • Make sure you know what tools are available to you for debugging. It was a big help to me knowing how I could access my Heroku files, so that I could see for sure that my static files just didn’t exist there.

Allowing HTML in Text Fields on a Django Site

One of the things I really wanted to be able to do with my Django blog project was display HTML in my blog posts. I just wanted to be able to use links and some basic formatting. While undertaking this task, I learned a little more about how Django itself works. Like, some stuff updates while your server is running. But some stuff will not take effect until you restart. Read on and you’ll see what I mean.

When I began my research, I first came across the ‘safe’ filter. This is included with Django and can be used in templates like this (surrounded by double curly braces):

post.text | safe | linebreaksbr

By default, Django escapes HTML tags. This stops it from doing that. It definitely isn’t a recommended option if you have users entering data since you can’t trust them (sorry users). Since I’m the only one posting though, I figured it would be okay, at least for the moment. However, it wasn’t working – or didn’t appear to be.

So, I went looking further. I came across a module called django-bleach which appeared to be exactly what I was looking for. I installed it, added the necessary import and changed the TextField in my post model to a BleachField. Unless I just wasn’t reading the documentation correctly, that was all that should have been required for it to work. But, it didn’t. So I then added my own list of allowed tags and attributes, but it still wasn’t working. And then, out of sheer frustration, I added the safe filters back to my templates. And it worked. I don’t know if this happens to other people or not, but I honestly don’t remember at what points I’d restarted my server during all this. I was operating under the assumption that changes would take effect while it was running, and that if they weren’t all I had to do was Ctrl+Shift+R for a hard refresh. That worked for CSS at least. But it apparently doesn’t work for some stuff. Like safe filters.

I decided to get rid of the Django safe filters because I figured it was more safe to just have bleach filtering the tags I chose. And for whatever reason, at that point I did restart my server, and all my awesome HTML was gone. Around this time was when I began to understand that my testing wasn’t really being done properly as I needed to be restarting between these changes, so I had to test everything again. That was how I came to realize that the safe filters worked all along, but django-bleach did not. I’m pretty sad about that, as it seemed like an awesome module. And, I mean, maybe it does work and I was missing something. I’ll probably revisit it later.

In my research I did also come across two modules that allow rich text editing: Django CKeditor and django-tinymce. I didn’t want to add more to my site than I had to, especially since it’s only on free hosting, and I didn’t feel I needed these modules since I’m fine with writing HTML the few times I want it. But I realize they would be a better option in many cases and wanted to include them for anyone reading.

I hope that this was useful information for someone somewhere. I struggled with this issue for longer than I should have when really, all along I just needed to restart my server! But I did learn some interesting things along the way, so it wasn’t a complete waste of time I guess.

Deploying a Django Site to Heroku

I recently deployed a Django website to Heroku for the very first time. It’s a blog, but it’s more of a project for my portfolio than a real blog I intend to maintain. If I ever decide to go to that much effort for one site for myself it will be for a browser-based game like Kingdom of Loathing.

Anyway, I was finishing up the Django Girls tutorial where we deploy our finished website to Heroku, and I ran into some problems. I found it frustrating trying to find how to fix everything that was wrong, and when I finally did I decided to document my experience in case anyone else can benefit.

My blog has PostgreSQL as the database which I understand is the default on Heroku. Your experience may differ if you’re using a different database. Also, disclaimer: I’m not an expert, but this worked for me and I’ll explain as well as I can.

I’m not going to tell you everything from the beginning because it’s already been done so well on the Django Girls tutorial. You should go there first and follow the instructions, but come back here before deploying, because it will not work.

One important thing I’d like to mention is that you shouldn’t put your database password or your SECRET_KEY straight into your file. This won’t necessarily hurt the functionality of your site but it’s bad practice as they aren’t protected. Instead you should use environmental variables. I’ll probably post about them in more detail at a later date. For now, just know that you can install python-dotenv and adjust your like this:

from dotenv import load_dotenv

load dotenv()


SECRET_KEY = os.getenv('SECRET_KEY')

Write your database password in the same way as the SECRET_KEY. Then, make a file called .env in the same folder as your file. In this file enter your secrets:


Keep in mind that your variable names have to match. You could technically call these whatever you want but remember that they are variables and have to be referenced by what you write in this file.

Your site should now run locally, but you still have to share your secrets with Heroku. Luckily this is really easy. Just go to your Heroku dashboard, select your app, go to settings and hit the ‘Reveal config vars’ button. Here is where you put in your secrets.

Now you have to solve a problem. Try and deploy your Heroku app now if you want, but it probably won’t work because it won’t be able to collect your static files. Remember when Django Girls had you enter this in your file?:

from whitenoise.django import DjangoWhiteNoise
application = DjangoWhiteNoise(application)

Go ahead and delete those lines. That information is outdated. Instead, you do this in your file:


The new line is the ‘whitenoise’ one, but I included the others so you can see where it has to be positioned. Right after the security line and before the others. That’s it. This made my static files stop working, but I fixed it by moving the folder from my blog app folder to my base project folder – whether that is ‘best practice’ or not, I do not know, but it’s what worked for me. At this point I thought I’d fixed my problem and went to try deploying again, and again, it did not work. My research took me to Heroku’s deployment guide for Django apps. After doing what we’ve just done with whitenoise, they want you to put this in your file:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# Static files (CSS, JavaScript, Images)
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
STATIC_URL = '/static/'

# Extra places for collectstatic to find static files.
os.path.join(BASE_DIR, 'static'),

This broke my static files again locally. My static folder is called ‘static’, by the way. To fix my static files I had to make STATIC_ROOT point to ‘static’ and STATICFILES_DIRS point to ‘staticfiles’ (I got errors when I tried making them both point to ‘static’. I tried deploying to Heroku again, and again, it did not work. In a whirl of frustration I started trying random things and my deploy finally worked when I simply commented out the STATICFILES_DIRS line.

At that point I was super excited, but my live site didn’t work – I was getting a 500 Server Error page. I realised it was database related, since I had a static page which worked just fine and could also get into the admin panel. I made my superuser and entered the admin console, but couldn’t load anything in the database. So, back to Google. Someone said that running makemigrations and migrate on the server was the solution. It was not. Then, someone said Heroku needed the migrations folder. Now, I had added that to .gitignore, since I had read that you could get conflicts if there were different migrations folders being merged into a repository. I also had the impression you just made the migrations again on the server after deploying. I always try to do what is considered best practice, but apparently that information was wrong. I unignored my migrations folder, pushed to Heroku again, and did ‘heroku run python migrate’ to…. migrate the migrations! Well, that worked.

I’m going to mention here that I realise the Django Girls site has you run migrate once your site is up. But at this point it had been like three hours since I’d left the tutorial, and I’d forgotten all about it.

Now you’ve hopefully got your site up and running! It doesn’t matter how simple it is; I feel getting it deployed is a huge step after the ordeal it was for me and it’s something you can be proud of.