In the previous step of the project, we used doc root relative links to solve some of the problems of using PHP include files. But this presented a new problem. We hard-coded the 'my-new-site' folder into each of the links. This is duplicated in every link (about 10 places throughout the site). If we decided to change the name of the project folder from 'my-new-site' to something else, then the links would be broken and we'd have to go through the code and change each occurence of 'my-new-site' in the links. Programmers need to deal with changing environments in a flexible manner! In this step, we'll create a 'config' file and use variables that will allow us to migrate our site from one environment (server) to another without the headache of updating links all over the place.
Many types of applications make use of a config file (short for 'configuration'), which acts as a central location for settings that are used when the app is running. Other files in the app can 'include' this file to get the settings. Many of the settings in the config file provide information about the environment in which the app is running. For example, in the development environment, we would want to display all error messages to help us with debugging. But in a live environment, we never want to display error messages.
In this step, we'll create a config file that automatically detects the environment in which the app is running. It will then provide settings for a live envirnoment and a development environment.
Create a file in the includes folder and name it config.inc.php.
Add this code to the file.
First note that the IF statement detects the server name by using the PHP $_SERVER super global array. If the server name is 'localhost', then we set the PROJECT_DIR constant to '/my-new-site/' (this is the path to the folder that contains our project files, notice that it's a doc root relative path). The ELSE block of code sets the constant to "/", because when we migrate our new site to the live web server, we'll want the files placed directly into the doc root directory.
You may have noticed something that looks a bit strange in the config file, that it's missing the closing php delimiter (?>). If you create a PHP include file that consists of only PHP code (no HTML, CSS, or JavaScript), then you can avoid some strange issues by omitting the ?> at the end of the file (you can ask me about this in class if you are interested to learn more). We'll learn more about this when we discuss HTTP headers.
Note that as we continue to work on this project, we'll be adding quite a few settings to our config file (and some other code as well).
We want every page in our site to link to the config file so that every page has access to the settings in it. So we will individually link each page to config.inc.php, luckily we don't have too many pages to update at this point. You might be inclined to put the link to the config file in header.inc.php, since all of our pages are already linking to it. If we took this approach, we would only have to update header.inc.php by adding the link to config.inc.php. But it's better to put the link to the config file at the very top of every page. The reason for this is that we want to make the configuration settings available as soon as possible in every page. Often times, PHP pages have quite a bit of PHP code in them before any HTML tags, so by linking to the config file at the top of the page, before any other PHP code, the settings will be available to any code that comes after it.
Go ahead and link each page in the site to the config file by adding this line at the top of each page (just after the <?php). Don't forget about the blog home page, and make sure to adjust the path to config.inc.php by adding ../ at the beginning. Note that we are using the require_once(), instead of the require() function. The reason for using the require_once() function instead of just require() is that many files in our project may need to link to the config file. So if we happen to link to another include file in this page that also links to the config file, then it may be included more than once, which could cause problems. By using require_once() to link to a file, PHP will detect if the config file has already been included and make sure that it only happens once.
Now all of our pages will be able to make use of the PROJECT_DIR setting in the config file. And since all of our pages link to header.inc.php after linking to the config file, the header include file will also have access to the configuration settings. We'll start off by updating all the client-side links in the header.inc.php to make use of the PROJECT_DIR constant.
Open header.inc.php and update all the links (that is, links to CSS and JS as well as the links to other pages that are in the nav bar).
We will replace all occurences of /my-new-site/ with this:
<?php echo(PROJECT_DIR); ?>
The code in header.inc.php should look like this.
It might seem strange to sprinkle little bits of PHP code among the HTML tags, and some programmers refer to the mixture of code as spaghetti code. I actually struggled with this quite a bit when I was learning PHP. But I have since learned that this is exactly how PHP was intended to be used.
Take a look at your web pages in the browser. If you did things correctly, then you won't notice any differences in the browser. But we have taken a very important step by making the site more dynamic. The site now dynamically detects which environment it's running in and can automatically change the configuration settings accordingly.
Let's add one more setting in our config file. We'll add a constant called IMAGES_DIR and when we set it's value, we'll make use of PROJECT_DIR. Your config file should now look like this.
You could also add settings for other folders in the project (for example the 'js' and 'styles' folders), but we'll leave things as they are right now.
Open the home page for the site (index.php) in your editor and find the path to the image that is displayed inside the main tag so that it uses the IMAGES_DIR constant, like this.
Now, whenever you add a new image to a web page, you should try to make use of the IMAGES_DIR when setting up the link. If for some reason we needed to restructure our site files, it will be much easier to update the IMAGES_DIR value than to go through all the pages and update links to images manually.
