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: 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

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: 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: 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

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