Lap Cat Software Blog

Unless you’re the Tolstoy of blogging — Does that even make sense? It’s like being the Gandhi of boxing — you’re probably not writing thirty WordPress posts a day. At my rate — the Def Leppard of blogging — I’m lucky to produce thirty a year (not counting my posts under the pen name “Arianna Huffington”). However, it is possible for one post to receive thirty comments in one day, especially if it contains provocative statements, e.g., AppleScript, Die! Die! Die! or Please leave your comments below. (This is assuming that you allow comments. And that someone reads your blog. And that the someone is not an NSA agent.)

Unfortunately, WordPress uses the same limit on the number of items in a syndicated feed for both the main post feed of the blog and for the comments feed of an individual post. By default, that limit is 10 items. Thus, if you try to follow an active comments thread on a post via the feed, you’re likely to miss comments (unless you’re one of the scourges of the internet who have their feed readers set to check for new articles every two minutes). It completely defeats the purpose of subscribing to the comments feed if you can’t track the comments with the feed. As a solution, you could raise the overall WordPress item limit, for both posts and comments, but this may increase the bandwidth of your web site significantly, enormously if you’re one of the angels of the internet who put the full text of their posts in the feed.

Fellow blogger Daniel Jalkut of Red Sweater Software has filed a feature request for a separate limit on comments feeds. However, you don’t need to wait until WordPress 2.7 for this request to be implemented, because you can implement it now by hacking your own WordPress installation. With Daniel’s help, I was able to get this to work in WordPress 2.5.1. You just need to modify one file, wp-includes/query.php. The ending of line 1380 in query.php is currently

	DESC LIMIT " . get_option('posts_per_rss'));

You need to modify it as below, replacing 100 with your desired item limit for comments feeds.

	DESC LIMIT 100");

You also need to modify the ending of line 1437, replacing

	DESC LIMIT " . get_option('posts_per_rss');

with

	DESC LIMIT 100";

That’s all there is to it! My usual disclaimers apply here: I take no responsibility for breaking anything of yours, for breaking anything of anyone else’s, or indeed for anything that happens in the universe. I do offer this guarantee: if my hack doesn’t work for you, I’ll gladly refund my consulting fee.

Please leave your comments below. AppleScript, Die! Die! Die!

Although I abhor self-promotion — much as Roger Federer abhors winning tournaments — someone must take on this thankless task. (I had to fire my publicist, because he had never heard of me.) Thus it is with great regret and sorrow that I announce my latest contribution to the WordPress open source project. It was just one minuscule twitch for mankind, yet one ginormous vault for a man, viz., yours truly.

Now some critics might claim that the security issue was trivial. In my defense, I would argue that critics are doo-doo heads. Except the ones in New York: they all love me.

It seems dead, though the clock is still ticking. (Countdown to extinction?) Anyway, I’ve just updated my own extensive list of cocoa blogs and other favorite feeds, which you can download from the Downloads section of my sidebar. FileMerge will reveal the changes in my all-important favor. Remember bloggers, X-Mas is coming soon, not to mention Y-Mas and Z-Mas. I’m keeping track of who’s naughty and nice — mostly by intercepting your wireless packets. If you’re nice, you’ll get a hot dog and a shake.

The network has decided to renew my series for at least one episode. WordPress 2.3 is approaching release, and I’m pleased with the progress that it has made in supporting syndicated feeds. The patch I submitted to fix the Atom feed modification date bug has been committed to the trunk. RSS 2.0 feeds still don’t give modification dates, but that could be considered a personal preference. (As can RSS 2.0 itself. Of course, no one would prefer the worse to the better, as Socrates would say, if he were 2500 years old and spoke English.)

Other syndication bugs that have been fixed in the trunk include checking the last modified date of posts rather than comments for comments feeds, an obsolete Atom feed template, and checking the last modified date of unapproved comments for comments feeds. WordPress 2.3 should be a good update for feed readers such as you and feed readers such as Vienna.

Time to go. Joan Cusack is calling again.

This is the first post in what I hope is a series, which I’ll call “WordPress Bug Fix Near Saturday”. And while I’m naming things, I’ll call this first post “Episode IV: A New Hope” (to be followed, no doubt, by “Episode V: All Hope Dashed”). I’m very happy to report that the ETag parsing bug has been fixed in WordPress 2.0.7. Thus, if you’re running WordPress 2.0.7 on your site, you no longer have to comment out the following line in the file wp-includes/classes.php:

@header("ETag: $wp_etag");

My logs confirm that WordPress is now correctly parsing its own ETags and sending out HTTP 200 and 304 responses as appropriate. The Penultimate Warrior is victorious and undefeated! Note, however, that none of the bugs that I reported before the Warrior started Running Wild® (cp. Going Wild®) have been fixed yet.

Speaking of my web site logs, they contain a list of phrases that were used to find my site from internet search engines. I’d like to share a few of them that have caught my eye:

1. instructions+for+using+the+thighmaster

   Squeeze, release, repeat. You’re welcome.

2. how+do+u+declare+a+pointer+to+an+array+of+pointers+to+int%3f%3f+in+c+language

   int * (* ptr)[];

3. talk+to+cat+software

   That doesn’t exist, Dr. Doolittle. Try meowing.

4. cat+lederhosen

   I’ve given your IP to the SPCA.

5. betamax+the+sausage+and+the+mouse

   These aren’t the droids we’re looking for.

6. what+does+ns+stand+for+i+cocoa

   NeXTSTEP. Next!

7. circle+k+employee+uniforms

   I’m so very sorry, dude.

8. if+jeff+s+usual+is+a+hint+for+a+password+what+is+the+password

   Stop trying to hack into my account, you scoundrel!

No sooner had I posted this, I noticed this. Case closed. I win by TKO.

I intended to post this on Friday. As they say when receiving a crappy Christmas gift, It’s the thought that counts. (They lie.) I should probably give myself a break and just change the official name to WordPress Bug Near Friday. Well, so be it. Make it so. Engage. Energize. Giddyup!

Usually I’m bemoaning the existence of HTTP 304 (Not Modified) responses, but this time the problem was the non-existence of them. (Can there be such a thing as non-existence? Where would you find it? And can you deduct it from your taxes?) I noticed when looking through my web site logs that feed requests from NetNewsWire always received an HTTP 200 (OK) response from WordPress, never 304, which means that NetNewsWire downloaded the entire content of a feed on every request. Since my web site gets more hits from NetNewsWire than from any other browser, that’s quite a lot of bandwidth used. (Relatively speaking, that is. In the grand scheme of things, my page ranking is right below the site for Grasshopper Enthusiasts of Eastern Ontario.)

Brent Simmons, the creator of NetNewsWire, was kind enough to talk to me about the problem, despite the fact that my app, Vienna, has undoubtedly taken away some sales from him. (In fact, I was all set to purchase NetNewsWire myself until I discovered Vienna.) I’m not worried about Brent, though: I heard that NewsGator paid him something like a trillion dollars for NetNewsWire, give or take. Plus he gets as many Café Lattes as he likes. Anyway, he explained that WordPress does not handle entity tags correctly.

In addition to Last-Modified headers, WordPress sends out ETag headers, which are basically gobbledygook strings that identify web content. Some web browsers, such as Vienna, only send conditional If-Modified-Since requests based on Last-Modified dates, but a browser can also store ETags and send them back on subsequent visits to the site as part of conditional If-None-Match requests. If the ETags don’t match the current content on the site, then there is new content that needs to be downloaded. NetNewsWire sends both kinds of conditional request. Unfortunately, WordPress does not parse its own ETags correctly on receiving If-None-Match requests — there seems to be a problem with quoting — so a match is never found, and it always sends a 200 response, along with the full feed content.

Brent passed along a suggestion to remove or comment out the following line in the file wp-includes/classes.php:

@header("ETag: $wp_etag");

After that, WordPress no longer sends out ETags, so it relies totally on Last-Modified dates. I’ve been testing this modification for a week, and NetNewsWire now receives both 200 and 304 responses, as appropriate. Moreover, my bandwidth has been cut by more than half. Thanks, Brent! We should form a tag team wrestling duo to pin down the WordPress developers and make them fix their feed bugs. My wrestling name will be the Penultimate Warrior.

Yesterday was Thanksgiving in the United States. Thanksgiving is a day for giving thanks, obviously. More important, it means that we Americans get to be ungrateful boors every other day of the year. Don’t you love holidays? Now that I don’t have to be thankful again (or eat again, for that matter) until next November, I’d like to take this opportunity to rip on WordPress. For the most part, WordPress works admirably. However, as I’ve noted once or twice, it doesn’t play well with syndication, which as you may know is something I’m familiar with. A number of you have WordPress installations on your own web sites, and even those of you who don’t have WordPress installations probably experience these bugs by following the syndicated feeds of this site and others in your favorite feed reader (Vienna, perhaps).

Today’s bug, which still exists in WordPress 2.0.5 (but has been fixed by me on this web site), afflicts comments feeds : for example, the main comments feed for the blog as well as comments feeds for individual posts. In order to prevent spam — as well as egg, bacon, spam, and sausage — I moderate all comments. No matter how long it takes for me to approve a comment (not long, usually, unless I’m asleep: that’s when I’m a Viking), the comment will appear with the date and time it was written. That’s fine, except that if your feed reader is polite like Vienna and sends an If-Modified-Since header in the request for articles, WordPress looks at the date of the latest comment in the database, regardless of whether the comment has been approved. Thus, if your feed reader checks the comments feed after a comment has been written but before it has been approved, the feed will give an HTTP 200 response (”OK”, “Yea!”, “Come hither”) and send the feed data, though thankfully WordPress won’t actually send the unapproved comment. Until another comment is written, however, the feed will give an HTTP 304 response (”Not Modified”, “Can’t Touch This!”, “I have a headache tonight”) on all subsequent checks, so you won’t see the comment in the feed after it’s approved.

By the way, if you wonder why I read the Hypertext Transfer Protocol document, take a glance at section 13.1.4. It’s good stuff, folks! I have yet to see a browser that follows the suggestions given by the RFC. Core Animation should make it easy.

Anyway, to fix the bug in WordPress 2.0.5, you need to modify the function get_lastcommentmodified in the file wp-includes/comment-functions.php. Replace the switch statement with the code below. You’re just adding $wpdb->comments.comment_approved = '1' AND to each of the cases.

switch(strtolower($timezone)) {
    case 'gmt':
        $lastcommentmodified = $wpdb->get_var("SELECT comment_date_gmt FROM $wpdb->comments WHERE $wpdb->comments.comment_approved = '1' AND comment_date_gmt <= '$now' ORDER BY comment_date_gmt DESC LIMIT 1");
        break;
    case 'blog':
        $lastcommentmodified = $wpdb->get_var("SELECT comment_date FROM $wpdb->comments WHERE $wpdb->comments.comment_approved = '1' AND comment_date_gmt <= '$now' ORDER BY comment_date_gmt DESC LIMIT 1");
        break;
    case 'server':
        $lastcommentmodified = $wpdb->get_var("SELECT DATE_ADD(comment_date_gmt, INTERVAL '$add_seconds_server' SECOND) FROM $wpdb->comments WHERE $wpdb->comments.comment_approved = '1' AND comment_date_gmt <= '$now' ORDER BY comment_date_gmt DESC LIMIT 1");
        break;
}

Alas, WordPress Bug Friday is already over again, too soon! Remember that there are now only 30 shopping days left until Christmas. You can get me anything from the store.

Ok, I lied. I won’t be talking about Cocoa programming in this post, except insofar as Vienna is a Cocoa program. This is really more of an announcement than a discussion, though. The Emergency Broadcast System has instructed me to annoy you with a series of loud beeps. If this had been an actual emergency, I would have been looting your valuables right now.

Beep! Beep! Beep! People of Earth, your attention, please. The developers of Vienna formally announce the release of … Vienna. Specifically, Vienna 2.1, the exciting sequel to Vienna 2.0. In a surprising turn of events, the incumbent, build 2107, has been upset by the challenger, build 2108. Sadly, build 2107 refuses to concede and is demanding a recount. Meanwhile, build 2109 is already setting up an exploratory committee for the next release. The release notes for Vienna 2.1 can be found in the forum. For those who prefer pictures over text, check out the illustrated list of features.

I would like to thank Steve Palmer for letting me mess with and mess up his app. Hopefully I’ve fixed more things than I’ve broken. I’d like to thank the Academy (Plato’s). It’s an honor just to nominate myself. Thanks to my cats, for helping me type. Thanks to caffeine, in all its forms. Thanks to my user agent, “Vienna/2.1.0.2108″. Finally, I’d like to thank all the little people: Dr. Ruth, Dustin Hoffman, Kerri Strug, Prince, and Ronnie James Dio. (Cue the band.)

My other important announcement is that the blog may be unavailable for a minute or two while I update from WordPress 2.0.4 to 2.0.5. By the time you read this post, it’ll all be over. That wasn’t so bad, was it? Just a little pinprick. Ahhhhhh! If you notice any problems after the update, please contact me. This is a recording. So long, and thanks for all the fish.

Welcome to the second installment of WordPress Bug Friday. You may have noticed that it’s Monday, but … uh … weekends don’t count. Yeah, that’s the ticket! Furthermore, it’s almost the end of Daylight Saving Time, so I’m just getting a head start on rolling back the clocks.

Until I saw it in my web site logs, I didn’t even realize that my blog had an Atom feed. Incidentally, I’m a bit surprised that my logs are filled with requests from NetNewsWire. I am the developer of Vienna after all! Where are you, Vienna users? Anyway, the WordPress template for Atom is obsolete. We’re talking Edsel, Betamax, Eric Clapton obsolete here. The template, contained in the file wp-atom.php, is based on Atom 0.3, which has been deprecated.

The other issue I had was that I revised the post Build settings for Xcode projects on Sunday, but the post didn’t show up as revised in Vienna, which has a neat little feature I added that gives revised articles a green dot to distinguish them visually from blue-dotted new articles. (If you prefer, you can turn the feature off with defaults write uk.co.opencommunity.vienna2 CheckForUpdatedArticles -bool no.) Neither the Atom nor the RSS 2.0 feed showed the post as revised. Indeed, I was getting the dreaded HTTP 304 response (Leave me alone, I’m playing Doom!).

The bug with the (obsolete) Atom feed was that the template calls the same function, get_post_time, for both the (obsolete) issued and (obsolete) modified fields. The correct post creation and modification dates are listed in the blog’s database, so I could use get_post_time for one and get_post_modified_time for the other. With the RSS 2.0 feed, in contrast, it wasn’t clear that there was a bug, because RSS 2.0 has only one default field for item dates, pubDate. I wanted post revisions to show up in the feed, so I replaced get_post_time with get_post_modified_time for pubDate in the WordPress RSS 2.0 template file, wp-rss2.php.

If your WordPress posts have date-based permalinks, do not, I repeat, DO NOT edit the timestamp of an already published post in order to change the date in the feed. (And don’t sit with your back to any doors.) Editing the timestamp will not only change the date in the feed but also change the URL of the post! You’re a very bad man, Jerry, for suggesting this. Fortunately, I was able to repair the damage quickly. Even if your posts don’t have date-based permalinks, editing the timestamp could mess up your archives. To change the date in the feed, use my method of calling get_post_modified_time in the feed template.

I’ve updated my blog’s wp-atom.php file to conform to the Atom 1.0 specifications and made it available for download at wp-atom.txt (the extension has been changed from php to txt). You might want to consider using the attribute type="xhtml" rather than type="html" for the content and summary fields, depending on how your posts are formatted. One element that’s missing from the template is the recommended rel=self link to the feed itself, because I didn’t know how to request the feed link. I’d appreciate help from WordPress experts out there.

Tune in next week, same bat time, same bat channel, for the next exciting installment of WordPress bug Friday! Or maybe some other bat time.