DISPLAY ERRORS AND ERROR REPORTING
With this function ini_set (‘ display_errors ‘, 0 ); we disable the display of errors . For example, we do not display a warning on an undeclared variable. If we set display_errors to 1 we activate the display of errors and display a warning on an undeclared variable. display_errors only concerns the display of errors within the page, error_reporting writes a log file with the errors or warnings that have occurred . If we set error_reporting to 0 even if display_errors is set to 1 we do not display errors. If we don’t want to report warnings with error_reporting we use this syntax.
error_reporting ( E_ALL & ~ E_WARNING );
It is good practice in both development and production to leave E_ALL. In order to view everything. Report the image of the log file on XAMPP, if error_reporting is set to E_ALL the errors are written to this file. Conversely, if set to 0, errors are not recorded in the file.
CUSTOMIZED ERROR FILE WITH THE ERRORLOG DIRECTIVE
It is not a good idea to use a single log file for all applications. However, we can define a specific log file for our application. At this moment the log file is located in the location on windows c:\xampp\apache\logs . To create a log file for our application we need to define a directive within our virtual host. Soon I will explain what a virtual host is, but at the moment we create a log file for the application. Let’s modify the basic folder structure by putting all the content inside a public_html folder. We now want this folder to be the application’s document root. We modify the virtual host as follows:
With the ErrorLog and CustomLog directives when we restart apache two files will be created whose path is the one specified in the virtual host.
THE HTACCESS FILE
In order for the application log file to be written, we need to create a file. htaccess and insert the following lines.
If we now try to make a request to the tmp.php file with an undeclared variable inside, the warning will be reported in the application’s ErrorLog file and the request traced in the request.log file.
CONFIGURATION OF THE VIRTUAL HOST
As we know in the internet, each device is associated with an IP address, in this way we can effectively reach every device in the network. However, if a server had a single IP address it would mean that that server can only host one website within it. In reality this is not the case because one server can host dozens of websites. Virtual hosts are used to do this. The first step is the creation of the Virtual Host in Apache. Let’s look for the httpd-vhosts.conf file, which should be inside the folder
<Installazione di
XAMPP>\apache\conf\extra
and make a backup copy of it for safety (eg by calling it httpd-vhosts.original.conf). Then we open the file with any editor (on Windows we recommend Notepad ++ ) and uncomment the line
NameVirtualHost *: 80
in this way we enable the recognition of virtual hosts based on the name present in the URL, that is, based on the domain name (virtual in this case). At the end of the file we insert the lines instead:
<VirtualHost>
ServerName localhost
DocumentRoot ” C:\xampp\htdocs “
</ VirtualHost>
<VirtualHost>
ServerName maestrophp.local
DocumentRoot “C:/xampp/htdocs/corsi/php/public_html“
</ VirtualHost>
The first section tells Apache to continue working as before when we write http: // localhost into the browser: Any request that arrives on port 80 the DocumentRoot is C: // xampp / htdocs associated with localhost. If we omit this section we will no longer see the pages deployed in the htdocs folder. The second section is the one that interests us, it is used to associate the maestrophp.local virtual host with the local folder C: / xampp / htdocs / courses / php / public_html. Indicating the ServerName = maestrophp.local directive means that when we type http: //maestrophp.local into the browser we want to access its DocumentRoot.
CONFIGURING THE HOST FILE
The above modification is sufficient to create a virtual host, in this case maestrophp.local . However, one thing remains to be done, the browser will not be able to reach the local Apache. The easiest way to force our machine (and only her) to reach the local Apache is via the hosts file, which on Windows should be here
C:\WINDOWS\system32\drivers\etc\hosts
we open the file with administrator permissions and insert the line
127.0.0.1 maestrophp.local
The instruction will tell Windows that any request to the host maestrophp.local must be resolved on the IP address 127.0.0.1, which is that of our local machine. That’s all. After restarting Apache, every time we write http: //maestrophp.local we will see the pages of the local Apache. The hosts file concerns the behavior of the operating system, not the applications installed on the machine (such as Apache).
CUSTOM ERROR MANAGEMENT
The errors generated by PHP can be fatal errors that terminate the script and errors that do not terminate the script, such as warnings, notices and so on. Errors can occur at compile time and at run time . Not all mistakes are manageable. If we import a non-existent script we will have a fatal error. For example, let’s echo a value, try to import a non-existent script and finally echo a second value:
echo 1;
require ‘abc.php’;
echo 2;
We display the value 1, then there is the fatal error that terminates the script and we do not display the value 2. If instead we make a syntax error, for example we omit the semicolon on the second echo, then we only display a fatal error being generated at compile time, therefore an error that prevents the code from running. We can define our own custom error handling system, and we do this by invoking a set_error_handler function. We have to pass two values to this function, the first concerns the function or callback that will handle the error, and as the second parameter the type of errors we want to handle.
set_error_handler (‘errorHandler‘, E_ALL );
If we go to the log file, we will see that the error is not written as we have handled it in the code. If we want to write the error in the log file we use the error_log() function;
Instead of using functions and procedural programming, we can use classes. However, we pay attention to the fact that not all errors are manageable in a personalized way, ie if for example after the echo we require a non-existent script we have a fatal error.
Leave A Comment