| When developing Web applications with PHP and MySQL, you end up with potential bugs in one of four or more technologies. You could have HTML issues, PHP problems, SQL errors, or MySQL mistakes. To be able to fix the bug, you must first determine in what realm the bug resides. HTML problems are often the least disruptive and the easiest to catch. You normally know there's a problem when your layout is all messed up. Some steps for catching and fixing these, as well as general debugging processes, are discussed in the next section. PHP errors are the ones you'll see most often, as this language will be at the heart of your applications. PHP errors fall into three general areas: Syntactical Run time Logical
Syntactical errors are the most common and the easiest to fix. You'll see them if you merely omit a semicolon. Such errors stop the script from executing, and if display_errors is on in your PHP configuration, PHP will show an error, including the line PHP thinks it's on (Figure 6.1). If display_errors is off, you'll see a blank page. Figure 6.1. Parse errorswhich you've probably seen many times over by noware the most common sort of PHP error, particularly for beginning programmers. 
The second category includes those things that don't stop a PHP script from beginning to run (like parse errors do) but do stop the script from doing everything it was supposed to do, such as calling a function using the wrong number or types of parameters. With these errors, PHP will normally display a message (Figure 6.2) indicating the exact problem (again, assuming that display_errors is on). Figure 6.2. Misusing a function (calling it with improper parameters) will create errors during the execution of the script. 
The final category of error is actually the worst, because PHP won't necessarily report it to you. These are out-and-out bugs: problems that aren't obvious and don't stop the execution of a script. Tricks for solving all of these PHP errors will be demonstrated in just a few pages. SQL errors are normally a matter of syntax, and they'll be reported when you try to run the query on MySQL. For example, I've done this many times: DELETE * FROM tablename
The syntax is just wrong, confused with the SELECT syntax (SELECT * FROM tablename). The right syntax is DELETE FROM tablename
Again, MySQL will raise a red flag when you have SQL errors, so these aren't that difficult to find and fix. With dynamic Web sites, the trick is that PHP will often generate the SQL query, so PHP ends up being the real culprit. Besides reporting on SQL errors, MySQL has its own to consider. An inability to access the database is a common one and a showstopper at that (Figure 6.3). You'll also see errors when you misuse a MySQL function or ambiguously refer to a column in a join. Again, MySQL will report any such error in specific detail. Keep in mind that when a query doesn't have the result you expect, that's not a MySQL or SQL error, but rather a logical one. Toward the end of this chapter you'll see how to solve SQL and MySQL errors. Figure 6.3. An inability to connect to a MySQL server or a specific database is a common MySQL error. 
But as you have to walk before you can run, I'll begin by covering the fundamentals of debugging dynamic Web sites, starting with the basic checks you should make and how to fix HTML problems. Basic Debugging Steps This first sequence of steps may seem obvious, but when it comes to debugging, missing one of these steps leads to an unproductive and extremely frustrating debugging experience. And while I'm at it, I should mention that the best piece of general debugging advice is this: When you get frustrated, step away from the computer! I have solved almost all of the most perplexing issues I've come across by taking a break, clearing my head, and coming back to the code with fresh eyes. To begin debugging any problem Make sure that you are running the right page. It's altogether too common that you try to fix a problem and no matter what you do, it never goes away. The reason: you've actually been editing a different page than you thought. Make sure that you have saved your latest changes. Make sure that you run all PHP pages through the URL. Because PHP requires the use of a Web server, running any PHP code requires that you access the page through a URL (http://www.sitename.com/page.php or http://localhost/page.php). If you double-click a PHP page to open it in a browser (or use the browser's File > Open option), you'll see the PHP code, not the executed result. Know what versions of PHP and MySQL you are running. Some problems are specific to a certain version of PHP or MySQL. For example, some functions are added in later versions of PHP, and MySQL has added significant new features in versions 4, 4.1, and 5. Run a phpinfo() script (Figure 6.4, see Appendix A, "Installation," for a script example) and open a mysql client session (Figure 6.5) to determine this information. Figure 6.4. A phpinfo() script is one of your best tools for debugging, informing you of the PHP version and how it's configured. 
Figure 6.5. When you connect to a MySQL server, it should let you know the version number. 
Know what Web server you are running. Similarly, some problems and features are unique to your Web serving applicationApache, IIS, and PWS. You should know which one you are using, and which version, from when you installed the application. Try executing pages in a different Web browser. Every Web developer should have and use at least two Web browsers. If you test your pages in different ones, you'll see if the problem has to do with your script or a particular browser. If possible, try executing the page using a different Web server. PHP and MySQL errors sometimes stem from particular configurations and versions on one server. If something works on one server but not another, then you'll know that the script isn't inherently at fault. From there it's a matter of using phpinfo() scripts to see what server settings may be different.
Book Errors If you've followed an example in this book and something's not working right, what should you do? 1. | Double-check your code or steps against those in the book.
| 2. | Use the index at the back of the book to see if I reference a script or function in an earlier page (you may have missed an important usage rule or tip).
| 3. | View the PHP manual for a specific function to see if it's available in only a certain version and to verify how the function is used.
| 4. | Check out the book's errata page (through the supporting Web site) to see if an error in the code does exist and has been reported. Don't post your particular problem there yet, though!
| 5. | Triple-check your code and use all the debugging techniques outlined in this chapter.
| 6. | Search the book's supporting forum to see if others have had this problem and if a solution has already been determined.
| 7. | If all else fails, use the book's supporting forum to ask for assistance.
|
|
 Tips
If taking a break is one thing you should do when you become frustrated, here's what you shouldn't do: send off one or multiple panicky and persnickety emails to the author, to a newsgroup or mailing list, or to anyone else. When it comes to asking for free help from strangers, patience and pleasantries garner much better and faster results. There's another different realm of errors that you could classify as usage errors: what goes wrong when the site's user doesn't do what you thought they would. These are very difficult to find on your own because it's hard for the programmer to use an application in a way other than she intended. As a golden rule, try to make sure that a PHP script has all of the dataand in the right formatthat it needs before proceeding. Don't assume that the pages will always be used exactly as you had intended them to be!
Debugging HTML Debugging HTML is relatively easy. The source code is very accessible, most problems are overt, and attempts at fixing the HTML don't normally make things worse (as can happen with PHP). Still, there are some basic steps you should follow to find and fix an HTML problem. To debug an HTML error Check the source code. If you have an HTML problem, you'll almost always need to check the source code of the page to find it. How you view the source code depends upon the browser being used, but different stepsvariations on View > Page Sourcewere introduced back in Chapter 1, "Introduction to PHP." Use a validation tool (Figure 6.6). Figure 6.6. Validation tools like the one provided by the W3C (World Wide Web Consortium) are good for finding problems and making sure your HTML conforms to standards. 
Validation tools, like the one at http://validator.w3.org, are great for finding mismatched tags, broken tables, and other problems. On the other hand, validation tools will also report on nonstandard but perfectly functional HTML, which may not be the problem you were hoping to solve. Add borders to your tables. Frequently layouts are messed up because tables are incomplete. To confirm this, add a prominent border to your table to make it obvious where the different columns and rows are. Use Firefox's Web Developer widget (Figure 6.7). Figure 6.7. Firefox's Web Developer widget provides quick access to several useful developer tools. 
Besides being just a great Web browser, the very popular Firefox browser (available for free from www.mozilla.org) has a ton of features that the Web developer will appreciate. Furthermore, you can expand Firefox's functionality by installing any of the free widgets that are available. The Web Developer widget in particular provides quick access to great tools, such as showing a table's borders, revealing the CSS, validating a page, and more. Test the page in another browser. PHP code is generally browser-independent, meaning you'll get consistent results regardless of the client. Not so with HTML. Sometimes a particular browser has a quirk that affects the rendered page. Running the same page in another browser is the easiest way to know if it's an HTML problem or a browser quirk.
Tips Although Internet Explorer is still the most popular Web browser, particularly on Windows, Web developers are better served by using Firefox, Safari (on Mac OS X), and others. As just one motivating example, how Firefox lets you see and handle cookies can make debugging cookie problems infinitely easier. Obviously, you'll need to test your applications using IE, as most Web users run it, but develop your scripts with better tools, like Firefox. The first step toward fixing any kind of problem is understanding what's causing it. Remember the role each technologyHTML, PHP, SQL, and MySQLplays as you debug. If your page doesn't look right, that's an HTML problem. If your HTML is dynamically generated by PHP, it's still an HTML problem but you'll need to work with the PHP code to make it right.
|
