You are very correct that the differences in hosting providers can cause a major headache! In my personal experience, I prefer to lay down some requirements for the software that I consider to be reasonable. For example, I require everything I write to require PHP 5. if someone wants to install something that required PHP5, then it isn’t hard to find an appropriate host.

That way, there’s no need to maintain compatibility with both systems. Trying to maintain compatibility with PHP4 and PHP5 at the same time will require a extra maintenance and a lot of library functions. Avoid it if you can! It will make your life a lot easier.

What I DO try to do, however, is not use features that have been introduced in recent PHP versions (5.2, 5.3) and stick with what has been around for a while (5.0, 5.1). Hosting providers are awful about keeping things up to date…

Speaking of error handling – if you are developing software for both PHP4 and PHP5, then you may want to consider looking at how PEAR (pear.php.net) handles errors. In PHP4, Exceptions did not exist, so most things dealt with errors the same way you do in C; return 0, -1, false, or some other basic value to denote an error condition.

What PEAR does instead is return an error object, with a message, error code, stack trace, all kinds of good things from calls that fail. So, to check for an error condition from a PEAR library, you would call:

if (PEAR::isError($result = $object->someMethod())) {
echo "Something broke!";
}

This was a godsend back in the days of PHP4 and worked very, very well. It provided some of the benefits of exceptions (good data about an error) in an environment that didn’t support them. If course, the code ends up having a lot of PEAR::isError blocks, but being able to handle and capture errors this way is a big benefit over checking for false.

One pitfall that I see very often is string manipulation NOT being multibyte safe. For example, substr can break a Unicode string since it works on bytes, not characters. The mb_ functions are what should be used, but I have found that not all providers have it installed. One great solution that I found was this utf8 library that uses the native mb_ functions if they exist, but if thy do not, uses a pure PHP implementation for the same effect: http://sourceforge.net/projects/phputf8/

Something that you may find useful (I find it to be VERY useful) is the auto_prepend feature. Every page needs access to standard libraries and configuration values, and using auto_prepend means you don’t have to add it to the top of every page.

Combine this with __autoload and you have a great way to avoid a mess of require statements on every page. This only works, however, if your hosting provider allows you to use a custom php.ini or set values in an .htaccess file.

Hope this helps – if not you, then someone else who stumbles along. PHP is a great language, but much like Perl it gives you a lot of rope. You can tie fancy knots or end up hanging yourself!

Keep up the good work…

No, not at the moment. Check out WordPress for a good blog you could get for free. And then you could either install that in a sub directory or link to it from your page.