Wherein QA Fixes Its Own Issues

As commenter The QA Slayer pointed out in a preceding post, the comment text area was susceptible to the Hamlet test. Not so much that it dumped a stack trace, mind you, but in that it allowed the user to enter unbroken strings such as Hamlet, and the cascading style sheets and basic logic of WordPress didn’t have a mechanism for handling it gracefully; instead, the unbroken string would burst through the right side of the body image like an alien from Kane’s chest:

QA Hates You failed the Hamlet test, briefly
Click for larger

Well, all right, then, I guess that should be fixed.I’ve often logged issues like that in various and sundry positions where I’ve worked, and the people in charge of fixing things have often declined to fix this issue even though it’s a recurring issue with pretty much any Web site that we built. It was a kind of tradition; I would test a Web site, I would log the same freaking issue, and it would be resolved with a response that they wouldn’t fix it. Even though, as you know, gentle reader, some URLs run long and don’t have a handy place for word-wrapping. Oh, but no, that’s only an issue QA would find.

Armed with the Internet and a book about PHP, your humble Director tore into the code for WordPress and spent two hours devising a fix. That would have been one hour, but I took some advice from a developer that led me down a blind alley for an hour.

So here it is, gentle reader, a piece of server side validation that should keep your WordPress blog from accepting too long of an unbroken string:

if ('' !=$comment_content){
   $string = $comment_content;
   $i_length = 50;

   $tok = strtok($string, " nt");
   while ($tok !== false) {
      if (strlen($tok) >=$i_length){
        wp_die( __('Error: please keep your individual words to fewer than
        50 characters, as the developers who read this blog are not that
        smart.') );
    $tok = strtok(" nt");

Change $i_length to match a number of characters that can display well within your template and add this to your wp_comments_post.php file and it will display the error page if the user tries to enter a single unbroken set of characters that would go outside the boundaries of your nice layout.

Now that I have that, what do you call it, algorithm thing ready, I can use the logic anywhere I want; I could even bundle it into its own function to reuse throughout WordPress.

So what keeps developers from fixing these simple, recurrent issues? Because ThinkGeek.com won’t browse itself!

No Responses to “Wherein QA Fixes Its Own Issues”

  1. DarkStar Says:

    Not to be a stickler… that is your job after all. But as an occasional UI designer who also dabbles in sales, I feel confident in rejecting your solution. Not that you are out of line highlighting the problem, but there is a reason QA doesn’t develop, and developers don’t QA.

    How about… breaking apart the string, so that the text ends up wrapping properly? Perhaps with a hyphen? If I’m typing text into your comment box, and the text is very long and ends up getting rejected… I probably won’t stick around to retype or reformat and thus you’ve lost a sale… or comment… or complaint… If its a URL, then you will probably need some code to reassemble the URL in case it is clicked on… Yes, an annoying tidbit of coding work – but beneficial none the less.

    And while we are on the topic of QA… which we always are at this site… when a user registers, the confirmation message suggests that an email has already been sent containing the new password and is waiting for the user to simply go read it. Not so. It took more than 5 minutes for my password to show up in my Inbox. The message should probably say… “An email will be sent…” Rather than, “An email has been sent.” While the message may be technically correct, user experience will dominate.

  2. Director Says:

    Very true. However, I found the solution for the immediate issue adequate, and I was able to fix it quickly and I’m not even one of you highly-paid development professionals.

  3. angelweave Says:

    That developer that led you down the “wrong” path was your WIFE. And had she been the coder, doubtless it would not have taken two hours.

    That developer also cooks your meals. No defects there.


  4. gimlet Says:

    If you were truly a developer, you would have blamed the issue on the server OS, hardware, and/or webserver. You then would have insisted (in a geekier-than-thou tone) that the sysadmin(s) deploy a trendy, poorly-documented, and/or untested solution that is “better,” at least according to what you’ve read on Slashdot.

  5. Director Says:

    Sadly, DarkStar’s comment made me want to justify, to a larger extent, how I fixed the issue. So there’s a little developer in each of us.

    Now I am going to resort to the discipline to try to drive mine out.

wordpress visitors