Blogging 'bout Blogging

I wrote a letter to the Austin American-Statesman decrying the Texas HB 789 provisions to outlaw public Internet. You can read the letter in an entry I blogged over at Save Muni Wireless.

As is typical, the letter was edited prior to publication. Fortunately, the editing was light. The letter already was within their 150-word limit and, thanks to assistance from Adina Levin, was pretty well done. I know you are supposed to rail when the press changes (twists?) your words, but I must admit the changes improved the letter—mostly.

Their editing introduced one significant error. When I viewed the letter as posted to the newspaper's web site, a reference to State Rep. Todd Baxter was mistakenly edited to identify him as a "State Senator." The print version, fortunately, was correct.

I'd always assumed that the online version of a newspaper web site was an electronic duplicate of the print content. Now I see that's not the case.

It's distressing to see that a newspaper could introduce so significant an error into their web content. Aren't newspapers supposed to be held to a higher standard than, say, bloggers? Don't those standards hold regardless of whether the information is produced in print or online?

The traditional pressroom protocols worked fine—the mistake was caught before it went to print. It appears there must be different—and lesser—protocols for web content than there are for print.

The link spam problem has been getting worse on the Austin Bloggers web site, just as it has everywhere else. When the site opened two years ago, we provided an open posting form. Anybody was welcome to submit whatever they blogged about Austin. Last month we moved the form into the member portal, behind a login screen.

The link spam has been a minor annoyance on the front page. I just need to make a few twiddles of the database bits, and it's gone. We'd typically get a few spam postings in the wee hours of the morning. I could clean it out over my morning coffee, and it would be gone long before most people would see it.

The link spam problem for RSS, on the other hand, has been significant. That's because once spam got into our RSS feed, it stayed there. If you were viewing Austin Bloggers with an RSS reader, it probably was looking very spammy to you.

That's because the RSS reader periodically fetches the RSS feed and stores away the articles. When I cleanup the spam it comes off the front page, but I can't remove it from your RSS reader once it's downloaded the entry.

I've now got a solution that should solve that problem. When an entry is removed from the web site, rather than deleting it from the RSS, I'll replace it with a redacted entry.

This solution required an upgrade of our RSS feed, from version 0.91 to 2.0. That's because RSS 2.0 adds support for a <guid> element. The Globally Unique Identifier (GUID) element is a unique identifier for the RSS entry. It typically (and by default) is a permalink, usually set to the same value as the <link> element. But it need not be. Instead, I'm using it to assign a unique identifier to every entry in the feed.

When an article posts to Austin Bloggers, the RSS will look something like:

  <item>
    <title>Get a Bigger Nose</title>
    <link>http://www.example.net/nose-enhancer.html</link>
    <description>Blah blah blah ...</description> 
    <guid isPermaLink="false">entry:1615 [at] austinbloggers [dot] org</guid>
  </item>

When an entry is removed from the site, instead of removing it from RSS, it will be replaced with a redacted entry. The redacted entry for the example above would be:

  <item>
    <title>(this entry has been removed)</title>
    <guid isPermaLink="false">entry:1615 [at] austinbloggers [dot] org</guid>
  </item>

The RSS reader should recognize this as an update of a previously posted entry. The original entry should be discarded, and this version used in its place.

You can see this in action at the Bloglines view of our site. Currently, there is one redacted article showing from February 6.

I hope this technique makes the link spam a little less annoying for our readers, and a lot less effective for the spammers.

It's the craziest time of the year: it's Holidailies time. Now in it's fifth year, Holidailies is a like a crazed dance marathon, but with on-line journal writers instead. Every day over a month-long period, on-line writers will post an article to their personal web site and a synopsis to the Holidailies portal. Those who make it through the month win nothing more than bragging rights. Still, over a hundred crazy writers are willing to do it every year.

This is my second year involved in the Holidailies project. Not as a journal writer, I designed the portal site.

A meetup for Austin-area MetaFilter users has been scheduled for June 3rd. I think I may go. Anybody else?

More info here.

I've been reading a lot about the Movable Type license change. I already noted that I'm unhappy about this. I think this was handled extraordinarily poorly. I've been reading a lot on the issue, not just to see people's responses, but also to pick up hints for possible replacement tools.

While reading the responses, I'm stricken by the complete lack of comment on the matter among the A-List bloggers—at least the ones I follow. I suspect many of them have been placed in an awkward position. They may see the move as ill-advised, but don't want to talk trash about their friends Anil and the Trotts. So rather than comment on this important development, we're hearing a lot of silence.

It's almost like we've got our own little form of media consolidation in the blogosphere.

You know that article I blogged about sticking with Movable Type? Is it too late to take it back?

Today, Six Apart announced a new licensing and pricing structure for the Movable Type weblog platform. Although a no-cost version will continue to be available, it will be severely limited. If you are doing anything more complicated than a single person blog, then you'll probably need to start paying. Depending on what you are doing, you may end up paying some big bucks.

I've been messing around with various online publishing and collaboration tools recently. I found several appealing options for blogging. There are, however, a number of reasons I keep coming back to Movable Type.

Spam Assassin and Movable Type got into a little tussle today. I have comment notification enabled, so I can see whenever somebody posts a comment to my blog and I can respond to comment spam quickly. My favorite part of the MT-Blacklist module is that it adds a de-spam link at the bottom of these notifications. It allows me to remove comment spam with a single click. My blog ends up being pretty spam free, but this depends upon receiving prompt notification.

I was perturbed to find that a bunch of spam had accumulated on my blog today. I never saw any notifications of the postings, so they've just been sitting there all day.

On a hunch I checked my email spam folder and—sure enough—the notifications had been classified as spam and refiled. I never saw the notifications because they never made it to my mailbox.

So, if you are running Spam Assassin (or similar spam filtering tools) you may want to take care to ensure comment notifies aren't classified as spam. I added a whitelist_from entry to my system /etc/spamassassin/local.cf file, and set it to accept all email generated by the web server.

Link: Software Archive: better_spam_protect

In the Movable Type weblog system, the names of entry and comment authors often are linked to their email address. Movable Type has a spam_protect feature to protect these addresses against harvesting by spam spiders. This feature, unfortunately, is not effective.

A new plug-in called better_spam_protect provides improved spam protection. Javascript is used to produce email addresses, thus making it less prone to harvesting. Users without Javascript (and—hopefully—spam harvesters) will see the name, but not the email address.

I recently modified my blog to put the trackback information on the entry page, thus eliminating the separate pop-up. On a stock Movable Type setup this presents a problem. When Movable Type receives a trackback ping it rebuilds the necessary index pages, but it doesn't rebuild the entry page. This means that although the blog main index page may show that a ping was received for an entry, when you go to read that entry the trackback may not be listed. A manual rebuild of the entry page would be required before that trackback was listed.

Phil Ringnalda has published a note that describes how to force an entry rebuild when a trackback ping is received. The note describes a modification to the ping method in the lib/MT/App/Trackback.pm file.

Unfortunately, if you use the popular MT-Blacklist add-on, this method is overridden. For MT-Blacklist v1.63, I had to place the modification in the extlib/jayallen/MTBlPing.pm file.

I made one other change. Normally, Movable Type calls for an index rebuild after the trackback ping is processed. Phil added a second rebuild: an entry rebuild with dependency rebuild disabled. I combined them all into a single rebuild: an entry rebuild with dependency rebuild enabled. I thought that may be a little more efficient, which is a concern since all this is done while the client is waiting for the trackback ping to be processed.

Here is a patch with this change.