Raam Dev’s Weblog

I’m following WordPress on Twitter and I was excited to see a recent tweet that WordPress 2.7, Release Candidate 1 had been released. I was very curious to see if comment threading was added or if it had been dropped since Automattic’s acquisition of IntenseDebate a few months ago. (I’m sure I could have gotten an answer to that by poking around on the WordPress Trac, but it wasn’t that important.) Yesterday, I wrote about how I decided not to outsource my comments to IntenseDebate so if you read that post you’ll understand why I’m excited about the possibility of native comment threading.

For testing WP 2.7 RC1, I decided to upgrade an existing blog that I set up a few months ago, but that I haven’t launched yet. My first impression upon seeing the new WordPress Dashboard? Wow. It’s amazingly different (but in a good way). Oh, and there is native comment threading support!

I’ve included some screenshots below, including the Discussion Settings where you can see the new options for comment threading and Avatars. Also, I also did a quick threaded comments test using the default WordPress theme, which you can see at the end. Enjoy!

And for the finale, comment threading!

I’ve been hearing a lot about IntenseDebate recently, in various blog posts and news sites (they were acquired by Automattic, the company behind WordPress, back in September). IntenseDebate is basically a set of tools that allows for enhanced commenting on your blog or website. Two features that caught my attention were Comment Threading and Reply-by-email.

Comment Threading was of particular interest to me because I find that being able to respond directly to a specific comment keeps the comments organized and relevant. Normally the way you respond directly to a comment without threading support is to prefix your reply with the persons name (e.g., “@raamdev That’s a great idea!”), but constantly searching the list of comments for the comment being replied to gets tiresome.

I don’t really have enough comment traffic on this blog to deal with the aforementioned problem on a regular basis, but I decided to install the IntenseDebate WordPress plugin to see how easily I could integrate it. I was impressed with how smoothly the process went. All my old comments (1,300+) were synced to IntenseDebate and there was nothing I needed to change on my theme templates — the entire commenting system was replaced with IntenseDebate’s commenting system, with threading support, a comment reputation point system, and all those other fancy features.

In the end, however, I decided to deactivate the plugin. I didn’t like that my comments were being loaded from an outside source, which both increased the average load time for each page and added yet another dependency on an external service. (In contrast, my Twitter sidebar uses Twitter Tools, which actually syncs tweets to the same database as WordPress and loads them from there. Dependency problems solved! To be fair though, the IntenseDebate plugin maintains a copy of all the comments in the WordPress database, just in case you decide to stop using it.) Customizing the look and feel of the comments also meant modifying CSS through my IntenseDebate account and right from the start I felt the need to customize and make the comment system less “busy” and self-advertising. There were no themes to choose from either. Ugh.

While doing all this thinking about the disadvantages of outsourcing my comments, I came across a post on Robert Nystorm’s blog where he decides to literally outsource all of his comments. Instead of having any form of commenting system, he simply provides a link to reddit, Digg, and StumbleUpon where he encourages people post their comments on his post. His rationale behind this is that people already use these other sites for commenting and those commenting systems are specifically tuned to handle comments. If you can’t beat’em, join’em.

But that’s extreme. Although I can sympathize with some of Robert’s frustration, I think a commenting system, even if only a simple one, is important. While some people may be familiar with reddit, Digg, and StumbleUpon, not everyone will use those sites regularly or, for that matter, want to go through the trouble of creating an account just to post a comment.

Back in September, I wrote about how excited I was to hear that Comment Threading was coming in WordPress 2.7. I hope the features and functionality of IntenseDebate are somehow integrated into WordPress down the road, instead of indefinitely relying on an external service to provide the same functionality.

I modified and applied the excellent Grid Focus WordPress theme by Derek Punsalan to my blog. His sense of style is very similar to my own and I think I have finally found a WordPress theme that I like enough to feel satisfied, at least for awhile.

There were a few things about the theme that didn’t work for me, so I made the following modifications:

1. I like a wide content column (at least 650px) so I removed the third column to make space.
2. Added Widget support so I could utilize the Twitter Tools and Get Recent Comments widgets
3. To support my use of Asides, I added some CSS styles to the stylesheet and modified index.php to check if the post belongs to the Asides category and style it accordingly
4. Shaded the left column to give it some definition and help it stand apart from the main content

You can download my modified version of the theme here. I’m still working out some of the kinks (like blockquotes not being styled to my liking) but I’ll update the theme zip file after I make any changes.

It looks like the WordPress commenting system will finally being overhauled in v2.7, including support for threaded comments!. If there is one thing I wished was done better in WP, it’s definitely the comment system. After all, second only to the actual blog content itself, comments and discussion are the most important aspect of a blog.

Intense Debate, the makers of software which adds commenting features like threading, reply by email, voting, reputation, and global profiles to WordPress and other blogging software, was just acquired by Automattic, the company behind WordPress. I think this goes to show how serious the improvements coming to the commenting system will be.

Matt Mullenweg, the founding developer of WordPress, has a post about the acquisition and talks about what it means for WordPress.

I’m getting sick of the iG:Syntax Hiliter bug that causes it to lose its configuration every time I do anything in the Plugins section. I also hate its proprietary syntax tags ([php] or [html]) because if someday the plugin author stops maintaining it and a newer version of WordPress breaks the plugin, I’m screwed (unless I wade through the code to fix it myself).

Here is what my code looks like whenever the plugin options are reset:

And here is what I want it to look like:

It makes so much more sense to use a plugin like Snippet Highlight which uses <pre> tags with CSS classes. The code for the plugin is dead simple, so maintaining it should be easy. Speaking of maintaining it, there’s a bug that causes Snippet Highlight to allow WordPress to parse HTML. I already notified the author, but if I have some free time this week I’m going to see if I can fix it.

Yup, I did it! I’ve upgraded this blog WordPress 2.5 and, as I’m sure you can see, I’ve changed my theme. It’s quite a change from the previous theme, but I like change and change is good. I spent quite a bit of time modifying it to my liking and there are still a few things to be done, such as adding the search bar (I couldn’t find a nice place to put it and I didn’t think it was really necessary to get the theme out there).

Another major addition that you’ll soon notice is my use of Asides. Sometimes I want to post something on my blog but I feel it’s not quite worthy enough for an entire post. Then if I do decide to post it, I’ll end up trying to make the post long enough to feel like an actual post, which usually just ends up degrading the quality of everything.

You can think of an aside as a little sticky note. I might post an aside saying where I’ve been, what I’m doing, or just some random thought I had. My Twitter account is hooked up to WordPress using the Twitter Tools plugin so I can even post asides via SMS from my phone.

An aside post won’t look like a normal post, but you can still comment on them like regular posts. An aside will look like this:

• With all the technology we have, we still can’t solve a problem as simple as traffic congestion. (0)

If you want to read more about asides, check out Matt’s post on them. He’s the one who started WordPress and his blog is where I first saw asides in use. He uses them a lot on his blog, so if you’re still confused as to what they are, check out his page.

Feel free to give me your thoughts on the new theme. It was a really hard decision to go with something so dramatically different from the “clean and white” look that I usually try to stick with. I realized that if I had to design something in the physical world, these are the colors I would use. My online blog should reflect that.

I spent this past weekend setting up a copy of this blog in my local development on my laptop. I wanted to see if upgrading from WP 2.3 to 2.5 would break my current theme and as I suspected, it did. What broke wasn’t obvious (category browsing I believe), but it was enough to make me decide to change my theme. There’s nothing wrong with the current theme, it just feels like it’s time for a change.

Setting up a local copy of my blog was really easy. I only needed to modify two WordPress settings and even then, that was only because I choose to use a different domain name locally. The basic process looked like this:

• Copied all of the WP files for my blog to my laptop
• Exported the live WP database and imported it into the local MySQL database using phpMyAdmin
• Created a database user to match the one on the live site (with the same password)
• Created a VirtualHost entry in my local httpd.conf:

<VirtualHost *:80>
   ServerAlias blog.raamdev.dev
   DocumentRoot "/Users/raam/workspace/blog.raamdev.com"
   ServerName www.blog.raamdev.dev
</VirtualHost>

• Added an entry to my local hosts file (/etc/hosts) so that blog.raamdev.dev would resolve to the local web server:

127.0.0.1      blog.raamdev.dev

• Opened the local phpMyAdmin and modified the following database entry, changing the URL to my local development address: wp_options -> siteurl = http://blog.raamdev.dev
• I was then able to login to my WP admin page at http://blog.raamdev.dev/wp-admin/ and modify the second setting: General Options -> Blog Address = http://blog.raamdev.dev

Now I could type in http://blog.raamdev.dev in my local web browser and use my blog on the local machine. This is great because it allows me to test themes and make changes without screwing up my blog.

I was trying to write a post about some code for generating HMAC signatures without PEAR or PHP5 and I discovered that I was unable to post anything that contained these three characters (without the space):

chr (

When I clicked “Save and Continue Editing”, I received a 404 error. It took me a good 30-40 minutes of blaming the iG:Syntax Hiliter plugin before I discovered it was actually WordPress. It breaks even if those three letters are enclosed in pre or code tags and I also confirmed this problem occurs when posting a comment.

I’m using WordPress 2.33 so I upgraded one of my other blogs to WordPress 2.5 just to see if this problem was gone (and to maintain my sanity) and was glad to see that it had been fixed*. The new WP looks very spiffy, except for the missing “Save and Continue Editing” button and the annoying lack of a preview feature (the Preview Frame plugin fixes this and I was glad to see it supports the latest WP).

I don’t like fixing what isn’t broken, so I’ve been holding off upgrading this blog to the latest WordPress. Besides, I’m pretty sure my customized theme will break with the new version and I simply don’t have the time to be fussing around with my theme. If I’m going to fuss around with it, I’d rather change it altogether. This site is due for a new look anyway.

*UPDATE: I don’t know if I’m losing my mind or what, but after upgrading this blog to WP 2.5 I’m having the same exact problem with creating a post containing those four characters!

UPDATE UPDATE: I did some Googling and discovered that the Apache mod_security might be doing something because apparently the chr () function is commonly used in exploits. This blog post explains 10 ways to secure WordPress and if you search for chr you’ll see that it’s part of the SecFilterSelective THE_REQUEST line.

CONFIRMED: I tried disabling mod_security for my entire account by adding SecFilterEngine Off to a .htaccess file in my root web path. I was then able to post those four characters without any problem. After creating a post containing chr(), I removed the .htaccess file to enable mod_security and as expected the post still displayed fine.

So, since this is only a problem when submitting a post, and since permanently disabling mod_security isn’t a great idea, I’ll just temporarily disable it in those rare situations when I need to create a post containing chr().

I have a lot of big ideas in my head for different types of sites that I think the masses would find very useful. What I’ve been struggling with over the past few months is deciding where to start with these sites. There is so much involved in making a site successful and even more involved in running a successful site.

What I really wanted was some type of platform that allowed me to turn my idea into a reality without worrying about basic things like the underlying user account database structure or basic functions like creating a blog post.

A few weeks ago I was pleasantly surprised to learn about WordPress MU, which basically allows you to run hundreds of thousands of blogs using a single installation of WordPress (it runs wordpress.com). And then it got even better.

Today I came across BuddyPress, which takes WordPress MU one step further by developing a collection of plugins that turn your WordPress MU installation into a social networking platform (see John’s post about the differences between the two). BuddyPress is just getting started, but I already see the huge potential behind it.

I can see the Internet eventually being full of little social networks covering every niche imaginable — much like the huge mess of web pages and forums on the Internet are today. The best way to find what you’re looking for on the Internet now is to either know of a forum or website, or to search Google and hope you find what you’re looking for. Imagine being able to join or browse an area of the Internet that has been designed, authored, and created by the very people who have the same interests as yourself.

Maybe that isn’t the final goal of BuddyPress, but I can definitely see how WordPress MU combined with the BuddyPress plugins will make bringing my ideas to life that much easier. WordPress MU + BuddyPress basically solve 75% of the problems for many of the sites I have in mind, so besides making me feel comfortable about scale, they will definitely save me time.

You may have noticed a lot of the pictures I’ve been posting lately have a little border around them. I started doing this after I saw Raf’s site and realized how easy it is to do with a CSS class.

One of the big annoyances I used to deal with when posting images was that I would always need to add border="0" to the <img> tag to prevent the ugly blue borders that appear when the image is surrounded with a link tag. Although it’s possible, I didn’t even think to disable all image borders in CSS. By why only disable them when we can make pretty borders too?

Here is the CSS I use (place it in your style.css file if you use one):

.photo img, .photo a img {
    border:1px solid #CCCCCC !important;
    padding:5px;
    margin-bottom: 10px;
}

And here is how I use it when I’m writing a post in WordPress (keep in mind that I don’t use the visual editor):

<div class="photo">
    <a href="http://blog.raamdev.com">
        <img src="http://images.raamdev.com/DSC_1112_640.JPG">
    </a>
</div>

And here is an example of the output:

The CSS border adds a touch of style to the image and without it the image border would appear sharp and out of place. Since I added .photo a img to the class definition, even images that are linked to something will appear with the nice border.

There are already buttons for creating links and adding images in the WordPress editor, but adding the <div> tags around the image does take a bit of time. Eventually I’d like to write a quick plugin for WordPress that adds a little photo button to the editor bar to automatically add the DIV tag with the proper CSS class already specified.

When creating tables inside a Wordpress post, using uppercase TABLE and/or TR tags causes additional whitespace to appear above the table. I say and/or TR tags because uppercase TABLE tags alone don’t seem to create additional whitespace, however uppercase TR tags do. If you combine the use of uppercase TABLE and TR tags together, they create even more whitespace!

First, lets see what normal output looks like:

This is a simple sentence used to demonstrate an odd spacing effect when uppercase TABLE and TR tags are used in a table.

<table cellspacing="10" cellpadding="0" border="0">
<tr>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
</tr>
</table>

Wordpress output:

And now, if we copy the exact same content and make the TABLE and TR tags uppercase, look what happens:

This is a simple sentence used to demonstrate an odd spacing effect when uppercase TABLE and TR tags are used in a table.

<TABLE cellspacing="10" cellpadding="0" border="0">
<TR>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
<td align="center"><img src="/wp-content/uploads/2007/12/br.jpg" border="0"></td>
</TR>
</TABLE>

Wordpress output:

I’m running the latest version of Wordpress (v2.3.1 as of this post) and I have confirmed this oddity appears on multiple platforms (Mac OS X 10.4.11, Windows XP SP2) with multiple browsers (Firefox 2.0.0.11 on Windows and OS X, Internet Explorer 6.0.29 and Opera 9.22 on Windows, and Safari 3.0.4 on OS X).

Upon closer inspection of the actual output produced by Wordpress in my browser (using view source), I discover the problem:

Browser output of the lowercase example:

<p>This is a simple sentence used to demonstrate an odd spacing effect when uppercase TABLE and TR tags are used in a table.</p>
<table cellspacing="10" cellpadding="0" border="0">
<tr>

Browser output of the uppercase example:

<p>This is a simple sentence used to demonstrate an odd spacing effect when uppercase TABLE and TR tags are used in a table.</p>
<p><TABLE cellspacing="10" cellpadding="0" border="0"><br />
<TR></p>

It appears that Wordpress is looking for the <table> and <tr> tags and when it finds them it doesn’t automatically add <br /> and <p> tags around them like it does with the rest of your post. (I don’t use the visual editor, so I’m able to easily add hand-written HTML directly to my post.) However, the search for <table> and <tr> must be case sensitive which causes problems if your tags are anything but lowercase.

I would normally report this as a bug to Wordpress, but I’m sure the reply will be that all XHTML must be lowercase and so the problem is not relevant. I say that’s bad backwards compatibility.

I generally like to wait awhile before upgrading things, especially since most bugs (serious or otherwise) come out after the new version has been released. A little over a month had passed, so I decided it was time to upgrade my WordPress installation to version 2.3.

How can we make upgrading as quick, painless, and safe as possible?

I found a really nice way of upgrading WordPress: The Automatic Upgrade plugin. It basically automates the process of backing up your existing WordPress installation (including the database), downloading the latest version of WordPress, and installing it. I don’t like the idea of putting my entire blog in the hands of a plugin and I would never have even considered using it if there wasn’t a backup feature included. I was happy to see a zip file of all my WordPress files, as well as a backup of my entire database, delivered to me through the browser before any upgrading began.

The upgrade to WordPress 2.3 went smoothly with Automatic Upgrade. In the future, it would be really nice to see something like the Automatic Upgrade plugin included directly in WordPress, since upgrading to a newer version is always going to be a necessary evil. The WordPress developers seem to have started down this path by including an Upgrade Notification feature in this version (which I discovered while writing this post):

What happened to inline preview!?

After upgrading, I immediately noticed something very annoying with post Preview. The inline preview box at the bottom of the post editing window was gone! Instead, there was Preview link next to the Title field which opens an entirely new window to preview the post:

The ability to preview your post from the edit page after clicking ‘Save and Continue Editing’ seems to make a lot more sense to me (at least from a work flow perspective) than saving the post, clicking preview to open a new window, previewing the post, and then closing the window.

I read somewhere on the WordPress forum that the decision to remove inline preview was based upon speed and performance concerns. However, in the 500+ posts I’ve created prior to WordPress 2.3 I have not once experienced a performance issue with the inline preview. If the developers wanted to remove inline preview, they should have at least created an option to enable/disable it and simply made the default disabled.

I found a really nice plugin that fixes the missing inline preview problem by adding a the inline preview back onto the edit page. It’s called Preview Frame and is created by Rob Miller.

Ah, sweet familiarity! It’s so nice being able to preview my post without leaving the editing window! Hopefully a future version of WordPress will bring back the option to preview inline, but until then, thanks Rob!

Drafts: My start-but-not-finish habit is finally (at least somewhat) hidden!

If you’re like me, you probably have dozens of drafts saved up for a rainy day. Perhaps there was something interesting you found and wanted to blog about but simply didn’t have the time to write a fully polished post, so you jotted down some stuff and saved it as a draft. Once in awhile you’ll finish a draft, but otherwise the pool continues to grow.

Prior to version 2.3, when you clicked on “Write” you would be presented with a big blob of your drafts, probably about 15 - 20 of them, which would take up about 1/3 your screen. Of course, this was very unnecessary. Version 2.3 fixes this in two ways. First, the list of drafts has been shortened to three:

Secondly, clicking the “more” link brings you to the Manage Posts section where you’re now able to filter posts by their status, sorted by Modified Date (see the timestamp bug below!):

Tagging and Tag Clouds: Should I follow the crowd?

Another big addition to WordPress 2.3 is the support for tags. Some people believe that tags are a better solution to categories (the Web 2.0 solution). I’m still trying to decide if I agree with that statement, since I really like the organized method of current category design.

The idea behind tagging is that you “tag” each post you write with multiple words, similar to selecting a category or multiple categories for the post. Then, using the new wp_tag_cloud() template tag available in WordPress 2.3, you can display a tag cloud:

A tag cloud is basically a way of visually displaying the most common tags and allowing the user to click on any tag to bring them to a list of posts containing that tag. If you tag a lot of posts ‘Publication’ and a few posts ‘Security’, then the security tag will appear smaller in the cloud (as in the example above). There is an alternate way to implement a tag cloud without using the tags feature by using the existing categories instead. This blog explains in detail how it can be done.

Until I find a good reason to start tagging my posts, I will continue using categories and leave the Tags field empty.

Everything has bugs!

I’ve found at least two bugs so far. I don’t know if they’ve been fixed with 2.3.1, since I haven’t installed that yet. The first is less of a bug and more of a usability issue, but both are related to the post timestamp.

When you start writing a new post, clicking Save does not save a timestamp. This means it won’t show up at the top of your drafts list! If you click “Save and Continue Editing” or “Publish”, the current timestamp is written and everything works as expected — or does it?

I had another issue with timestamp. After publishing a post, I decided I wanted it to show up tomorrow instead of a few hours from now. So I modified the timestamp and re-published the post, fully expecting it wouldn’t show up until tomorrow. However it still showed up when the original timestamp date passed, even though the current timestamp showed a later date!

As with any type of bug, replication is a requirement. I performed a couple of tests to see if I could duplicate the second timestamp issue, but I was unable to. Raf suggested a possible plugin conflict, but I disabled all plugins and still had the same problem. I discovered the second timestamp bug before the first and now I’m wondering if the two are related.

Obligatory Summary

WordPress is definitely morphing into a better piece of software. I like the new features, though I’m a bit surprised at the remove of inline preview and the obvious timestamp bug. I’ve been using WordPress since the first 2.0 version and I really like the way things are designed. In determining what to use as a CMS for the website of my web hosting company, I’ve decided WordPress is an ideal candidate due to the ease of customization and the power provided through the templates.

After creating the Comment History page, I realized the Recent Comments Plugin was listing the comments in order from newer-to-older, instead of older-to-newer (which is how the comments on my post pages were ordered). I thought that I should probably change the ordering of the comments on my post pages to match the Comment History ordering.

The solution, I discovered, was rather simple. Just open the comments.php file in your theme’s home directory, find this line:

<?php foreach ($comments as $comment) : ?>

and immediately above it add this:

<?php $comments = array_reverse($comments, true); ?>

Save the file and your comments will be ordered from newer-to-older. However, after making the change I realized my original older-to-newer ordering made more sense. Why? Because when someone is reading a post, the first comment they read might not make any sense unless they have read a previous comment.

So to make reading the post page more user-friendly, comments should be ordered from older-to-newer (the WordPress default). For a Comment History page however, ordering comments from newer-to-older makes more sense because the visitor is probably viewing the Comment History page to check for the most recent comments on a post they have been following.