Full Text vs. Summary Feeds

It’s a hot topic among bloggers. Full feeds or Summary feeds? I’ve exchanged some words with a reader about it, but I’ve always been sitting on the fence.

RSS Feed Basics

For those of you who don’t have a clue what I’m talking about, let me take a moment to cover the basics.

This blog (and its individual categories or topics) is available in two formats: HTML viewable in a Web browser and RSS viewable in a feed reader (or aggregator). The HTML format includes nicely designed pages (if I do say so myself), access to polls and comments, and full site navigation features. The RSS format includes just the most recent posts in whatever format a subscriber’s feed reader displays them in.

The benefit of the RSS format is that content is automatically delivered to subscribers as it is published. There’s no need to visit the site to see what’s new. The feed reader will automatically gather all new content for reading at the subscriber’s leisure. You can learn more about RSS on Feedburner’s Feed 101 page.

Full-Text vs. Summary Feeds

Bloggers normally have the option of creating feeds as full text feeds or as summary feeds. (To set this option in WordPress, go to Dashboard > Options > Reading. We provide full instructions in our WordPress book.) A full text feed publishes the entire content of each post to the feed, making it unnecessary for the subscriber to come to the source Web site. A summary feed publishes just the beginning of each post to the feed, making it necessary for the subscriber to come to the Web site for the remaining content of each post he wants to read. (In WordPress, this is only the first 55 words.)

It’s pretty well established that full text feeds attract more subscribers than summary feeds, so if getting more subscribers is a blogger’s goal, full text is definitely the way to go. But full text feeds have several drawbacks that have kept me from jumping on board:

• Full text feeds eliminate the need for subscribers to visit the site at all. All your hard work on blog design is completely wasted on feed subscribers.
• Because full text feed subscribers are less likely to visit your site, they’re also less likely to comment on entries. This reduces the interactive aspect of your site. I think this is a serious problem, since RSS subscribers are more likely to have something constructive to say about technical topics, which is what I often write about here.
• Because full text feed subscribers are less likely to visit your site, they’re also less likely to click ads there, thus potentially reducing your revenue stream. (Of course, it’s a valid argument that RSS subscribers are more tech savvy and less likely to click ads in the first place.)
• The appearance of feeds in a subscriber’s feed reader is dependent on settings within that reader. As a result, entry formatting can be lost, resulting in ineffective appearance to the reader. For example, headings may show up as boxes in the margins rather than as headings.
• Full text feeds are more likely to be scraped by splogs. That means your content may be used by “bloggers” to build content on their advertising-heavy sites, as well as link farms and other unsavory Web traffic-generating or revenue-generating schemes.
• If you write very long entries or include many posts in your feeds, you could reach feed length limitations with FeedBurner (if you use it).

For summary feeds, the only drawback is that they’re less likely to get subscribers since a lot of folks don’t think it’s worth subscribing to a feed if the entire content does not appear in their feed reader.

Sitting on the Fence

With all of this in mind, I’ve been using summary feeds since I switched to WordPress about a year ago. I haven’t been very interested in building the number of subscribers. This drew a lot of flack from a subscriber, especially when I couldn’t make up my mind and switched back and forth between the two kinds of feeds over the period of a number of weeks. I assume that she dropped her subscription when I stuck with summary feeds.

Now I’m more interested in building my subscriber base. So I’ve switched back to full text feeds. It’s been about a week, and my feed has already been scraped once, with a pingback that I assume was supposed to help the scraper’s Google placing. (I deleted that pingback comment as soon as I found it.) One subscriber (Miraz) has already joyfully commented on the switch. Others haven’t commented. I don’t expect them to, since there’s no way to comment from within the feed reader software (see drawback list above).

Anyway, I’m encouraging subscribers to my blog now and it’s a full text feed, so I invite you to subscribe. But please do stop by once in a while to share your comments with other site visitors.

Upgrading to 2.1: The New Privacy Options

One of the new features of WordPress 2.1 is the Privacy Options administration panel. This panel offers two options that control whether your blog is visible to search engines and archivers:

• I would like my blog to be visible to everyone, including search engines (like Google, Sphere, Technorati) and archivers. This option, which is selected by default, allows search engine spiders and robots and crawlers to index your site and include it in search results.
• I would like to block search engines, but allow normal visitors. This option makes your blog invisible to search engines and archivers but allows normal visitors to access it.

Why would you choose the second option? Well, suppose you have a private, family blog which is maintained solely for the use of your family. You wouldn’t want Google listing your entry about Aunt Sally’s colonoscopy as part of its search results, would you? The same goes for company-only blogs that are on the Internet but contains relatively confidential information.

Keep in mind that the Privacy Options do not prevent unauthorized site visitors from reading site content. Only password-protecting a post or securing the blog behind a firewall can do that. Instead, the search engine blocking feature just reduces the chance of someone stumbling onto the blog by accident as a result of a search.

To access this new feature on your blog, open Dashboard > Options > Privacy.

The Importance of XHTML Validation

Miraz has told me again and again — validate your pages after making changes to your WordPress theme templates. She even advised readers in our book, WordPress 2: Visual QuickStart Guide. And every time I validate, I find errors, proving that it’s a step I really do need to take.

Yet I continue to skip this step when I tweak my theme’s template files on every single blog I run.

This morning, I got an e-mail message from someone named Tine who wrote:

I’m completely new to Wordpress but found your site because of the book you have made and was curious.

Are you aware that your blog don’t look good in Explorer 6? Some of the text to the left is cut off.

I use Explorer 6 on XP Pro and 1024×768.

Uh-oh.

I fired up my PC and loaded up my home page in Explorer 6. The situation was worse than Tine reported. What appeared did not look much like my site at all. And in the status bar, Explorer was politely telling me that page had errors but didn’t offer any way to find out what they were.

My first instinct was to panic. But then I remembered the XHTML validator at http://validator.w3.org/. I ran the page’s URL through the validator and settled down to find and fix the 110 errors it found.

Sheesh.

The main culprit in this case was some code I’d inserted into my post.php file to display RSS links beside category names in each post’s header. This rather slick piece of coding, which I was pretty proud of, contained the dreaded unencoded ampersand error. That means I’d included & in the code when I should have included & in the code. That error was all over the place, but Explorer seemed to be choking on it in the new code. When I fixed its first occurrence and reloaded the page in Explorer, the page appeared fine, although the status bar smugly reported that there were still errors in the document.

Other problems included <ul> and </ul> tags without <li> and </li> tags. Oops. And <p> tags without </p> tags. (It appears that ecto was causing that problem in the way it codes Technorati tags. Good thing I’m not using tags in my posts anymore.) Of course, all my Amazon.com book cover links were missing alt attributes. And some of my rotating ads used IMG instead of img for coding. The list goes on and on.

Of course, if I’d been validating the XHTML after each template change as Miraz recommends, I would have caught these errors as I introduced them. I wouldn’t have spent my Sunday morning debugging code.

Have I learned my lesson? I think so. At least for a few days.

Manage uploads

It’s easy to upload files (such as the image here of a New Zealand native parrot called a kea), and to add them to a post. WordPress 2.1 has brought some welcome improvements though to the area of file uploads.

You upload an image as before, and as explained on page 58. What happens next is slightly changed, as you can see in this screenshot:

Previously you had to click on the thumbnail to see options for sending the image to the Editor. If you didn’t know that, it could be very confusing, especially for new or infrequent users. Now you see the relevant options right beside the image. It’s much clearer.

The improvements don’t stop there, though. If you click the Browse All link, or choose the new Uploads section of the Manage panel of the Dashboard you can view all files you have uploaded, not just those attached to a single post (click the thumbnail for the full-size screenshot):

To delete a file, click on it in the Browse or Browse All area, click on the Edit link (which then becomes an Insert link), and click the Delete File button.

Simple blog, simple update

After my summer holiday I have a busy schedule and several blogs to look after. I don’t have time right now to explore complex update procedures, or to worry about breaking my heavily customised blog, so I decided to use the simplest blog I run for my first WordPress 2.1 update. And I’m pleased to report that it was plain sailing the whole way.

One blog I maintain isn’t really a blog at all: its sole purpose is to supply an RSS feed for a website that runs on a cumbersome Content Management System. We don’t intend for anyone to actually visit and view the blog, but expect readers will view the RSS feed in a feedreader. We definitely don’t want comments, trackbacks or pingbacks. We use the default theme, with the addition of one paragraph of text directing stray visitors to the real website. Our Links in a single category, all point to useful areas of the real website. The only plugins we use are Bad Behaviour and Spam Karma. All our settings are heavily restrictive.

I decided this would be the perfect testing ground for the 2.1 update.

First I read Maria’s articles here, then I backed up the database, the theme folder, and the wp-config file. Next I read the whole way through the upgrade instructions. I also downloaded the new version of WordPress and fresh copies of both plugins, expanded the files and checked the documentation.

The next step was to deactivate the plugins and delete most of the WordPress files from the server, as explained in the upgrade instructions. I then uploaded the new files, visited the upgrade page and followed instructions, activated the two plugins and viewed the site.

Since that particular ‘blog’ uses the default theme with only one tiny modification, I actually deleted the existing theme folder and replaced it with the new one. I had then only to add in the extra paragraph, taking it from my backup.

As we have learned to expect from WordPress, this update was extremely smooth and extremely quick. The most time-consuming part was reading the instructions.

My conclusion: if you haven’t yet customised your blog to any great extent, and if you follow instructions, your update to WordPress 2.1 should be smooth and simple.

Upgrading to 2.1: Fixing the ecto Category Problem

I use ecto to post to all of my blog-based Web sites. It’s a great offline post composition/editing tool that gives me all of the tools I need to get the job done.

Yesterday, I updated this site to WordPress 2.1 Today, I discovered that I could no longer load or “refresh” the site’s entries in ecto. When I tried, ecto would get hung up while “retrieving categories” for the last entry created.

I poked around in the ecto support forum and came up with this thread. Evidently, I wasn’t the only one having the problem. The ecto folks claimed it was a WordPress problem that had to do with the xmlrpc.php file (which resides in the root directory of a WordPress installation). I followed the thread until I came up with this fix by gusleig:

You must edit your xmlrpc.php. Find:

'categoryId' => $catid,

and change to:

'categoryId' => (string) $catid,

I followed these instructions, saved the modified xmlrpc.php file, and tried ecto again. It worked.

The folks at WordPress are aware of the problem. If they haven’t already fixed this on WordPress.com, I assume they will shortly. And the xmlrpc.php file modification will be in place in the next release of WordPress, so be sure to make sure you have a problem before you try this fix.