Here's a rundown of a few likely culprits, such as documents that contain no data and parsing problems -- and tips on how to avoid them. My document contains no data We'll start with the hardest problem to debug: the blank page. This mostly happens when you're trying to include or require another page. In plain English, that means you are trying to add content, PHP or otherwise, to be parsed within your script. This is useful for common code such as headers or login forms. However, if the PHP engine can't find that included page, or the page has errors, it will often cause zero output, making Internet Explorer return some strange HTML, and Netscape/Mozilla fail with the "document contains no data" error. This happens because many include and require statements end up at the top of the file, and for very good reason: The resources the file contains wouldn't be very useful if the statements appeared at the end. So we often see no data; nothing has the chance to echo out yet. Also, because of the way include and require behave -- actually processing the files included before actually including them -- any error messages can get lost, giving you a false sense of security. The best thing to do is to simply call each include or require in your browser to make sure there are no parse errors. Another tactic is to exploit the difference in the include and require functions. Although require will produce a fatal error and end script execution, include will simply pass over that point and continue processing the rest of the page. So sometimes it's worth switching your requires to includes. If you're still not sure that the problem is your include or require code, try adding this. This snippet will display debug messages onscreen that will enable you to determine whether the include code is causing your problems. When you execute it, you'll know how far the processing engine got. My variables have become unstuck According to most PHP proponents, one of the language's strongest assets is its ability to take any variable with some data attached and make it available to your code. This means you can generate simple dynamic content, such as getting data from the query string, without much hassle. However, security experts warn that this approach could allow people to execute malicious code from within the URL. To combat this, PHP developers turn off register globals for 4.1 onward. If your script relies on them -- and many if not most do -- be sure to either convert them using the new superglobal arrays or simply turn register globals back on in Php.ini, as shown in the following code: register_globals = On The superglobal arrays are simple to use. They consist of seven arrays containing all the information that previously formed individual variables. The most accessed arrays are $_GET[ ], $_POST[ ], $_SESSION[ ] and $_COOKIE[ ]. They contain the query string, form post data, session variables, and cookie variables, respectively. The remaining arrays are $_SERVER[ ], which contains information about the server; $_ENV[ ], which contains information about the environment; and $_REQUEST[ ]. This array is an amalgamation of the first four arrays. If data is being sent to you, but it could come in multiple ways (for example, both GET and POST), you can use the $_REQUEST[ ] array rather than querying the others, reducing your chances of error.