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
and
tags and when it finds them it doesn’t automatically add
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
and
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.
My Dad and I have been going back and forth quite a bit in the comments on a recent post I wrote about Consumption. This filled up the Recent Comments list on the sidebar rather quickly and I wasn’t able to see other recent comments. I realized a comment history or archive page, similar to my post archive page, would be very useful.
After looking around a bit, I found a really nice plugin by Krischan Jodies called Get Recent Comments. It has a ton of features and lots of configuration options. It has been updated as recently as last month and even supports the new widgets feature of WordPress 2.3 (it also works with older versions of WordPress as far back as 1.5).
By default, the instructions included with the plugin explain how to add recent comments to your sidebar. They don’t, however, mention anything about creating a comment history page. In the instructions there is a snippet of PHP code which you are supposed to use in the sidebar.php file of your WordPress template. I thought great, I simply need to create a new page in WordPress and add that snippet of code to the page using the runPHP plugin to execute the PHP on that page. This worked, partially. At the top of my comment history was this error:
Parse error: syntax error, unexpected $end in /home/raamdev/public_html/blog/wp-content/plugins/runPHP/runPHP.php(410) : eval()’d code on line 1
I thought perhaps it was because my runPHP plugin was outdated, so I upgraded it to the latest version (currently v3.2.1). I still received the error, so I decided to play around with the snippet of PHP code provided by the Get Recent Comments plugin. I was able to modify it slightly to get rid of the error as well as output some additional text. Here is the snippet of code I use to create my new Comment History page:
<?php
if (function_exists('get_recent_comments')) {
echo "(Showing 500 most recent comments.)";
echo "<li><ul>". get_recent_comments() ."</ul></li>";
}
?>
In the plugin options, I configured the plugin to group recent comments by post. This created a very readable Comment History page. After adding the ID of the new page to the exclude list in my header.php file to prevent the page from showing in the header (wp_list_pages('exclude=704&title_li=' )), I added a ‘View comment history’ link to the bottom of the Recent Comments list on the sidebar.
The Get Recent Comments plugin is really powerful and I’m a bit surprised that the plugin doesn’t include basic instructions about how to create a comment history page. If you receive a decent amount of feedback from your visitors (in the form of comments), this is a great way to see all that feedback on a single page. If you have Trackback’s and Pings enabled, this plugin can even show those.
SecureImage is nice, but the problem is that SecureImage doesn’t work well with wp-cache, the cache plugin I use to insure a speedy experience for my visitors. So only a few minutes after installing SecureImage, I found another solution: reCAPTCHA.
The idea behind reCAPTCHA is very cool. It works by asking you to read two words, one which the computer generated and one that is part of a scanned page from a book, a word that the computer was not able to decipher. If you can understand the computer generated word, chances are that you’ll also be able to decipher the scanned word. This helps digitize books! If you want to learn more about reCAPTCHA, I suggest you visit their site and read the “What is reCAPTCHA?” page.
I had to do a little tweaking to get it positioned properly with my custom WordPress theme, but that wasn’t too bad. I’m really liking reCAPTCHA. Not only does it work with wp-cache, but it also fixes the annoying problem where your comment data would be lost if you enter the wrong information in the captcha. Of course, the captcha will be used by you, my visitors, more than anyone else, so please leave me your comments!
A few months ago I installed the Challenge plugin, which presents a math question for anyone wanting to post a comment. It’s been working great and I have not received a single spam comment… until this morning. I woke up and checked my Blackberry for new email: 49 new email messages. They were all comment notifications. Apparently a spam bot managed to get around the Challenge plugin and posted 49 spam comments throughout my blog!
After deleting the spam, I decided to install the same plugin I’ve installed on a couple of other WordPress blogs, SecureImage (the developers site is down and that is the best URL I can find for SecureImage). It’s a simple captcha plugin that generates an image containing a string of letters. Other captcha plugins required GDLib, which I couldn’t seem to find on my web server (or at least didn’t bother spending much time looking for it). SecureImage requires ImageMagick, which is readily available (read: default /usr/bin/convert path worked fine). After installing a TrueTypeFont (FreeSansBold.ttf) I was up and running.
Well, I took the plunge and upgraded my WordPress installation from 2.0.1 to version 2.1.2. I few weeks ago was going to do the upgrade to version 2.1.1, but I decided to wait a bit longer. Damn good thing I waited — only four days later it was discovered that someone cracked the 2.1.1 WordPress files and allowed dangerous code to be executed.
Now it’s been a few weeks since the updated version was released, so I feel comfortable about upgrading. During the upgrade process I forgot the step to disable all the plugins. When I copied the new files to my web server, my whole blog installation was screwed up. So, praying to god that the backups I made would work, I deleted everything and restored the backups.
Long story short, I eventually got everything working with the latest version of WordPress. I had to install a new plugin called RunPHP, so that I could get the SRG Clean Archives plugin working again. The entire blog feels a bit more responsive, which is always good.
Please let me know if you notice anything broken or anything that doesn’t look right!
I’m sick of scanning through the list of comments caught by Akismet to see if there are any false-positives — I have had a few false-positives, namely from DJT.
So I’ve deactivated Akismet and installed Challenge 1.1. It works by asking the commenter a question. If the correct answer is provided, the comment is posted. I can customize Challenge to ask any question, however I’m currently using a simple, random math problem. Hopefully this plugin will save me from scanning through hundreds of spam comment posts.
One thing I would like to fix, though I don’t think it will be an easy fix, is to save the contents of the users comment in case he enters the wrong answer. Right now, if you enter the wrong answer and click Post, it gives you a message saying you entered the wrong answer. However, when you press the Back button in your browser, you have to retype your comment. So get the answer right the first time!
Go ahead and leave a comment to try out the new system.
EDIT: After deactivating Akismet, I started getting a lot of TrackBack spam. Since Akismet doesn’t have any option to only filter TrackBack’s, I’ve decided to disable link notifications altogether.
As you can see, I am now using a modified version of the Wordpress Simplr theme by Scott. It took me a good 4 1/2 hours to modify and to make sure everything was working the way I wanted it to.
Changes:
- The sidebar has been moved from the bottom to the right.
- Single post pages are shown without any sidebar to make room for actual post content when you’re reading the post.
- Each of the pages (About, Contact, Archives, etc) also do not show the sidebar.
- From the main page, when you click one of the categories from the sidebar to browse the posts in that category, you will be provided with a sidebar to further navigate via categories while you’re reading posts.
- The theme is designed to stretch with the browser window, so it should work on many different resolutions (even 640×480, though that wouldn’t be very usable)
- Moved the title of the blog into the top left corner, on the same line as the page links
- Moved the tagline (my quote) to the right corner, under the page links
Important Installation Notes:
- You can no longer use the Simplr Layout Width or Sidebar Layout options.
- You MUST change Layout Width to 95% once you have activated the theme.
- I recommend you set the Base Font Size to 75%
- If you change the Base Font Size option to something greater than 75%, you may need to increase the following in style.css:
div.postcontainer { margin-right: 330px; }
- The rest of the Simplr options should work.
Screenshot:
Download: simplrraam.zip (379kb)
Keep in mind that I did this in a hurry, so many of my changes to the theme files are not documented. I also plugged in extra CSS styles where I needed to get things working. Please feel free to post comments, fixes, or suggestions to this theme below.
