you are writing scripts for the web, having your own local server to do the testing on is not only useful, it is essential. The last thing that you really want to be doing is to use the live server where the final script is going to run to do your testing. Even if you use a separate password protected folder for the test copy it isn't ideal as you would then be copying the files back and forth to your computer every time you want to make a change in order to make use of a decent editor.
There are a couple of different ways you can set up your own server. The easy way is to use XAMPP or WAMP/MAMP/LAMP which provides a single install of not only Apache, PHP and mySQL but which also include some other associated utilities. This has the advantage of easy install but is the more complicated option when it comes to upgrades to the various components. The other way to handle this which gives greater control but which is more complex for the original install is to install each of the component parts of your web server - Apache, PHP, mySQL, etc separately.
No matter which way you set up your test server, the fact that it is a different server from your live site means that the configuration will be potentially different and what works on one server may produce unexpected results on the other. The simplest part of the configuration to check is version numbers. Are you running the same version of Apache, PHP and mySQL on both servers. The ideal solution is to have the same version of each of these running in both places but it is not necessarily going to be a problem if the versions are not exactly the same. Where the versions are different you need to be aware of what has changed between the versions so as to take that into account in the way you write your code. Often shared hosting provides multiple versions of PHP on the server so that you can select to run the version there corresponding to your test environment so as to ensure that they are as close as possible - possibly differing in which maintenance patches are installed but having no significant difference in what code they support. When you are coding PHP the version differences for Apache and mySQL are going to be less significant in terms of the code you write.
When it comes to the rest of your configuration some things will be really obvious (such as whether PHP short tags are supported or not) while other things will be far less obvious and may not show up as problems for a long time. One option you have is to extract all of the configuration options from the live server and make sure that your test server is configured exactly the same way. Of course if you move hosting for your live site then the new hosting may be configured slightly differently. For many of the configuration options it isn't going to matter if they are set up differently until you try to do something that is affected by that particular option. Simply accepting that the options are slightly different so that you need to recheck that things work properly after they go live is often the quickest way of dealing with this. This is particularly the case where undoing the changes if they don't work is relatively easy. In the rate instance where the configuration does make a difference you can investigate what the cause of that particular problem is when it occurs without having slowed down the many preceding changes where the configuration differences didn't matter.
One configuration difference that I didn't concern myself with until it caused a significant problem is the include path that PHP searches when looking for files to be included that do not have the path defined in the include statement. I occasionally found that an include that was being found on my test server wouldn't be found on the live server and so would modify the include call to add the path to where the file was located.
The more serious problem with include paths occurred when I implemented a change that included a new file that just happened to share the same name as a file in another folder. The live script put itself into an infinite redirect loop with the page constantly redirecting to itself. A few quick tests narrowed the problem down to the particular include causing the problem but the reason for the problem wasn't obvious as I hadn't written the include file that had the problem (it was a polyfill file for new PHP 5.5 commands to allow them to be used in PHP 5.3 and PHP 5.4). The most obvious configuration possibility was that the live server was running a different PHP version to what I thought it was. Support staff at the hosting were able to confirm that the PHP version was correct and that the script wasn't generating any messages in the log to provide any clues as to what was happening. Obviously the configuration problem was elsewhere. As the redirects occurred when the include was uncommented and stopped when it was commented (I'd reverted the rest of the code back so as to not need the include) the next thing that occurred to me was to try to narrow down where in the include that the problem was occurring. I started by commenting out all of the code in the include file and uncommenting the call to include it. The problem came back indicating that none of the code in the include was causing the problem but that the problem was being caused by picking up the wrong file. Restoring the include file back the way it was originally and renaming the file got the script working properly. When I advised the hosting support that renaming the include fixed the problem they reminded me that I had another file with the same name in the parent folder. Realising that this file was being incorrectly run instead of the correct file explained why the infinite redirects were occurring and also identified the particular area of the configuration that caused the problem - the include paths on both servers were different with them searching the folders in a different order - something that only made a difference when the folders contained files with the same name.
The alternatives to actually changing the configuration of my test server so that the include path matches the live site include path is to either make sure that no two files have the same name or to always include the path in the include statements. So it isn't always necessary to make the configuration match exactly (particularly sine changing hosting may mean that what did match with the configuration at the old hosting may not match with the new hosting. Knowing what caused a particular problem means that you can avoid the situations where that problem can apply and then it doesn't matter if the configuration is different (making your code more portable).
If you are writing code that you expect others to be able to run on their hosting where you don't know what their configuration will be then using these alternative fixes that avoid any configuration issues are even more essential. You can't make your test environment match everyone's live environment and so making your live and test environments use the same configuration is not a good idea.
This article written by Stephen Chapman, Felgall Pty Ltd.