Generic Dangers

Here at the Texas Tribune, we started using a project called django-chunks some time last year. Consider this post a cautionary tale and think long and hard before you start using. We didn’t. We’re paying the price.

The Promise

django-chunks gives you the ability to inject arbitrary chunks of HTML into any template inside Django. You load up a template tag library, call a templatetag, and you’re off to the races. No more waiting on clients (or other departments) to get you copy. “Here’s the chunk, go to town,” you tell them.

That seems pretty good, right? We’re all lazy, that’s why we program. The idea of making a computer do something for us tends to be at the core of why most programmers got into programming. Second only to making computers do the work is making other people do the work, so django-chunks let’s us off load that work to someone else.

The Problem

Once you’ve started making things chunks, everything becomes a chunk. It’s a golden hammer of sorts.

This field needs to be copy edited once in its entire existence? Bring in the chunks!

This type of thinking is shortsighted at best, and harmful at worst. This morning I took a look at our join page only to discover that we were giving users a security error due to a mishandled chunk. An image URL had been entered as http instead of https, mixing insecure content in to a secure page. Yes, there was a chunk created who’s sole purpose in life was to be edited to change out an <img> tag!

The Solution

Don’t use chunks. The case above is where a simple model should have been used if we really need to let non-technical people change out the image. We have a hard requirement on https on that page, and as programmers we can enforce that.

Django is meant for building custom stuff. Go do that. Use things that help you build that custom stuff faster, but don’t go looking for turn-key. Someone else’s answer to the problem isn’t going to be as good as what you could have built.