The need to diagnose and troubleshoot application's failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.

He shares seven different tips, some pretty simple, others a bit more difficult requiring other software to be up and working:

• Using phpinfo()
• Checking the wincache settings
• Looking at your error logs
• Turning on the display_errors setting
• Turning on HTTP logging, detailed errors and failed request tracking in the control panel
• Using XDebug
• Getting the statistics for your ClearDB instance

Back in 2009 there was a bug in the php_admin_value implementation before PHP 5.2.6. Since then, everything should run smoothly again. However, I find there's still a lot of confusion on when to use php_value, php_admin_value, php_flag and php_admin_flag. So I'll see if we can clear some of that.

He compares the three php_* flags you can use to set different kinds of values - "php_flag" for boolean operations, "php_admin_flag" (similar, but only in the vhost config) and the "php_value" that can be used for everything else, including overriding some settings in your php.ini.

I came across this question on Twitter last week: "How can I turn display_errors on for an application that is running in Windows Azure?" I have to admit that I was stumped. The only thing I could think of was to re-deploy the application with an updated php.ini file. But, I happened to mention this question to Ben Lobaugh who suggested a very simple idea: Store your PHP settings in some durable store external to your application as key-value pairs, then loop through the settings and update them with the ini_set function when a page loads.

He puts a big disclaimer on his suggestion, noting that it's "a hack and only a hack" and can be useful for someone still learning how to work with Azure and deployment. He shows how to use a Table storage to save the values and make them easier for the application to grab at runtime. Using the tools from their SDK, fetching and setting those values is a simple process. An idea like this, while convenient, could potentially cause performance issues down the line, do be careful with this recommendation (and be sure to load test).

A config.php or a settings.xml file is a very common thing for most PHP scripts, and it's usually where all the script settings (e.g. database information) are stored. The easiest way is to simply use a simple PHP script as a config file, but this may not be the best way, and it's certainly not the most user-friendly way.

In this tutorial we'll have a look at creating a Settings class which can handle any type of config format. I'll take you through the steps necessary to handle four different formats (PHP, INI, XML and YAML), but it's very easy to add more formats.

To start, they build the base class before quickly adding the get() and load() functions to pull in the external content. First on the list, they extend the base and make a pure PHP implementation holding the settings. Following that, they move on to the INI format, using PHP's parse_ini_file function to make it simple.

Last but not least, they venture into something a bit more complex - working with XML and the YAML formats to create this simple, handy tool.

They cover some of the options that you can alter (in the php.ini) to change the defaults for your sessions, including where they're written to. With those basics out of the way, the real meat of the tutorial comes in - the creation of a custom session handler. They base theirs on a few simple functions like open, read, write, destroy, etc. There's no code for those functions, but they do provide good descriptions for what they should do. To wrap it all up, they give the "howto" on actually using this functionality in your application.

I was wondering how people handled this situation themselves. I'm personally trying to decide whether my constants be in the class files, or a global configuration file. Right now I have a global.conf.php which contains things like (MySQL login info, include paths, table names).

So, my question is: Is it better to have one big configuration file, or should some things be defined on top of the individual classes ? (CONTACTS_TABLE.. is a clear example). I see pros and cons for both approaches.

He lists out pros and cons for the "one file approach" versus the "multiple specific definitions" method, for example:

• simple editing vs. easier to manage
• a single large file vs. multiple small files
• high memory usage on every page vs. lower memory consumption from loading only what's needed