Let's talk about development modes. In a typical real-world development of an application at a company, you will usually find three different modes that your application will run in.
These modes are development, staging, and production modes.
In smaller projects, you might find just development and production modes.
What does this mean exactly? Let's talk about each mode.
Development Mode - This basically means the code will be running on your local machine or on a server that is located in house on your intranet. This mode is not available on the internet. Basically, you are actively working on the application and writing code.
In development mode, you'll get to a point where the code works, looks clean, and is ready to be widely tested. This is when you push your code to staging.
Staging Mode - This is when your code is ready to be tested on a server that is an exact mirror of your production server. You might be using test data from the database, or a subset of real data from your live database.
You and your co-workers will then test new and updated features for bugs and defects.
Production Mode - This is when your code is finally done being tested in staging mode and pushed to production. Production is when your new or updated features are generally available to the entire internet and hosted on production servers with production data.
In the case of error handling, you either do or don't want to show errors in the browser. Let's walk through what and why.
In Development Mode, you want all errors available so you can see where and when something is going wrong. If something is erroring out, you want to see it immediately. This helps speed development. When in Development Mode you want errors to show in the browser.
In Staging Mode, you are trying to simulate your production environment on something that isn't generally available to the internet. In this case you don't want errors showing in the browser.
In Production Mode, your code is generally available to the internet. In this case you don't want errors showing in the browser.
Why don't you want your errors showing in the browser? Because it could lead to easier attacks on your application. Any information you give to an attacker makes it easier to attack your code. For example, in the first error output from above, the attacker now knows that the field stat does not exist and that you are using an order by clause. It's a very small piece of information, but an attacker can use that to determine their next steps.
What do you do instead of showing errors in the browser? You log to your system log. In PHP, you can do that with the syslog() function.
Let's show an example of using syslog():
<?php
syslog(LOG_DEBUG, "Here is a message that should show up in my system log");On Ubuntu Linux, if you type:
journalctl -fFeb 21 12:48:13 dev php[30585]: Here is a message that should show up in my system log
You can use different log types such as:
<?php
syslog(LOG_ERR, "Here is a message that should show up in my system log");And the message will be output in red.
Feb 21 12:48:13 dev php[30585]: Here is a message that should show up in my system log
You can see a list of different syslog types here:
https://www.php.net/manual/en/function.syslog.php
So, how do we put this together? How do we create an environment to handle the different dev, staging, and prod environments? We can use different methods, such as creating a config.php file, using environment variables, or just direcly manipulating the file itself.
For our examples, we'll create a configuration file, since that's probably the most clear example.