Do You Filter?

A new PHP feature you might have missed (I know I did until I stumbled onto it recently) is the Data Filtering extension, which made its debut in PHP 5.2.0. This extension provides a set of functions for both validating and filtering of external data, such as users’ form inputs.

These functions are each controlled as to what sort of filtering/validating they do by a set of pre-defined constants. See the Data Filtering Introduction page of the manual for a list of the currently available filters. As an example of its potential utility in the simplification of your code, consider the validation of email address formats. Probably the most commonly used technique for this is to use a regular expression comparison. The most thorough implementation of such a function I’ve encountered is this one I found at iamcal.com:

Continue reading “Do You Filter?”

Excuse Our Mess

I’ve dived into the theme I was using for this blog to change to a new color scheme and appearance (featurning my best friend Noggin reminding me how unimportant he thinks all this computer stuff is). Looks like I got the main parts working OK, but there is still some tweaking to do. Hopefully I’ll have it cleaned up within the next day or two.

2008/07/12: I’ve finished fixing things (to the best of my knowledge). Let me know if you run into any problems with the display of any pages.

Beginners’ Corner: Avoid Bad Habits

This is the first “Beginners’ Corner” article, designed to help new PHP programmers in their quest to become veteran PHP programmers. In this initial installment we’ll look at a few things which are best avoided, but for various reasons often become habits of new PHP users who do not yet know better. Many of these may become habits simply because there are so many bad examples out there to learn from, often because they are dated and PHP has moved on in a manner which obsoletes them.

<?php Tags

The first bad habit to avoid is using <? instead of <?php or <?= instead of <?php echo. While saving those few keystrokes is a temptation to all of us lazy programmers, it is a potential problem should you need to run the script on a site where the short_open_tag option is disabled. One likely reason to have it disabled is in order to avoid confusion with <?xml tags in XML documents, and as XML is much more prevalent now than it was when PHP was created, you are more likely to find such configurations in use; so just get in the habit of typing those three extra characters and saving yourself a lot of aggravation in the future.

Continue reading “Beginners’ Corner: Avoid Bad Habits”

WordPress Upgrade

I just completed the upgrade to WordPress version 2.5.1. (WordPress is the application which runs this blog.) It was a relatively painless process, and as it includes an important security fix, I recommend anyone else out there using WordPress perform the upgrade as soon as possible.

Get the latest version here.

So far everything appears to be working fine, and hopefully it will have no effect on my readers (if there are any).

Most Used Words in File

I recently saw a question posted in a forum about obtaining the most-used words in a file for the purpose of populating the content of a “keywords” meta tag. It got me thinking about how I would do it. I knew I could use the str_word_count() function to count words, but running that against any typical [X]HTML file would give a lot of junk you would not want in your keyword list.

One obvious step was to use the strip_tags() function as a means to only look at actual content and not grab tag and property names. A bit more involved was how to avoid common words. Then it occurred to me that MySQL’s full text search mechanism utilizes a list of “stopwords” to ignore in its matching process. Luckily enough, I found the default list of stopwords in their online manual, so I copied that into a text file, ran a few search/replace operations on it to get it into one word per line, did a little massaging, and then I had stopword list ready to go:

Continue reading “Most Used Words in File”

PHP4 Is Dead; Long Live PHP5…

…at least until PHP6 is released.

As stated in the php.net release notes, “Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release.” The news archive also notes, “This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last normal PHP 4.4 release. If necessary, releases to address security issues could be made until 2008-08-08,” (my emphasis).

While I’ve often tried to create general-purpose functions and applications that could port to either PHP4 or PHP5, I’ve decided to forego any further support of PHP4 with any code I create (unless, of course, someone is paying me to create something for PHP4 for some reason). I would therefore like to encourage my fellow PHP hackers (in the good sense) to join me in encouraging all developers to move on to PHP5, and explain to all clients and hosting services that they should migrate to PHP5 ASAP, if for no other reason than to ensure that they can continue to operate with the most secure version of PHP by keeping up with the latest stable releases.

But this upgrade is also to our benefit, opening up access to the much more thorough class and object support of PHP5, enhanced database interfaces such as MySQLi, and new functions like filter_var(), just to name a few of the benefits. Additionally, we should strive to rid our applications of deprecated features and functions, in particular those that will not be supported at all in PHP6. (We don’t want to have to upgrade our scripts again, right?) According to Nathan A. Good in “The Future of PHP“, the following features will be completely removed from PHP6:

If your scripts depend upon any of those settings, it’s time to wean yourself of them now. Don’t wait until someone upgrades a server and all your scripts start crashing.

Clearing the Floats

No, this has nothing to do with the aftermath of the Macy’s Thanksgiving Day Parade. This is about that annoying thing with floated HTML elements within a container element, whereby it seems that said container has no inkling of the fact that it should expand enough vertically to contain any and all such floated elements.

I used to address this via the common Band-Aid of inserting a non-floated element just before the closing tag of the container, and giving that new element the clear: both; CSS property:

<div id='container'>
  <p class='float'>This element has a float:left or float:right;" style property.</p>
  <div class='clear'></div> <!-- "clear" class has the "clear:both;" style -->
</div>

But lo and behold, I recently discovered a simpler solution that does not require any extraneous, empty HTML mark-up, thanks to this article at  quirksmode.com. Now I can get rid of that semantically useless <div class='clear'></div> line in the above HTML, and instead just make sure the style for the “container” div includes:

#container {
  width: 100%;
  overflow: auto;
}

Beginners’ Corner: The Dreaded Blank Page

[2008/07/15: Added this to the “Beginners’ Corner” category]

A common problem I see new PHP users running into is having a script output absolutely nothing: the dreaded “blank page” syndrome. This is normally due to a syntax error of some sort generating a fatal parse error. As this error is generated before any of the script is actually executed, none of the file’s output ever gets sent to the browser. If the current PHP environment on the server has display_errors turned off, then not even the error message generated by the parser gets displayed. Additionally, since no PHP commands actually get executed when there is a parse error, turning on display_errors within that script via the ini_set() function will make no difference.

The two usual approaches to debugging such problems are to either search the PHP or web server error logs to look for relevant error messages, or else to turn on display_errors, either globally in the php.ini file or at the directory level via a .htaccess file, assuming you are running under Apache and the necessary Apache settings are in effect to allow this. (A third alternative is to use an editor that has PHP syntax checking built in, such as PHPDesigner.)

If for some reason none of those approaches is practical for your situation, a simple way to have any  parse errors be displayed is to create a tiny wrapper script that includes the offending file:

<?php
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
include 'path/to/flawed/file.php';
?>

All you have to do is run this script in your browser, et voilà, your parse errors will now be displayed.