Content Components to Consider When Designing a Blog
Background
When beginning a blog project your needs to handle content are small because, well, there isn't much or any content. The obvious place to start is with a model for an article/post. But quickly you'll find there are other types of content that needs to be treated differently and separately.
This article is a discussion on how I've chosen to break apart different content and how I've grouped or otherwise indexed the content to make retrieval better.
Content Types
In my experience with blogs, and in my experience building this particular project, I've found that content tends to fit into a handful of different buckets. Some of these will be obvious and others perhaps less so. Don't over think your structure or over-engineer your project either. If there was a content type I didn't have a need for initially, I wouldn't spend any time building features around it.
Let's dig in.
Pages
Before you begin writing blog posts, you're going to need to build out a few primary components for your website. At the very least you'll need a home page and pages for your privacy policy as well as terms and conditions. Additionally, you may have other high-level pages like an about page, and so on.
Likely, you'll want at least some of the content presented on pages like these stored in a database and not statically coded. That way, you can use whatever backend you use or build to update content without needing to update source code.
If you're using Django, the you have the Flatpages app at your disposal. This is a really powerful tool I highly recommend using if you're building with Django. Take a look at two articles I wrote earlier on past implementations with Flatpages:
If you're not using Django, you can easily build your own data model since there aren't a lot of moving parts. At the most basic level, you just need a field to store content and another to store the URL. And depending on your set up you may not even need the URL field.
Other fields you could include in a pages model may include fields to handle data for meta tags, title and subtitle, etc.
Posts
Probably the most obvious of the data you'll need to manage for a blog is posts or articles. This, after all, is the whole point of any blog project. If you're using Django, you could once again use Flatpages to manage your posts. I personally prefer to manage this particular model directly and opt not even to extend the existing Flatpages model.
When building this model, the primary fields I'm interested in are title, subtitle, and content. I like storing title and subtitle directly in the model rather than opting to store those in the content field so I can control the elements that are rendered.
For example, any page should only even have just one heading 1 tag. To enforce this, I store the title as a model field and then set up my WYSIWYG editor to not allow heading 1 tags. When the content is rendered, only a single heading 1 tag is created and the title is inserted.
Just as with pages, I would also have fields for storing meta data for managing SEO. Other fields that may be useful to consider here would be author, date created, date updated, and so forth.
Images
When you write blog posts, you're going to run into situations where images will complement your written content. Assuming you'll want more than one image associated with a blog post at times, then you'll need a separate model with a one-to-many foreign key relationship to manage your images.
This model will need to include at a minimum a field to store the image's URL to wherever it's stored and a field to relate the image to a particular blog post. Strictly speaking, the foreign key isn't actually necessary since you'll be providing the images URL directly into the image tag in a blog post's content. Storing the which article the image relates to isn't going to affect this retrieval at all. Where I think there's benefit though is specifically for cascading deletes. If you delete a blog post you'll probably want to remove any associated images. It's unlikely that images would be re-used across posts. Object store is a direct cost to us for hosting our content. We want to minimize that cost. Thus, we don't want to store images needlessly.
This article I recently wrote goes into greater detail on my approach to images: How Do You Embed Images in a Django Blog From a WYSIWYG Editor?.
Referrals
Now we're starting to get to the less obvious types of content you may wish to manage. When including an outbound link in your content, you'll likely want some way of managing resources like this. Perhaps you want to see which links your visitors engage most with. Or maybe you're tracking outbound referrals to see what content creators you may want to collaborate with. I implemented my system so I could detect if outbound links become broken so that way my content doesn't refer to bad locations. Either way, tracking outbound traffic could be useful.
There's different ways to approach managing outbound links and some implementations are more or less popular than others. I recommend researching this topic deeper before making design decisions because there's considerable path dependency.
One approach would be to store the links directly in a data model. You use an internal link to identify a resource and then hit a database to retrieve the link you want to refer out to. The benefit here is that if the link needs to be updated you only have to make a change in one place. The downside is you now have a database hit required to process a user action.
Another approach would be to store the link directly in the content but point to an internal redirect that accepts the link as an argument. For example:
www.example.com/external-redirect/?url=google.com
With this approach, I don't need to ask the user to wait for the system to retrieve the resource because it's being directly passed as an argument and the redirect engine can simply return this argument as the new destination for the browser. To have a similar amount of control and oversight over outbound links, you can then store (preferably asynchronously) the link each time a redirect is processed.
I prefer the second approach to the first because it's less invasive to the user experience.
Another idea could be to use javascript on the page, avoiding a redirect completely, and having the browser send back to the server the URL of an outbound link with the user clicks on an anchor tag.
Affiliate Marketing
Links I would definitely store in a database would be links for affiliate marketing. Additionally, I would want my own way of tracking how many times these resources are accessed since this will directly determine your revenue and you'll want means of keeping your counterparty honest.
Short-Form Content (Experimental)
Having a separate data model for short-form content is a new idea. I'm not convinced one way or another. Maybe having a separate model for short posts isn't necessary and instead redundant? The question I'm trying to answer is whether I want shorter blog posts to commingle with longer posts. Does a 2,000 word article belong next to something that's 200 words? I'm not sure.
Indexing
Once you have your models defined for your content, you need to index your content to make it easier for your visitors to find related content and thus boost engagement. The obvious choice is a category model that you'll set up as a foreign key to your posts and other content.
I prefer to keep categories very high level. My goal is to keep the count as low as possible.
In order to provide more granular indexing, I prefer using some sort of tag. If you're building with Django, I like the django-taggit package.
Categories and tags will provide a lot of dimensionality to group and index your posts. But there comes a point when your indexes themselves become content! I would consider a way to store some sort of content to preface or introduce the index. Maybe this isn't necessary for tags since they'll be a lot of them as your content volume grows. However, I would definitely consider introducing pages for categories with some form of content.
Final Thoughts
Blogs are fun projects to build. I've certainly enjoyed the process. When you get to building, you find that not everything fits into the tidy box of 'blog post.' So, we'll need to build other models to store and maintain our content as it develops and grows in different ways and dimensions. Furthermore, we'll need a way to keep all of this content organized with appropriate indexing. I hope the ideas shared here help you on your way to building your blog!
