Viewers: in countries Watching now:
PHP is a popular, reliable programming language at the foundation of many smart, data-driven websites. This comprehensive course from Kevin Skoglund helps developers learn the basics of PHP (including variables, logical expressions, loops, and functions), understand how to connect PHP to a MySQL database, and gain experience developing a complete web application with site navigation, form validation, and a password-protected admin area. Kevin also covers the basic CRUD routines for updating a database, debugging techniques, and usable user interfaces. Along the way, he provides practical advice, offers examples of best practices, and demonstrates refactoring techniques to improve existing code.
When we encounter an error in our code, more information that we have about that error, the easier it's going to be to resolve it. In this movie, we'll look at the Warnings and Errors that PHP generates and learn how they can help you to resolve problems. The first and most important thing is to make sure that error reporting is turned on, we can't deal with our errors if we can't see them. So we want to make sure that PHP is reporting errors as they happen to us, when we're in development. There are two ways to do this. The first is that we can set the error reporting in the php.ini file. And we saw how to do that back in the configuration chapter.
You just edit your php.ini file to have display errors on, error_reporting equal to whatever settings we want to have for that. And then, restart our web server so that it reloads that php.ini file. We can also set the error reporting on the fly in our PHP code. This is especially useful if we are working on a server where several people are sharing a copy of PHP. The PHP ini file might not have the settings that we want customized for our little bit of code. So in that case we can use the function ini_set to set the value as if it had been set in the ini file. So I can set display errors to be turned on and I can set error reporting using the error reporting function.
Notice that On is the word On, it's a string, but error Reporting is using a constant, E_ALL is a constant, it does not get quotes around it. There are a variety of values that we can provide to error reporting. A lot of those are detailed in the php.ini file, or on php.net. Let's just look at a couple of them. One is that we can provide E_ALL and then an upright pipe followed by E_STRICT. What this is saying is we want all errors and also the strict errors. Strict is a category of errors that was added to PHP 5, but it wasn't incorporated into ALL until 5.4.
So if you're using 5.4 and only 5.4, you can omit that second part and just have e underscore all. But if you're using 5.3 or anything before that or if you're going to be moving back and forth. Then you want to have both of them so you're seeing all errors all the time. Now we don't have to see all errors, we can selectively turn off some errors. So if we wanted to turn off the errors regarding deprecated code, then we could have E_ALL ampersand. And then the little twiddle followed by E_DEPRECATED. Deprecated is a fancy word for code that's been scheduled for removal from PHP, so in the future it's going to stop working.
I think it is generally a good idea for you to go ahead and have those errors in there so that you make sure that your code is forward compatible. And last, I just wanted to show you that you can return the current error_reporting level by just calling error_reporting with no argument. Now, what it's going to return to you is a number. It's not going to return to you one of these constants. These constants all represent numbers. And it takes those and compiles them together into a single number that it will return back to you when you call error reporting. You can get that full list of numbers on the php.net website. There's a full list of all those constants and what numbers correspond to them.
Let's take a quick peek. So here I am on that webpage. And it has all the predefined constants here, starting with Errors and Logging at the top. And you can see here is the constant, and here is the value that corresponds to it. If you scroll down here to the bottom you'll see here is e underscore all and the number that corresponds to it. What it does is it takes all of those numbers and adds them up in order to figure out what the current user level ought to be. It also gives you a description of what each of these error constants mean. This can be really useful when you want to configure your error reporting to report something less than all of the errors.
Most times I think, you probably just want to have it report all errors back to you though. And while this page lists off many different categories of errors, there's actually four main categories. Let's take a look at those and see what they mean. The first category of errors are Fatal Errors. What this means is that PHP understood what we were asking it to do, but it could not execute it. It would be like, if I asked you to walk from New York to London, you understood the English sentence that I just said, it made perfect sense. But you can't do it. When PHP encounters a fatal error, it is fatal for your code.
It means that the page of code cannot be executed, and so you don't get back anything. It's essentially saying that PHP tried and gave up. The most common cause of a fatal error is going to be calling an undefined class or a function. If you try and call a function that hasn't been defined, obviously it can't do that for us. The second category of errors are going to be Syntax Errors. In this case, PHP just plain all couldn't understand what we were asking it to do. This is usually the result of a typo, a missing semicolon, a quotation mark, a parenthesis, something like that, something that makes our code not valid.
It tried to parse it; it tried to figure out where one thing started and where one thing stopped. And it couldn't make any sense of it. And therefore, it gives us a syntax error. Often these will be reported as a syntax error, and it will say unexpected something in this file at a certain point. It was expecting to get a closing parenthesis, but instead it saw a call to define a function. Right, that was unexpected, and so it goes ahead and says oops, that's a syntax error, something's wrong here. After the error, it'll also tell you what file the error was in and the line number where the error was encountered. It's helpful if in your text editor you turn on line numbering, so that you see the line numbers running down the left side.
That'll help you identify the line very quickly. It's also very common with syntax errors for the line number to be off by one. Because if it encountered an unexpected something, the problem is probably that something happened right before it that caused it to be unexpected. Next category are Warnings, this indicates that PHP found a problem but it was able to recover from it, it was non-fatal. It understood what you were asking, it was able to execute it but it ran into a bump along the way. It indicates that you made a mistake and have a bug in your code. It wasn't a fatal error but the page is probably not correct, probably not what you intended.
An example of a warning would be if you tried to divide by zero. It would come up and give you a warning that you can't divide by zero. It'll keep processing everything after that, but whatever that mathematical operation was will have failed. You'll also get warnings if you have the incorrect number of arguments sent to a function or if you have the incorrect path to a file. Or if you don't have access permissions to access a file. In the last category are Notices. Notices are just PHP offering you advice. Think of it as PHP telling you that something smells bad. It's a good indicator of bugs and sloppy programming style. And it can also include those deprecation notices that tell you about code that's scheduled to stop working, in future versions of PHP. Your code is fine, but you really ought to think about making these adjustments. If we were going to turn off one of these four categories in development, notices is probably the one that would go first.
Now as I said at the beginning, we want to make sure that we do see these errors and warnings when we're in development. It's tremendously helpful for identifying problems, however we do not want to have errors displayed when we launch our website to the world. First of all, they're ugly. And second it would be a major security failure that would reveal far too much detail about our code. So you want to make sure that you turn off error reporting when you launch your website to the world. But just because those errors aren't on the screen anymore, doesn't mean that they don't exist. Errors are notices still generated by PHP whether they're displayed or not. And it's important to know that that takes up some time, so if you have a lot of those pesky little notices that have been generated. Well if you deploy with that PHP is still generating those notices and it does have an impact on performance for your website. So, it is better to go ahead and address them and fix them even if they are just notices about deprecations, go ahead and fix them now to speed up your website. The second point is that, chances are, those errors are still being logged by your web server.
And that's good because we definitely want to know about those errors that our users are getting on the live site. In fact, it's as important, if not more important, to know about problems that are happening on the live site. Then it is to find out about errors that are happening when we're developing. Now where your web server logs those errors can vary and can be configured, but I want to give you just a few of the places that you might look for it. Here on Mac OS X, chances are that be default, it's going to be logging to private/var/log/apahce2/error_log, and that's where you would find it. If you're on Windows in WAMP, chances are it's going to log into the WAMP folder, into Logs into php_error.log Or you can access those logs from the WAMP menu.
If you're running Apache, well then it's probably being configured inside Apache's Config file, and you could look there to find out where that's being stored. If you look in there, you do a search for Log, it should tell you where the Log file is being stored. If your version of Apache's loading in other configuration files, let's say different files for different domains that are hosted on the same sever. Well, then those might be the place to configure where the error logging occurs. You want to make sure that you check these error logs from time to time, otherwise you won't know what problems your users are encountering.
Find answers to the most frequently asked questions about PHP with MySQL Essential Training .
Here are the FAQs that matched your search "" :
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.