In the last two days there has been a new release of PHP4 (4.3.9) and PHP5 (5.0.2). When the first non-beta release of PHP5 came out I started trying it out. There are definitely some cool new features that were sorely needed in PHP, especially in the area of OO code. I’m still a bit bitter that they didn’t do multiple inheritance, I would have been happy with something similar to the way Perl does it (left to right depth first).

After trying out a couple of different applications that we run at work I decided to stick with PHP4 for production work for the time being. As much as I’d like to make use of PHP5 features, I just don’t see a major move to PHP4 for at least another 12 to 18 months. I must admit one surprise here, seeing apps that are already being written exclusively for PHP5. That must make for a relatively small target audience compared to the entire PHP community.

Another use for a blog, making predictions about the future so that the whole world can look back and see how wrong you were.

One of the great things about PHP is its flexibility and options. One of the bad things about PHP is its flexibility and options. The result is that programmers can’t be 100% sure what the conditions are (think php.ini options) that their software will be running under. So here are some tips that every PHP programmer should keep in mind, specifically while in development mode:

1. Magic Quotes: Ideally set this via .htaccess with php_value, either on or off, which ever way you want to work with your data. My personal preference of late is to turn this off and make sure that my code escapes everything. This avoids trying to guess when you need to escape something and when you don’t. This can be tricky when you have systems (databases usually) that have different formats for escaping quotes. Look at magic_quotes_gpc and magic_quotes_runtime settings.
2. Error Level: There are multiple error levels in PHP. When you are in development mode please, please, please set this to E_ALL (or maybe even to E_STRICT if you are using PHP 5). This can be done from within your code using the error_reporting() function. Once you are ready to make a release of your software you can turn the error level down if you want.
3. Display Errors: Along with cranking up the errors, displaying them makes them pretty obvious during the development process. This is also easily turned on using the ini_set() function. This is all it takes: ini_set('display_errors', '1');. This one isn’t quite as big a deal as the others because there is nothing wrong with watching errors in a log file, but I’ve found that if the errors aren’t being displayed in the page they are often forgotten about. And again, this is something that can be turned off when you make a release of your software. But if you’ve fixed all of the bugs that display errors or warnings then you shouldn’t need to

So when an error pops up in your page, don’t just turn off display errors or lower the error level, fix it. These settings I recommended above are the default for PHP on my systems, so if you have warnings and errors in your code they end up all of the page when I run your software. This makes your software look pretty low in the quality department. Keep in mind that as the author of a software package, you don’t know what people will have these options set to on their server, so your software should force them to a known value that you can rely upon.

I’ve been putting off this little rant for quite sometime, but lately the number of software packages that I’ve tried out that ignore one or all of the above suggestions was really high. In some cases large security holes were opened because of these assumptions (think magic quotes and sql injection attacks). Following these suggestions is much easier if you implement them at the beginning of a project instead of after version 1.0 has already shipped.

Peter Bowyer asked a question on his blog about optional case statements in PHP. After a couple of minutes I came up with two possible solutions. I tried to post the solutions as a comment to the blog entry, but it kept asking for a login in order to post a comment. I don’t have an account at his blog and I couldn’t find any info on how to create one. So I’m using this post to show a solution to his question. Hopefully the TrackBack to his entry works so he’ll be able to find this. Follow the link above to read the original question, below are the two possible solutions I came up with:

Solution 1)

$foo = 'baz';
switch($foo){
        case 'bar':
            print 'BAA';
            break;
        case 'moo' && !empty($varisset):
            print 'ANIMAL!';
            break;
        case 'brrrrr' && !empty($varisset):
            print 'COLD?';
            break;
} // switch

Solution 2)

$foo = 'moo';
switch($foo){
        case 'bar':
            print 'BAA';
            break;
        case (!empty($varisset)):
            switch($foo) {
                case 'moo':
                    print 'ANIMAL!';
                    break;
                case 'brrrrr':
                    print 'COLD?';
                    break;
            } //switch
            break;
} // switch

I’ve only done some basic testing to see if these work. I haven’t done any sort of benchmarking to see if one is faster than the other. I’d guess that solution 2 would be faster, but I don’t have any data to back that up.

It was likely to happen eventually, Zend has announced a PHP certification. Despite having just announced the release of PHP 5, the certification will only focus on PHP 4. The thinking behind that seems to be that it will still be awhile before PHP 5 becomes wide spread. I’m not sure yet how I feel about this idea. In general I have really mixed feelings about certification because some people are able to get certified that don’t really “know” anything about what they got certified in. On the other hand not everyone who has a certification falls into that category.

For some additional info on Zend’s PHP certification you can read comments by Chris Shiflett, John Coggeshall and Marco Tabini

On a related note, Zend has secured an additional $8 million investment. They now have a new U.S. headquarters in Cupertino, California. I wonder how far from Apple HQ they are?

The day has finally come, PHP 5.0 has been released. If for some reason you’ve been off the planet lately, PHP 5 is huge update to the guts of the PHP language. There is a long list of features and changes in this release. The MySQL client libraries are no longer included in releases (license issues aside this just makes sense, especially how old the client libraries they were including were) and SQLite is now included. The OO support has been heavily changed, most of which I’m happy with. I’m a bit disappointed that multiple inheritance is supported, in favor of the Java model of interfaces. I would have been happy with the Perl model of multiple inheritance.

There are has been lots of discussion about the new features of PHP 5, a good place to start is at the archive of PHP talks, many of which talk about PHP 5. Undoubtedly there will be some new books coming out about coding with PHP 5 in mind.

On another PHP front, Roadsend has release a PHP compiler for PHP 4. The benchmarks they list do show some impressive improvements in some areas. I think in the long run this sort of idea will either get swallowed up by the PHP project or only be useful to a smaller group of people.

So far I’ve resisted pretty heavily getting to involved with PHP 5. Now that there is non-beta release I’m going to swallow my pride and try it out. Initially my biggest concern is that all of my existing code based on PHP 4 works under PHP 5.

Update (6:47 pm 13 Jul 2004): Turns out there is PHP 4 to PHP 5 migration manual.

Update (3:09 pm 15 Jul 2004): Because OO support in PHP 5 has so many changes it may be helpful to read through the Classes and Object documentation specific to PHP 5. There are some sections that haven’t been filled in yet, but is still a good resource.

I’ve got a small function that builds an HTML select form given a name, array of options, an array of selected options and some javascript options. While looping over the array of options I have a very simple call to PHP’s in_array function to determine if the option currently being looked at is also one of the selected options. The code looks something like this:

           if(in_array($option, $selected_options)) {
               $out .= " selected";
           }

This worked most of the time, but started given me problems under certain conditions. This is where having loose typing in PHP can be a bit of a down side. So my first thought was to simply add true as the third argument to in_array which forces a type comparison as well as a value comparison. This fixed the problem for my previous error conditions, but broke the conditions where it was working before. I thought about adding another argument to my simple function as a hint to know if it should use strict type checking or not. That approach didn’t feel right, I wanted something that would just work. So I threw out the code above completely and replaced it with the following:

            foreach($selected_options as $selected) {
                if("{$option}" == "{$selected}") {
                    $out .= " selected";
                }
            }

In concept this does the same thing as in_array, but the comparison is always done in string context. So far this works under all of the conditions that I’m using it. One of the problem combinations is when 0 (zero) is a valid option. Another problem is when an option could be a number or a letter. With in_array I had to decide which way I wanted to it break, with a simple foreach using string context, both conditions work.

I doubt that this will be the best solution in call cases, but it seems to be working in mine where zero values and type issues were causing me grief. I’ve only been testing this for about 15 minutes, so we’ll see if this stands the test of time as it gets more use.