james mckay dot net

Occasionally people report problems with Comment Timeout breaking the layout on their WordPress themes when comments are closed.

In these cases it is almost certainly the theme that is at fault rather than the plugin itself. It seems that some theme designers do not test their themes properly on posts where comments are closed.

You can verify that this is the case by manually turning off comments on an offending post:

1. Disable Comment Timeout.
2. Edit one of your old posts, uncheck the box under “Comments & Pings” that says “Allow Comments” and click save.
3. View the post you just edited in your browser again.

If the problem persists, you should contact your theme’s designer as it is the theme that is at fault.

If you are a theme designer and you receive a report of this fault, please check that you have balanced your <div> tags and <?php if (...) ?> statements in your theme. For example, this will be incorrect:

<div class="comments">
<?php if ('open' == $post->comment_status) : ?>
<div class="comments-inner">
<?php render_comments(); ?>
</div>
<?php else: ?>
<div class="no-comments">Sorry, comments are closed.</div>
</div>
<?php endif; ?>

This kind of mistake is very easy to miss if you do not indent your code correctly, as in the above sample. For reasons that completely befuddle me, some developers and web designers don’t indent their code at all — in fact, this was the case the first time I encountered this error, which is why I mention it here. Adding indentation shows it up clearly — lines 8 and 9 do not match lines 1 and 2 correctly and should be swapped:

<div class="comments">
  <?php if ('open' == $post->comment_status) : ?>
    <div class="comments-inner">
      <?php render_comments(); ?>
    </div>
  <?php else: ?>
    <div class="no-comments">Sorry, comments are closed.</div>
  </div>
<?php endif; ?>

Comments closed »

Posted at 23:51 on 28 July 2008.
Tagged: best practices, Comment Timeout, WordPress

It turns out that the WordPress Syntax Highlighter plugin that I mentioned a couple of weeks ago has some rather nasty artifacts. One in particular is that when you try to display HTML — or any code containing HTML — WordPress tries to “fix” this by adding extra tags that you may not want to make it valid XHTML, and it b0rks your nice tidily formatted source code in the process. Another problem was that it converted emoticons to images — a big no-no when you’re writing source code.

Yeah, maybe I should have been using the rich text editor, but that caused other problems. Rich text editors generally wreak havoc with source code, so it’s best to turn them off when you’re doing anything of that nature.

This was the reason why I stuck with Code Auto Escape for so long. Entering source code is awkward, to be sure, but nevertheless the plugin is pretty robust and does a good job. I did try a few proper syntax highlighter plugins way back, but I didn’t find any of them all that satisfactory. However, Code Auto Escape is a plugin that Just Works™.

It also turns out that Alex Gorbatchev’s Syntax Highlighter JavaScript code allows you to set various options for your code blocks, such as hiding the toolbar or the line numbers, or starting numbering at a number other than 1. The WordPress Syntax Highlighter plugin does not expose these options.

Sooo… why not combine the two approaches?

Over the Bank Holiday I’ve spent a few hours writing a new plugin that does precisely that. I took Code Auto Escape as the baseline, and added a whole bunch of extra code to plug in the syntax highlighter scripts.

Interested? Get Coder 1.0 alpha 1 here.

Comments closed (2) »

Posted at 13:41 on 5 May 2008.
Tagged: JavaScript, syntax highlighter, WordPress

I’ve been thinking a bit recently that many other programmers’ blogs do a much better job of handling code snippets than mine does. Since time immemorial I’ve been using a very simple plugin called Code Auto Escape, which merely allows you to type code verbatim into your posts without having to go through all the rigmarole of HTML encoding them. I’ve never looked for anything fancier mainly because I never got round to it.

However, if you are geeky enough to post code on your blog in the first place, you need to do it properly, and that means syntax highlighting. Fortunately, it’s a simple case of finding and installing the right WordPress plugin. So, this morning, I finally got round to doing a bit of googling for one.

There are several such plugins to choose from. Most of them are based on GeSHi, a popular and very well supported PHP library which offers syntax highlighting for almost every programming language you can think of. It runs on the server, injecting extra markup into your code to achieve the desired effect.

In the end I settled for Syntax Highlighter. It takes a different approach, using JavaScript in your browser to render the highlighting and add a little toolbar at the top of each snippet with options such as copying it to the clipboard:

var highlightColour = "#ffff00";
var normalColour = "#ffffff";

$(document).ready(function() {
  $("#my-table tr").hover(
    function() {
      $(this).css("background-color", highlightColour);
    },
    function() {
      $(this).css("background-color", normalColour);
    }
  );
});

Personally I think this is a better, cleaner approach: it delegates the heavy lifting involved from the server to your browser, and reduces the size of the markup in your posts. It is also semantically cleaner: while the output from GeSHi is valid XHTML strict, it does jumble up content and presentation a bit, which is the reason why table-based layouts, the <font> tag and inline CSS tend to be frowned upon these days.

Unfortunately, none of these plugins address the biggest problem with writing code on your blog: that it is so fiddly and awkward with a rich text editor. Both Windows Live Writer and TinyMCE in WordPress take a perverse delight in messing up your indentation, your line breaks, and sometimes even with what gets HTML encoded and what doesn’t.

Comments closed »

Posted at 10:23 on 19 April 2008.
Tagged: syntax highlighter, WordPress

Astute readers of my blog will note that I turned off my Comment Timeout plugin at the start of this year. I had begun to suspect that its effect on spam was minimal, while at the same time there were still some posts that, according to Google Analytics, attract a bit of attention — in particular, my posts about SharePoint seem to feature rather prominently in searches by people who find the subject even more confusing than I do.

Sooo… now you can even leave comments on my very first blog entry if you are that way inclined.

In the end, I found that turning it off did not result in a noticeable increase in spam comments. I am now using only three plugins to manage spam on my blog and together they put in a stellar performance. Akismet and Bad Behavior stop almost everything dead in its tracks, and beyond that, a blanket rejection of comments that contain BBCode or more than two hyperlinks keeps your spam queue short, makes it easy to check for false positives, and reduces the load that it places on Akismet and your bandwidth consumption. As far as I can tell, 80-90% of spam comments contain either BBCode, or three or more hyperlinks.

However, this raises a question: what is the future of Comment Timeout?

Unfortunately, I have had quite a lot on at work recently and I have other projects that I want to move on to that I simply haven’t had time for so far, so since I am no longer using Comment Timeout myself, maintaining it further now has a very low priority.

There are some things that could still be done on it, such as localisation, but as far as I can tell, it is stable, it works with any version of WordPress since 2.0, and pretty much all the bugs that have been brought to my attention have been ironed out. I haven’t tested it thoroughly against WordPress 2.5, but as far as I can tell it should work properly.

If anyone would like to develop it further, I have no objections. It’s dual licensed under both the GPL and the MIT/X11 licence, so you don’t even need to ask for permission, though it would obviously be nice to get a heads-up.

Comments closed (1) »

Posted at 13:06 on 5 April 2008.
Tagged: Comment Timeout, spam, WordPress

Automattic releases the WordPress Stats 1.1 plugin, and the next day, it is found to have a SQL injection vulnerability.

Fortunately, the vulnerability has been fixed, but it is this kind of bug that I was talking about earlier today. With a solid, well thought out database access architecture using parametrised queries, SQL injection vulnerabilities like this could be all but eliminated.

If the WordPress guys don’t change their tune about GoPHP5 sometime soon and come up with a firm action plan to rework their application architecture to use PDO and nail these things on the head, I’m looking for another blog engine.

(Updated: added link to the fix)

Comments closed »

Posted at 20:03 on 27 July 2007.
Tagged: best practices, security, SQL injection, WordPress

I’ve been thinking a bit more about what to do with my blog. More from a technical perspective than anything else, mind you — I have been wondering a bit whether WordPress is the best solution to use for it, and if not, what I should be using instead.

WordPress is very popular and very fully featured, but it has a poor reputation when it comes to security. Stefan Esser, of “Month of PHP Bugs” fame, is particularly critical — a week or so back he gave an interview on BlogSecurity.net about the problems with WordPress, citing architectural problems that make it difficult to write secure code.

I must admit that while there is a lot that WordPress does very well — it is a very full featured application, supported by a lively community — I find its codebase pretty tacky. Some of it isn’t too bad, but the admin section in particular is a right unholy mess, with HTML, PHP code and SQL statements bundled together haphazardly in a monstrous plate of gone wrong spaghetti bolognese on the loo.

Matt Mullenweg is pretty defensive about WordPress security, however. In a blog entry about a month ago, he made the point that (a) all software has bugs and security vulnerabilities, which is true, and (b) that the WordPress developers do a great job of tracking down and fixing bugs and security holes before releasing a new version, which is also true. However, he did not address the point that the overall architecture of WordPress makes the process of tracking down and eliminating bugs — and keeping out whole classes of certain bugs in the first place — unnecessarily difficult.

The fact that Mullenweg has stated his opposition to the long overdue GoPHP5 initiative and the end of life of PHP 4 is also far from reassuring. PHP 4 may still be amazingly popular, but it has some serious shortcomings as a language which make it much more difficult to write robust, secure and easily maintainable code — shortcomings which were addressed in version 5. It has no support for parametrised queries, for instance, forcing developers to adopt the dangerously insecure practice of concatenating SQL code and user input to construct database queries. In an attempt to protect against SQL injection attacks, PHP offers magic quotes — an ugly, naive, broken and widely criticised hack that causes more problems than it solves and doesn’t always work.

What makes this more serious is that these days, writing WordPress plugins and themes is for many people the introduction to the world of software development, and while it does need to be kept simple so that newbies can learn and participate to some extent, it also needs to show the way in terms of good programming practices and robust code, and when you are using a language that limits your ability to do so, it is not good.

So how could WordPress improve in this respect?

First of all, the WordPress core team needs to take PHP 5.2 seriously and sign up to GoPHP5. The new features of PHP 5 are not merely luxuries; they do make it much easier to adopt good programming practices and write robust, easily maintainable code. It would not make it more secure overnight, but it would make it considerably easier to evolve it towards a better, more secure, more robust and more easily maintainable architecture.

Secondly, it needs as complete a suite of unit tests and integration tests as possible. I know that there are moves afoot to add unit testing to some particularly error-prone parts of the application, but the automated tests need to go beyond this and cover as much of the code as is possible. These would not only increase confidence in the code quality dramatically, they would also make it a lot easier to track down and fix bugs that creep in during development. Automated unit and integration testing seems much less common in PHP open source projects than in their counterparts in .NET or Java, and if WordPress takes a solid lead in this respect, it will be a smart move and bring them kudos among serious developers.

This would, however, necessitate some fairly fundamental architectural changes. It is much more difficult to write meaningful unit tests for an application with a monolithic structure where HTML, PHP and SQL code are all wrapped into one than for an application that adopts a three-tier or Model-View-Controller approach. This does not have to be done all at once, and it does not have to become fully object oriented, but WordPress does need to move towards a more structured approach with a better separation of concerns between database access, network communications (such as e-mail and pings), business logic and the UI.

Finally, the upgrade process needs to be made as simple as possible for the end user. I wrote a while back about how we have moved to a scripted, single step process for one of our major projects, which makes the process of applying changes a doddle. WordPress needs to do something similar. It can be, and should be, as simple as pressing a button on your dashboard. Novice users certainly should not need to bother with making backups, FTPing some parts of the application and not others, and so on — it is an error-prone process that can be so daunting for inexperienced users that there are still a lot of blogs out there running WordPress 1.5, wide open to attack.

Comments closed »

Posted at 12:30 on 27 July 2007.
Tagged: best practices, security, WordPress

The first alpha versions of my new WordPress comment plugins are now available for download.

Comment Timeout 2.0 closes comments on posts on your blog a certain time after they are posted. It has been rebuilt from the ground up to incorporate some new features:

• You can now override the default settings to allow certain posts to have the discussion kept open for a shorter or longer time, or even indefinitely.
• You can define a “popularity level” above which the discussion can be kept open for an even longer period of time if you so desire.
• You can have comments on older posts sent to the moderation queue instead of closing the discussion altogether.
• The comment form now indicates when the discussion for a particular post will close.

Some features were added to version 1.3 but have now been spun off into two separate plugins:

Three Strikes and You’re Out examines your Bad Behavior logs and your spam queue and closes comments across the board on your blog when you are visited from any IP addresses that have been repeatedly misbehaving (the default settings are three times in a week). It also defines a couple of hooks and adds a new logging table to the database, so other plugins can register naughty events (e.g. failed captcha tests) or override the counting mechanism (e.g. to implement whitelists or blacklists).

Link Limits rejects comments which contain BBCode or more than two normal hyperlinks. I’ve found that this blocks approximately 80% of spam, yet genuine comments exceeding these limits are almost non-existent. It informs your commenters that this restriction is in place. It also logs any violations to Three Strikes And You’re Out, but it works perfectly well if you do not have Three Strikes And You’re Out installed.

I’ve marked them all as “alpha 1″ status, which means use at your own risk, though I am dogfooding them on my own blog. If you have any problems with them, I’ve written a post on how to report problems with WordPress plugins — please read it before giving me a shout, though I do welcome feedback and suggestions of course.

Starting with these plugins, I have changed the licensing terms. Whereas the old versions were GPL, these ones are available under the MIT X11 licence. It is GPL compatible but doesn’t have the “copyleft” element. This means that if you wanted to, you could adapt it for use with another, non-GPL, CMS or blog program.

Comments closed (5) »

Posted at 23:28 on 3 June 2007.
Tagged: Comment Timeout, Link Limits, Three Strikes and You're Out, WordPress

Since I’ve released a WordPress plugin that’s been attracting a fair amount of attention, it’s inevitably had its share of users who have reported some problem or other. Most people find that everything proceeds fairly smoothly, but inevitably there will be those who, for one reason or another, simply can’t get it up and running. So I thought I’d put down some tips on what to do if you encounter a problem, and how best to go about reporting it.

This advice is intended to be fairly general, and not specific to any of my own plugins, and though different developers may have slightly different expectations, it should come in useful irrespective of which plugin you are using and who wrote it.

1. Make sure that you’ve read and understood the instructions.

This may sound obvious, but amazingly, some people don’t. Check that your version of WordPress is supported (most newer plugins these days require version 2.0 or later, and some even require version 2.1). Check that you’ve understood correctly what the plugin does, what all the configuration options mean, and whether or not you’ve overlooked something. There may also be some known issues or bugs with the plugin, so you should check to see if you’re up against one of those. It also helps to read the comments left by other users: they may be able to shed some light on the problem. A search of the WordPress support forums may also help.

You don’t have to trawl the whole Internet or even the whole site, but if you at least show that you’ve looked in the most obvious places, it helps a lot. If there’s anything you don’t understand, by all means say so, but indicate exactly what it is that you don’t understand, rather than simply saying “I don’t understand the instructions.”

2. Check to see if there’s a conflict with another plugin.

There are thousands of WordPress plugins out there, and it is simply not possible to test our creations against all of them. Consequently, there is always the possibility that your newly installed plugin could be conflicting with one of the others that you have been using.

Checking to see if this is the case is fairly straightforward, though it’s a good idea to back up your WordPress database before you do so in case anything goes wrong. Disable all your other plugins and switch to the WordPress default theme. This may or may not fix the problem. If it does, switch your theme back and then re-enable the other plugins one at a time until the problem reasserts itself. When you do this, the conflict is between your new plugin and the last one that you re-activated.

You should let us know which other plugin or theme, and which version, is causing the problem. Tell us where to get it too, and make sure that the link to its home page still works. There is little or no incentive to ensure compatibility with a plugin or theme that has vanished off the face of the web and is no longer being maintained.

3. Check to see if the problem occurs on other computers in other places.

Some plugins have features that depend on your IP address, which may be different depending on whether you are accessing the Internet at work or at home. Some have Javascript that may not have been tested thoroughly on all browsers. You may be accessing the Internet through a proxy server which could be causing unforeseen problems.

If you can, check to see whether or not you get the same problem on a different browser on another computer. You don’t have to check every permutation of plugins and so on, but if the problem occurs in one place and not another one, we’d be interested to know.

4. Make your feedback clear and specific.

Here is an example of a bad question:

I tried your plugin. I can not get it to work. What is the problem?

This haiku is worse than useless because it tells me nothing, yet I have to spend time reading it and deciding whether to respond to it or report it as spam to Akismet. If you’re lucky, you’ll get a response along the lines of: “I haven’t a clue. I am not a mind reader. Please give more details.” If you’re not, you’ll just be ignored and your comment will be flagged as spam.

By contrast, here is an example of a good bug report:

I’ve installed version 3.14159 of the Happy Pi Day plugin and I’ve found that my users are getting a Blue Screen Of Death when they visit my website on the fourteenth of March if they’re using Internet Explorer on Windows Vista. I’m running WordPress 2.1.3 on PHP 4.4.4 and MySQL 4.1. I’ve tried disabling all my other plugins and switching to the WordPress default theme, but the problem still persists. There’s an option on the plugin page that says “Einstein’s Birthday Mode” but I didn’t understand from the documentation what that is supposed to do, so I haven’t tried changing that.

You can see the problematic page at http://www.example.com/happy-pi-day/.

This is much better because it gives us a lot of useful information in clear, unambiguous terms.

At an absolute minimum, you should state:

• what you expected to happen;
• exactly what actually happened;
• the exact text of any error messages;
• the steps needed to reproduce the error;
• which versions of WordPress, PHP, MySQL and the offending plugin you are using.

You should also give as much additional information as you have been able to determine in your troubleshooting steps above:

• which browsers and operating systems are affected on the client side;
• whether you have found a conflict with any other plugins or your theme;
• anything about the documentation that you didn’t understand;
• where appropriate, the URL of a blog or post where the error can be seen in action.

Remember that you’re aiming for clarity. Write in plain English, in whole sentences. Read your report back to yourself to make sure that it’s clear and unambiguous. Don’t post guesswork as to what you think the problem might be: report the symptoms of the problem — i.e. exactly what you did, exactly what happened, and exactly how reality deviated from your expectations.

Many plugin authors — myself included — work on their offerings for free. This means that the amount of time that we can spend supporting them is strictly limited, and unless you are one of our paying clients, we have to triage bug fixes and support issues that come our way, sometimes pretty aggressively. Inevitably, it’s the queries that provide us with the most helpful information about the problem that are likely to get the most (and quickest) attention.

Comments closed »

Posted at 15:24 on 28 April 2007.
Tagged: contact, WordPress

What does this guy think he’s playing at? He thinks WordPress — the world’s most popular open source blogging engine — is not notable enough for Wikipedia.

Okay, let’s come up with a few other articles that, by the same standard, are not notable enough for Wikipedia. How about, er, this one, this one, this one, or this one?

Comments closed »

Posted at 22:58 on 22 November 2006.
Tagged: Wikipedia, WordPress