Cross-platform code 4: Coping with php.ini differences
If you have made a lot of changes to your php.ini file, or indeed any changes from the default php.ini file, it is possible that scripts your write will not work elsewhere. There are three common culprits: extensions, register_globals, and safe mode.
If you have enabled an extension which is not enabled in someone else's php.ini file, people deploying your script will get lots of errors about undefined functions. The best way around this, other than adding warnings about required extensions in your readme file, is to have a checkconfig.php file that runs checks on the current configuration to make sure it has the correct extensions available.
Register_globals is a setting that, when enabled, makes PHP put all user-submitted variables into the global scope automatically - not very secure, as you can imagine. The problem is that this setting was enabled by default in old versions of PHP 4, which means that a lot of people might have this setting enabled still. If someone gives you a script that requires register_globals being enabled, it is probably best that you do not use it - it is not worth the security risk. Similarly you should avoid writing scripts that rely on register_globals, even if you choose to enable it locally - most people out there leave it disabled, as recommended.
The third problem you are likely to encounter when people use your scripts elsewhere is safe mode. With safe mode enabled there is very little you can do to ensure your script will work without flaw, because administrators can disable whichever functions they deem unsafe - even very basic functions. If you think there might be problems with your script (reading files is the most common problem), your best bet is to provide a list of what your script requires with your documentation - that way, people stuck with safe mode enabled can at least see what the problem is, and maybe even ask their ISP to relax their restrictions a little.