Building a Django Blog

Normally, sane people who want to start a blog use blogging services like Tumblr or Wordpress. I had gone the Wordpress route before, however, and after losing all my old blog post data from my old blog I decided I wanted to try hard mode this time and set up the blog on my very own web app. After researching various web frameworks, I decided to work with the Django web framework, AKA Ruby on Rails in Python (please don't lynch me).

Cheating With Blogging Engines

Django itself is straightforward enough to setup, the hard part is actually building a blog app in it. Setting up models, writing views, testing, it's all such a chore. So I did what any strapping young dev does when they're backed into a corner of desperation: cheat by using an open source blogging engine.

Zinnia is an open source blogging app for Django and I like their motto:

"Why should we re-implement something that is already done and reviewed by others and tested?"

Little did I know that installing Zinnia comes with its own set of challenges. The initial setup was simple and easy of course, just like all well known frameworks. However, after I got the generically themed Zinnia boilerplate blog running on localhost, the next step was to actually customize and theme the blog with static css files. This turned out to be a shitton more time consuming than I expected it to be.

Styling the Blog

I should've known that delivering my static css files wasn't going to be as easy as sticking the files into my project. Django provides a system that finds all the static files in your project, then collects them together inside a staticfiles folder, but one typo in referencing your css inside staticfiles and you're fucked. Django gives you quite possibly the most unhelpful error message in this case which basically summarizes to: you're using the staticfiles system in a way that we don't understand; dick off. I spent about a day or two struggling to with this problem only to finally figure out that one of my html templates was referencing the css using the format:

{% static /blog/css/myblog.css %}

instead of

{% static blog/css/myblog.css %}

Did you spot the problem? That's right, because of the leading slash, it interpreted my staticfiles reference as an absolute path instead of a relative path, which gives the static files engine an aneurysm and results in the unhelpful error message that I mentioned earlier. If you ever have vague error messages related to staticfiles, I would recommend checking your file path references and making sure you don't have any miniscule character typos in your file references like I did.

Moving to Production with Heroku

Well after finally figuring out how to include my css files, and then toiling around with the css for a few more days iterating upon the look of the blog, I was happy with how the blog looked and was ready to push my blog to a production environment :)

Heroku is a popular web deployment platform amongst hipsters like myself, because you can get a simple web app running for free! It also helps that it's incredibly easy and efficient to install, and has a nice dashboard interface. Well done, Heroku, no complaints from me :)

Pointing the Domain to Heroku with CloudFlare

After I got the Heroku web app running, I needed to link my purchased domain to the app.

Sometimes you can point your domain to your web app directly from the registrar services that you used to purchase your domain. However, I found out that my registrar Siteground was unable to point to my Heroku web app, because Heroku serves web apps using a dynamic IP address, which is not supported by Siteground. I needed a DNS provider service that could act as the middleman and point to my Heroku app's dynamic IP address.

Luckily I was saved by the DNS service CloudFlare. They provide a feature called CNAME Flattening which in short allows you to point your root domain (like, for example) at an app served with a dynamic IP address. After struggling with the Siteground dashboard for hours trying to figure out how to do the same thing, breaking up with them as my DNS provider and moving to CloudFlare felt deeply satisfying. I still love Siteground as a domain registrar though!

Getting Hacked

Of course, there had to be one last hiccup: my CloudFlare account getting hacked. The day after setting up my CloudFlare DNS, I came home from work feeling elated, getting ready to type up my first blog post, and I saw a series of emails from CloudFlare indicating that my account had been accessed several times during the day from various unrecognized IP addresses. The attackers were unable to or forgot to change the password, so I was able to immediately regain access, and see the results of their work.

The first thing I noticed was that my domain was now redirecting to some random spam website instead of my blog app, so luckily the damage wasn't too disastrous. It turns out that the attackers had set up a redirect rule on my CloudFlare account to force my domain to redirect to their shitty little spam website instead of my app. Deleting the rule once I figured how to actually use my CloudFlare dashboard was simple enough, and I made sure to comb the dashboard for any other malicious activity--luckily it seems like all the attackers wanted was some quick and easy traffic to their spam site. Hopefully I'm not wrong about that and they haven't installed some sort of dormant malware to delete my blog's codebase when I'm least suspecting.

I quickly set up two factor authentication for my CloudFlare account afterwards. Lesson learned, Jonathan: never skip out on the two factor authentication if it's offered by a service that you're registered to.

Finally done...!

Finally, my blog was ready for me to start adding content. It was a long and unnecessarily painful journey to set up a blog on my own without using a blogging service, but IMO it was worth it, if even just to say that I fucking did it. The educational value was nice too.