The PHP Anthology Volume 1, Chapter 1 - PHP Basics

How do I write portable PHP code?

Not all PHP installations are the same. Depending on version and configuration settings in php.ini, your script may or may not run correctly on another server where PHP is installed. However, there are some general good practices you can adopt to make life easier and minimize the need to rewrite code for other servers.

Keep All Configuration Central

For most PHP applications, it will be necessary to provide information describing the environment in which the script will run, including database user names and passwords, directory locations, and so on. As a general rule, try to keep the majority of this information in a single place—maybe even a single file—so that when the information needs to be modified, you can do it all in the one place. That said, when building modular applications, you may want to store elements of the configuration that are local to a specific "module" with the module itself, rather than centrally.

How exactly you choose to store this information is a matter of personal choice. In some cases, it may be worth considering an XML file or storing some of the information in a database. It's also worth being aware of the parse_ini_file function, which I'll explore in Chapter 4, Files.

A simple but effective mechanism is to place all the settings in a single file as PHP constants, which makes them available from any function or class in your application. For example:

Example 1.7. 6.php

<?php      
// Configuration settings      
define('DOMAIN', 'sitepoint.com');      
     
// In another script      
echo 'The domain is ' . DOMAIN;      
?>

Constants need to be used with caution, though. To make your functions and classes reusable in other applications, they shouldn't depend on constants of a fixed name; rather, they should accept configuration information as arguments. In such cases, it's best to use PHP variables in your central configuration file, which you can then pass to functions and classes as required. If you look at Chapter 3, PHP and MySQL, when connecting to MySQL we can identify a number of variables we need to have in a central location: the server host name, the user name, the password, and the name of the selected database.

Using the require_once command we looked at in the previous solution, we can create a file called, for instance, config.php, and place it outside the public Web directories. This helps ensure that no one accidentally browses to the file containing this critical information, which would place the site's security at risk.

Use the Full <?php ?> Tags

PHP supports a variety of tag styles to mark up sections of PHP code, including the short tags (<? ?>), and ASP-style tags (<% %>). These are controlled from php.ini with the settings short_open_tag and asp_tags. While you have these settings set to On, other people may not. The short tag style, for example, causes a problem when the PHP is mixed with XML documents, which use processing instructions like this:

<?xml version="1.0"?>

If we have a document which contains PHP and XML, and we have the short_open_tag turned on, PHP will mistake the XML processing instruction <?xml for a PHP opening tag.

It's possible that your code will need to run in environments where short_open_tags and asp_tags are both off. The best way to be sure that they are is to get into the habit of always using the <?php ?> tag style, otherwise there may be a lot of code rewriting to do in some dark future.

register_globals off

PHP is capable of turning incoming data into native PHP variables. This feature is controlled by the register_globals setting in php.ini. With register_globals switched on, if I point my browser at an address like http://www.mysite.com/index.php?logged_in=1, PHP will automatically create a variable $logged_in and assign it the value of 1. The PHP group now recommends this setting be disabled because it presents a risk to security, as the previous example suggests.

So, in php.ini make sure the following code is in place:

register_globals = Off

This will force you to access incoming data via the special predefined superglobal variables (e.g. $_GET['username']), which means they won't conflict with variables you've created in your script.

Using a .htaccess file with Apache, the same result can be achieved with the following code:

php_flag register_globals off

Further information can be found in the PHP manual, and in Kevin Yank's article, Write Secure Scripts with PHP 4.2! on SitePoint.