Sometimes it’s better to update an existing post than to write a new one. Maybe there’s an ongoing conversation in the comments thread, or news is breaking over the course of a day. Sometimes I’ll post a poll, then reuse the same post for the results, to keep discussion together. The problem is that not everyone will get the notice that the article has changed.

After posting a question on Feedly’s Google+ page, I confirmed that Feedly (and no doubt other readers) uses the post GUID to decide whether to fetch content. If it’s seen the GUID before, it assumes it’s already seen the content, and stops looking at it.

If you’ve never delved into RSS markup, you’ve probably never noticed this field, but the GUID is a “generally unique identifier” used to tell feed readers whether they’ve seen an article before. A new GUID means a new post. Most of the time, you don’t want that to happen, because you don’t want it adding the same post over and over again every time you fix a typo or change a headline.

Under limited circumstances, though, it might make sense to tell reader software that the updated post is a new one.

A StackExchange post pointed me to a filter hook that can be used to change the GUID. WordPress uses the ID-style permalink by default, because it should be unique, but it’s important to remember that the field is only an ID, and isn’t used as a link — so you can modify it without worrying about it staying a valid URL.

The response suggested to just append the modification date, but I didn’t want to do that. I frequently update old posts to fix typos, update links, remove dead links, etc. So instead, I added a custom field that I can fill out when I make a big enough change that I want the post to show up as new again.

// Modify the GUID in the RSS feed after major revisions (but not after every
// little change) so that clients like Feedly will pull the updated content.
function ktv_feed_guid_revisions($content) {
	$revised = get_post_meta( get_the_ID(), 'updated', true );
	if ($revised != "") {
		$content .= "?updated=$revised";
	}
	return $content;
}
add_filter('get_the_guid', 'ktv_feed_guid_revisions', 7);

I’ve got it in a functionality plugin for now. When I make a change that I really want to update everywhere, I add a custom field called “updated” and give it a value – usually a number, so that I can add to it if I have something that I update more than once while it’s still new enough to show up in feeds.

I wrote this months ago, but never got around to publishing it. Yesterday’s 10 ways to optimize your feed for feedly reminded me it was still sitting in my drafts, so I dusted it off.

I’ve been using Pocket lately to offload “Hey, this looks interesting” articles from times when I really should be doing something else to times when I have, well, time.

  • It syncs a copy of the article to each mobile device, which means I can see something in the morning, save it to Pocket, then read it on my tablet at lunch.
  • Feedly talks to it easily. I’ve even linked it up with IFTTT so that tapping “Save for Later” on the tablet will add an article to Pocket.
  • Speaking of IFTTT, I’ve also set it up so that saving an article as a favorite in Pocket also adds it to Delicious.
  • The Android app will accept shares even if there’s no network connection, then sync up when it’s online. That means I can look over a newsletter in Gmail at lunch, save the links that look interesting, and archive the email. Then I can read the article at work or at home…or the next time I’m out somewhere, after it’s synced.

I’ve also started using the text-to-speech feature to listen to articles in the car while driving to and from work. The voice is fairly decent despite the usual flat tones and lack of natural rhythms, but there are a few oddities that take getting used to.

  • # is always read as “hash.” This makes it really odd for comics articles, which frequently talk about issue numbers. “Batman Hash 123” just sounds wrong.
  • Italics are…always…emphasis, and presented by…pausing…rather than changing tone. This makes it…awkward…for anything involving lots of titles.
  • It parses words, rather than using a dictionary, and can’t always figure out whether initials should be read individually or pronounced as a word. This usually works fine, but occasionally leads to phrases like “tah-kay-down notice,” “link-uh-din” or “pohs terminal.” On the other hand, it figured out “I-triple-E,” so I imagine it’s got a dictionary for special cases.

I set up 404 Notifier when I moved my Les Mis commentary to its own blog, to catch anything I might have missed while getting content moved and the new site set up. I then added the RSS feed to Feedly.

After a few weeks, I started noticing some odd links showing up to /r/bienvenu, but I couldn’t find anything that linked to that URL. Then I looked closer and realized it was Feedly itself that was hitting the link!

Basically:

  1. Broken URL gets hit.
  2. 404 Notifier adds the hit to the feed.
  3. Feedly retrieves the feed.
  4. Feedly follows the URL!
  5. Return to step 1.

The timing is inconsistent, but I think Feedly might be hitting the URL whenever I look at the list of “articles,” maybe checking for an image to use for the card in magazine view. And based on the first instance in the DB, I think it may have been a URL I used to test the plugin when I first installed it, then forgot.

For now, I’ve just removed the feed from Feedly. I’m considering altering the plugin to skip hits from Feedly, but I can probably just turn it off now that the blog has been up for a month. It’s served its purpose. If anything, it might make more sense to put it on this site to see if I missed any redirects (though I haven’t actually removed the old copies of the posts yet).