Why Should I Care What Server My Application is Running On?

Imagine this – you develop an application on your machine and then, when you come to deploy it to the production server, all of a sudden, you encounter various errors and failures. Or maybe, when you decide to switch your hosting provider, your application stops behaving the way it should. How about this – one day, out of the blue (well, out of your IT manager’s whim) your application just misbehaves. Sounds familiar?

Whenever something like that happens, you know it’s going to hurt. You know that you will probably spend hours going over large parts of your code in order to identify where these sudden errors came from. If you are lucky, you may find that it is a configuration change which can be undone, but in most cases, you don’t have control over that.

So what can you do to avoid such cases? Well, your best option would be to write your code in such a way that it will be less sensitive to the server it runs on. This article will touch some issues which can help you achieve that, by:

• Avoiding issues that may arise from different PHP directives configurations (such as magic_quotes or the infamous register_globals)
• Avoiding functions which behave differently on different servers
• Using built in constants such as PHP_EOL or DIRECTORY_SEPERATOR

Some may argue that using a framework or a toolkit of some sort will solve all that, but as much as I encourage that, I will not take that as a bulletproof solution to the problem. We may never take it as a given that the supporting code we are using will protect us. However, since we are using PHP, we can review the code and verify that it really does help us or check the documentation to make sure. So, if you are planning on using a framework or a toolkit, check it before you trust it.

So, which directive configurations should we be aware of? Well, not counting on the infamous register_globals to be set to any value is obvious. Just assume that it is turned off and work like that, as using it can create many errors in your application, but may also create some major security holes. Another directive’s value that should not be assumed is the short_open_tag which means you should not write code starting with <? or even the magical <?=, but instead use <?php and <?php echo respectively. This is one of the standards you should get used to in order to avoid future mishaps of revealing all your code in clear text after deploying your application to a new server. Other directives worth mentioning are display_errors, magic_quotes_gpc and variables_order.

In regards to directives, the best option is to have a strict php.ini in your development environment, based on the php.ini-recommended file and then when you switch servers, chances are you will face less problems.

There are some PHP core functions which behave differently on different types of servers. For example, setlocale() might affect other requests if run on a Windows machine as it affects the whole process and not just the specific thread. A rule of thumb would be to suspect any function which needs information from the server, such as file system related functions (e.g. chmod() on a Windows machine), timezone functions, and of course, shell execution functions. Some of them may fail because of our improper handling, others may fail because of things like safe_mode. Try to avoid functions like that if you can, and if you have to use them, learn what these functions do, and what they can harm. Be paranoid, it helps.

Another group of functions which may cause issues are extensions’ API functions. Think what might happen if you call mysql_connect() and the MySQL extension is not loaded on the production server. If you are using a specific function in a contained location, such as wrapping it in a class, you may encapsulate it with a call to function_exists() to make sure you don’t call it if it is not there and then handle how the application should act when missing that function. If you are using that extension all over the application, you may wish to create some bootstrap file which will be included in your scripts and check that the extension is there using extension_loaded().

An important note about functions on different machines is that we should distinguish between functions that behave abnormally on different machines, which are the ones mentioned in the previous paragraphs, and functions which help us work on different machines. An example of such a function would be sys_get_temp_dir() which as I’m sure you can guess from its name, gives us the machine’s temporary directory, be it C:\Temp or /tmp or even Z:\MyFiles\AreFunky\AndCrazy

A standard which should be adopted by all is the use of built in PHP constants, for the same reasons I gave so far. Constants such as PHP_EOL (PHP End-Of-Line which will be converted to \n or \r\n depending on the system) or DIRECTORY_SEPERATOR (which will be converted to \ or / ). There’s also PHP_INT_MAX so you don’t need to worry about the machine’s architecture and PHP_OS or PHP_VERSION which I’m pretty sure you can guess yourself what they do.

There are many more issues and items we can discuss, such as design patterns and other best practices, which may all help us reach that goal of creating an independent application, but I think the major point has been made. Take into consideration at all times that the machine you are developing on may differ from the one you will be running the application on; Be aware of the common problems mentioned above; Develop in a strict environment so that you will face less surprises when you deploy; Have a bootstrap file in your application to check that what you need is what you get (WYNIWYG); Be paranoid.

Footnote: This article is a basis for a session I’m about to give at the coming Zend Conference. If you have anything to share, like good stories of things that had happened to you, or issues I’ve missed here, I’d be happy to hear from you. Please do share.