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

I was late home this evening because I was sorting out a problem for one of our clients. One particular database table has a couple of triggers that update some tables in other databases. It turned out that someone had renamed one of these other databases but had forgotten all about the triggers, which were throwing errors as a result. Fortunately, it didn’t take too long to track down the problem and fix it.

This kind of thing is very easy to do if you have a lot of database interdependencies and stored procedures like this. Databases are by nature very tightly coupled to your other applications and systems, and making major changes to them calls for nerves of steel at times. They are frequently accessed not only by the applications that you know about but often by several that you don’t, especially in larger organisations. With that in mind, any smart advice and help that you can get is most definitely welcome.

This is why Refactoring Databases by Scott Ambler and Pramod J Sadalage (Addison-Wesley Signature Series) is a book that I highly recommend to any developer (or DBA) working with databases in any capacity. It has a lot of useful advice on how to handle different scenarios that you may come across (including political ones), as well as details about the precise mechanics of specific refactorings, and shows you that with a disciplined, iterative, step by step approach, backed up by a suite of unit, integration and regression tests, it needn’t be all that scary.

Comments closed (1) »

Posted at 23:39 on 14 July 2008.
Tagged: books, deployment, programming