When I started using WordPress last year, one aspect took me a while to understand and refine: blog comments. What’s more, commenting is the most obvious form of interaction on this site.
But I wanted to avoid spam. How badly I wanted to avoid any kind of junk ad, specious link, mindless troll, content leech, and faux search-result queen!
Registering a domain for over a decade gave me the agony of junk email, which comprises the vast majority of messages I receive. This exasperating experience made me only more uneasy and unwilling to open my site to potential splogs and spam.
Testing the waters
I started out hyper-paranoid and became a “Fort Knox of websites,” as a friend put it: I required registration. I required login. I monitored and moderated every comment. I turned on CAPTCHA. All posts had comments and pings turned off by default. I installed a bunch of WordPress plugins: Akismet, Spam Karma, Bad Behavior, AntiLeech, etc. It drove me (and my testers) crazy.
It took some amount of testing and learning before I found a suitable combination of anti-spam tools and rules. Communication should be neither overwhelming to me, nor confusing to readers who wish to share something. Developing a sensible comment policy did not occur right away.
Insight and decision
As I continued experimenting, I slowly became more lenient with the WordPress administrative and plugin settings. But the mind opening inspiration (and realization) came after reading articles by Lorelle VanFossen and my friend Jed. My tests and their posts helped me to become more decisive:
- I’ve chosen to not allow anonymous comments, but non-anonymous users should have the path of least resistance in order to submit a comment. Requiring a name and email is, I believe, a workable compromise between deterring spammers and encouraging dialog. The email data are never published or shared. Registration and login are no longer necessary.
- CAPTCHAs are unhelpful for visually impaired users or graphically limited client applications. Duh! Besides, programs are being developed which can outwit CAPTCHAs. Moreover, quizzes won’t stop humans who manually enter comment spam.
- I don’t need to approve every comment or trackback. I don’t need email notification for every comment or trackback. Really. I don’t. The administration pages and plugins are there to help out. The triumvirate of Akismet, Spam Karma and Bad Behavior make it easier, by working behind the scenes to block out the rubbish.
- I can change my mind. I can (and have) close commenting on ancient articles. I can keep trackbacks open indefinitely, or not. I can delete comments, if needed. The comforting point is that I can treat each article independently. I still have control. >:-)
Looking ahead and looking now
Sure, there are things I want to improve: Allowing OpenID logins so that LiveJournal and TypePad users can use their usernames here. Having a “cancel” button in the comment form in order to reset it, similar to what I’ve seen in some Moveable Type blogs. (Jed, was that a built-in feature of your MT installation? Update (17-April-2007): Yes, it is.) Stronger, smarter blocking of blog scrapers. I look forward to the future when I can make my commenting policy more permissive (e.g., allow anonymous comments), while also having better control unobtrusively (e.g., over Apache, WordPress plugin improvements, etc.).
As it turns out, the majority of blog comments at this site have been spammers of one sort or another. However, none have appeared publicly, so far. This is in huge contrast to my email experience. Many years went by before email clients (e.g., Mozilla’s MailNews, Apple’s Mail.app), server-side tools, or ISP utilities (e.g., SpamAssassin, SpamCop) would filter out the junk. Even now email spam still slips into my inbox uncaught. It’s one of the few advantages of procrastinating so long before having a blog —in my case, migrating my old site to use WordPress like a CMS. Namely because anti-spam tools for blogs happened to already exist during my site’s conversion. Of course, I continue to keep an eye on incoming comments and links —these tools exist to assist. Nothing one cares about is completely automatic or foolproof, including a website! But I feel more aware and confident.
I fixed the plugin so that keyboard navigation works properly (correct tabbing order) in the comment forms of plaintxt.org themes. I changed the
tabindex values in the
submitbuttons() function (around lines 249 through 274) to 7 and 8 for the preview and submit buttons, respectively.
Again, thanks to Austin Matko, the developer of Comments Preview! I wish this functionality were built into WordPress, even if it were offered as a plugin like Akismet.