Introduction

PHP 5 has been out for a long, long time. Yet there is a disturbing trend. I still see servers with PHP 4 installed. Why would you have PHP 4 installed? Really, keeping PHP 4 won’t help you very much in the long run. It might be more convenient as you already know that all your script work in PHP 4, but I believe that it is worth it to upgrade to PHP 5.

Get PHP 5. It’s good for you.

1) PHP 5 has features that have been in other languages for a long time.

PHP 5 introduces exceptions. As many beginner programmers use PHP, having them learn PHP 5 exceptions means that they will be familiar with the concept when they move onto other languages.

2) It allows you to use tools that only support PHP 5.

Remember that content management system that you thought would be perfect for your site? But wait! It’s for PHP 5 only. Since you’re running a PHP 4 server, you miss out.

3) Because support for PHP 4 has been dropped.

What, so you’re going to continue using something unsupported when PHP 5 is right there?

Also, if you attempt to ask a developer friend for PHP help, there is a good chance that your developer friend will tell you to upgrade, unless he or she is also running PHP 4. If your friend is running PHP 4, you should send this article to him or her. ^_^

4) You don’t annoy people that write PHP code for your server.

Let’s bring back that developer friend of yours. You have a cool idea for a PHP web application. He or she asks which version of PHP 5 you are running. You say, with an embarrassed smile, “I’m running PHP 4.4.8.”

If your developer friends are used to PHP 5, it makes it much more difficult for them to write PHP code for your sever. Friends are good, save them a headache.

You’re a beginner PHP programmer, and your server has just been upgraded to PHP 5. Yay! Time to rewrite that error handling code to include exceptions! One mistake that beginner PHP programmers make is that they go crazy with exceptions. They might turn the below code:

function checkUsername ($username)
{
    if (!is_string ($username))
    {
        die ('The username is invalid');
        /* Also acceptable are:
        *     trigger_error (<something>);
        *     ^-- If you the proper error handling
        *         setup for site visitors.
        *
        *     return <something>;
        *      ^-- Provided that the caller saves
        *      the return value and that the
        *      value is checked.*/
    }
    else
    {
        return true;
    }
}

oldCheckUsername ($username);

into:

class OMGYourUsernameIsNotValidException extends
Exception {}

function checkUsername ($username)
{
    if (!is_string ($username))
    {
        throw new OMGYourUsernameIsNotValidException
        ('Username = fail');
    }
    else
    {
        return true;
    }
}

try
{
    checkUsername ($username);
}
catch  (OMGYourUsernameIsNotValidException  $e)
{
    echo $e->getMessage ();
}

Exceptions are best used for things like a database connection failing. They aren’t really for simple things like form validation.

Uncaught PHP exceptions are considered E_FATAL errors, and I consider that a good measurement of whether or not you need exceptions. While you might want to terminate script execution in the case of improperly filled in forms, you wouldn’t want to use that error level for form validation.

A failed database connection seems to fit well into E_FATAL, and by that logic, it’s okay to use exceptions for it.

Disagree? Know a better way to handle errors in PHP? Tell me in the comments.

I’ve talked about PHP before. One of the major problems is all the beginners writing code and posting examples that other beginning programmers use. But complaining on and on about beginner code isn’t actually very useful. What if I actually explained how to write good code in PHP and what sort of code that a PHP programmer should avoid? Well, that would actually be useful. That would accomplish something. That would be another series of posts at CodingExperiments.

So, here goes. This post in the series will cover using global variables in PHP, or rather, why you shouldn’t use global variables in PHP. First, let’s see what a global variable is, and what it does.

<?php
$random_variable = 'foo';
$awesome_variable = 'http://codingexperiments.com';
// This works
function bar ()
{
// Making it global makes it work
global $random_variable;
echo $random_variable;
}
bar ();
//
// This doesn't
function website_promotion ()
{
// $awesome_variable is not being made global here
echo '
' . $awesome_variable;
}
website_promotion ();
?>

If you were to run that script, you would get “foo”, and only “foo”. Don’t believe me? Try it out here. Any good programmer will tell you that the URL of this awesome website isn’t being displayed because of scope. Read more about PHP variable scope here.

So, why are global variables bad? Because they can be changed from anywhere. Global variables are often used for configuration settings, as they will be needed in many places in the program. Configuration settings typically should never change. That’s why PHP constants are a very good alternative for configuration settings.

If you want a read that really goes in-depth about global variables and so forth, you can check out “Why Global Variables in PHP is Bad Programming Practice“

The PHP function debug_backtrace ( ); is very useful, but it can be dangerous. A beginning developer trying to find a bug on a production-line website might be inclined to use print_r ( ); to show what debug_backtrace ( ); returns, as it returns data in the format of an array.

The function print_r ( ); displays things directly into the screen. That may not be very wise for a production-line website. After a little thinking, I came up with a secure way to view backtraces. It’s an easy one-line piece of code that can be inserted into a PHP (5) script.

file_put_contents (‘backtrace.txt’, print_r (debug_backtrace (), true));