Charles Reace
PHP Musings

It's been almost a month since my last article. It seems work and other aspects of my life have contrived to keep me plenty busy lately. So to keep some level of activity going here, I thought I'd mention one of the things I've been up to lately.

I've been looking at a few PHP frameworks over the last several months as time permits (i.e.: not often!). The latest one I've tried is CodeIgniter. My initial impression is very positive--this one might be a keeper.

One thing I like about it is that it does not dictate a specific methodology with an iron fist. But what really stands out to me compared to others I've looked at is the quality of its documentation. Take a look for yourself at the online copy of the user manual, and I think you'll see what I mean.

If you're in the market for a PHP framework and have found others to be too inflexible and/or too difficult to learn, take a look at CodeIgniter and see what you think.

A common annoyance when dealing with user-supplied content is the way MS Word uses some non-standard character encodings (at least non-standard in terms of the web). Among others, these include the directional (a.k.a. "smart") quotes. The problem occurs when you output text that contains those characters as a result of a user copying and pasting text from a Word document. Typically they are not interpreted by the browser and the font being used, resulting in the dreaded place-holder characters (question marks, boxes, etc.).

If outputting the UTF-8 character encoding in your PHP pages, I came up with the following PHP function to help deal with this. It is inspired by this comment on Chris Shiflett's blog. It is simply a use of the str_replace() function to replace some known problem characters with character entities that should work better when outputting UTF-8 content.

<?php
function filterText($text)
{
   $search = array (
      '&',
      '<',
      '>',
      '"',
      chr(212),
      chr(213),
      chr(210),
      chr(211),
      chr(209),
      chr(208),
      chr(201),
      chr(145),
      chr(146),
      chr(147),
      chr(148),
      chr(151),
      chr(150),
      chr(133)
   );
   $replace = array (
      '&amp;',
      '&lt;',
      '&gt;',
      '&quot;',
      '&#8216;',
      '&#8217;',
      '&#8220;',
      '&#8221;',
      '&#8211;',
      '&#8212;',
      '&#8230;',
      '&#8216;',
      '&#8217;',
      '&#8220;',
      '&#8221;',
      '&#8211;',
      '&#8212;',
      '&#8230;'
   );
   return str_replace($search, $replace, $text);
}

// USAGE:
header('Content-Type: text/html; charset="UTF-8"');
echo filterText($test);
?>

The intent of this article is to tie together some things I've learned to do in order to get my web apps to "play nicely" with the UTF8 character set. Before we go any further, let me state that I do not claim to be an expert on this; the following is simply a collection of things I've discovered here and there on the web, and which together seem to help smooth out most of the bumps in the road of using UTF8.

So let's start with the database itself. To get your varchar and text fields talking UTF8, you should assign both the character set and a corresponding collation. (See the MySQL manual section on character sets and collations to see the differences between the various collation types.) You can assign this stuff at the field level should you desire, but generally I just assign it at the table level:

Read the rest...

Here's a little one-liner I thought up today for this PHPBuilder forum thread. It's purpose is to calculate someone's age when you know the year, month, and day of their birth (integer values). In this snippet it is assumed that $year, $month, and $day hold the integer values for the birthday of interest.

$today = time();
for($yr = $year, $age = -1; mktime(0,0,0,$month,$day,$yr) < $today; $yr++, $age++);
echo $age;

This utilizes the often ignored fact that you can use comma-separated statements for the first and third expressions in the for loop definition list.

After seeing the effectiveness of the Akisment WordPress plug-in at filtering out spam comments here, I decided to see if I could use it in conjunction with a email contact form. I thought it might be interesting to some of my readers (there are at least a couple) to keep a sort of journal here of what I do to accomplish that, plus it might help encourage me to finish it.

So the first thing I've done is to create an Akismet class that can take the pertinent data, contact the Akismet server via cURL and send it that data, and then return the response as a boolean (true == spam, false == not spam).

Read the rest...

In response to this thread at WebDeveloper.com, I came up with the idea of using PHP's Tidy functions to format the HTML output from a script. The basic idea was to capture all the output by using ob_start() to buffer the output and then ob_get_clean() to save it to a variable. Then just run it through the tidy_repair_string() function with a couple configuration settings to indent it.


<?php
ob_start();
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>test</title>
</head>
<body>
<h1>Test</h1>
<ul>
<li>This is a test.</li>
<li>It is only a test.</li>
</ul>
</body>
</html>
<?php
$text = ob_get_clean();
$config = array(
'indent' => true,
'indent-spaces' => 4
);
$text = tidy_repair_string($text, $config);
echo $text;



But Read the rest...

Due to the recent number of "Spam" comments received on this blog, I have been forced to implement the restriction that all users must be registered and logged in before they can submit comments. Sorry for any inconvenience; once again you can thank the spamming scum of the world who do their best to ruin the interenet for the rest of us.