Using Disqus
March 29, 2012
Previously, I'd implemented my own commenting system for the blog; however, I really don't want to reinvent, build and maintain the wheel. I'd prefer instead to rely on existing projects that do it better. So halfway through the process of experimenting and writing about creating the commenting system, I was pointed towards Disqus.
Disqus satisfied my original needs of being simple to implement and protecting against spam. Then it goes further to provide a whole plethora of additional features.
Adding Disqus was incredibly simple and the documentation did a really decent job of making it that way. First I added the commenting script to the bottom of each post:
Secondly, I wanted to display a comment count for each post in the index:
That's all there was to it. Now, without any further maintenance, I have a fully-featured commenting system.
Adding Comments (Part 2)
March 25, 2012
This is the second of two posts that show how to add commenting to a blog site. The first part went into how to create the model, show comments in the site, show comments in an index view and a little bit of styling. This part will go into how to add a commenting form to a post.
As discussed in the previous part, I'd like to avoid spam comments. I've chosen to deal with this by implementing reCAPTCHA as part of the comment form.
To use reCAPTCHA, you'll have to create an account for the site. Upon creation, you'll receive public and private keys that will be used further. In addition, you'll be linked to a Developer's Guide for implementation.
You can then install recaptcha-client via pip:
The recaptcha-client package allows us to easily contact the reCAPTCHA servers in order to validate the request data users will provide you with.
You'll also want to add your reCAPTCHA private key provided by Google to your settings.py file:
Now we can create a simple comment form in our template by adding the following:
You'll want to change a portion of the URL in the script and noscript tags to have the public key provided by reCAPTCHA.
Next, we'll add the url route to urls.py for our add-comment requests:
Finally we'll implement the view in views.py:
Now we're done!
Vim: Changing Buffers With Keys
March 17, 2012
I'm slowly converting from some editors such as Notepad++ and the behemoth that is Visual Studio to Vim. One of the irritations is constantly type ":bn" or ":bp" in order to switch between buffers when working on multiple things at once. I find it strange that, by default, Vim provides shortcuts for moving about tabs (gt and gT), but does not allow for as easy a switch between buffers.
In a search for answers I came across many solutions to the problem and chose the following:
This addition to the .vimrc file translates ALT+<left arrow> and ALT+<right arrow> into the previous and next buffer movements respectively. Further, and this is rather critical, it forces that action. This will ignore the fact that your buffer has unsaved changes.
So, as a slightly safer alternative, you can opt for:
This, like many of my other configurations, is available on my personal configurations GitHub repository.
Adding Comments (Part 1)
March 4, 2012
Most blogs have is the ability to add comments to posts. I have mixed feelings about the idea. Certainly it's great to get or provide feedback on a post, but at the same time I want to avoid (as much as is possible) spam. So, in all, I have a pretty simple set of requirements:
- Simplicity: I just want a commenting system. Bells and whistles are not only optional, but distracting.
- Spam Deterrence: While I view anything that makes it more difficult to comment as an irritation to actual people, I'd like to keep the site free of garbage.
To meet these requirements, in Part 1 I will establish a Django comment model object, use it in a few templates and and add a bit of CSS styling. Part 2 will finish up with allowing outside users to add comments, using reCAPTCHA to deter spammers.
Getting started, what I'll want to do first is to add a Comment class to the blog's model.py file.
This is a pretty straightforward object. The "post" foreign key allows us to associate the comment with one post. The "username" and "user_url" fields allow the user to identify themselves and give a link back to the location of their choosing. The "body" is a freeform text field and the "posted" field is an auto-generated date and time so that we can tell when a comment was made. Finally the "__unicode__" method is for display purposes in admin.
Now we simply add this class to the database by syncing to the database.
From here we can can start to use this in our templates. We'll add comment links to post in our index page first:
We're making use of two really cool Django template tag features here: "with" and "pluralize". "with" allows us to define a complex name in simpler terms and has the added bonus of avoiding multiple database calls. Here we're determining the count of comments on our post object. Using that in conjunction with "pluralize" we can create a link with the number of posts and the apporpriate plurality.
This is great for the main index, but what about the actual comments? We'll render actual comments in the post-specific template:
We're iterating through each comment rendering the specific details. The amount of divs used here might be a little overkill for our purposes, but some will definitiely have value in styling.
This gives us a different color to differentiate from the post body, a little separation to make it easier to tell one comment from another and a little bit cleaner look to the individual comments.
While this isn't the final solution, you should now be able to run the local development server, add a comment to a post and see what it looks like. Part 2 will pick up where we've finished by giving users the ability to add their own comments including reCAPTCHA integration.
AutoSlugField
Feb. 29, 2012
Django SlugFields are a great way to quickly label model objects for usage in URLs (among other uses). In my original blog Post model implementation I used a simple SlugField. It quickly became obvious that there was a problem with this: I had to create the slugs.
In an attempt to find something that automatically generated the SlugField, I came upon a StackOverflow post on the subject. Of all the ideas posted on this subject, the one I found most interesting was the use of a special "AutoSlugField". In that flow of thought I came across the django-autoslugfield package.
It can easily be installed via pip:
From that point you can then use it in something like a simple Post model object like so:
The AutoSlugField comes with a ton of options. In the example above, I've chosen to source it off my Post title, indicated that I'd like it to be unique and limited it to 50 characters (the default for a SlugField).
So, it's committed and working great! All that said, I'm wondering if simply identifying the SlugField as a prepopulated field might be a better idea. Something to play with later!