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; ?>

Comment on this »

Posted at 23:51 in WordPress plugins

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 (1) »

Posted at 23:39 in Programming

Marco Arment (in a response to Jeff Atwood) came up with a list of five common complaints that are not valid reasons for hating a programming language:

• You’re unfamiliar with it.
• You don’t like the language’s vendors.
• Idiots often use it to write bad code.
• It doesn’t fully resemble your favorite language.
• You don’t like its syntax.

PHP’s not a perfect language, of course. Nothing is. But it’s by far the best language to use for nearly any web application, as long as you use an appropriate framework and good coding practices. Any language without either of those is bad.

I’d agree that PHP has its foibles, such as its lack of closures, its bloated global namespace and its ad-hoc, inconsistent approach to conventions. However, none of these are insurmountable, and in fact, once you get used to its foibles, working with PHP isn’t all that hard.

A few days ago I finished up on several days’ work on a PHP project and started on a SharePoint workflow. It’s an exercise that I highly recommend for anyone who is tempted to write an anti-PHP rant, because it will put everything in perspective, and give you a list of valid reasons for hating a programming language, platform or framework:

1. Vertical and infinite learning curve.
2. Unnecessary complexity.
3. Useless documentation.
4. Excessive pitfalls, gotchas and leaky abstractions.
5. Design that obstructs you from adopting best practices.
6. Meaningless, cryptic and uninformative error messages, buried in a massive log file deep in an obscure part of the bowels of your file system.
7. Painful debugging process.

Check this out: to debug a SharePoint workflow you can’t just hit run in Visual Studio. You have to attach the debugger to the w3wp.exe process, and even then it still won’t hit your breakpoints or break on exceptions. According to this blog post, you have to copy the .pdb file by hand into a part of the GAC’s directory structure that you can’t even access through Windows Explorer, so you have to do it via the command line. On top of that, the edit-compile-test loop is agonising — it can take two minutes to re-compile, deploy, and re-load your test site into your browser, after which you may well have to remove and restart the workflow.

Admittedly it’s not all bad. The vertical and infinite learning curve at least gives you some immense satisfaction when you finally “get it”. However, getting there feels at times like climbing the Inaccessible Pinnacle in rollerblades with your hands tied behind your back.

Comments (1) »

Posted at 15:58 in PHP, SharePoint