Before we start building anything with our fresh-installed version of FuelPHP, let's first take a look at some of the main aspects of the architecture. We will also cover some of the places where you should put your code for the project and then follow this with examples in the next chapter.
In this chapter, we will cover the following topics:
- Environments, constants, and configuration
- Apache configuration
- The FuelPHP bootstrap
- Models, views, and controllers
As any developer will tell you, it's never a good idea to edit files directly in the live production environment. To this end, FuelPHP has the notion of environments baked into its core. Environments allow for different configurations in each stage of the project's life cycle. FuelPHP supports four environment settings, which are as follows:
Fuel::DEVELOPMENT: This is the default environment setting and also where you'll startFuel::TEST: This is where you can run code with test dataFuel::STAGING: This is where you get client approval and acceptanceFuel::PRODUCTION: This is the live environment
If the environment is not set, the code will run in the development mode. Setting the environment can be done in several ways.
This section will teach you what probably is the easiest way of setting the environment variable, but only if you have access to the Apache configuration or virtual host file for the project domain. In the configuration or virtual host file, simply include the following code:
SetEnv FUEL_ENV production
If you don't have access to set the server configuration and want to get it, an alternative is to set the environment in the application bootstrap. This can be done in the bootstrap.php file located in fuel/app/, using the following code:
Fuel::$env = ( isset( $_SERVER['FUEL_ENV'] )? $_SERVER['FUEL_ENV'] : Fuel::PRODUCTION ;
Once you have your environment configured, it's worth thinking about the configuration for the project. FuelPHP follows a hierarchy when auto-loading configurations. This really comes in handy for database settings, meaning that your production connections can be more secure for the production and staging environments. In fact, the team doesn't even need access to the database credentials for them to work on the project. The configuration directory structure can resemble the following code:
app/
config/
db.php
development/
db.php
staging/
db.php
test/
bd.php
production/
db.php The settings in the environment directories are treated as more important than those in the higher directories giving fine-grained configuration controls with a fallback. This is great for testing and ensuring that each environment can be configured differently, for example, third-party API connection details.
The same hierarchy is followed for package configurations. In this case, the package configuration in the application configuration folder is treated with greater importance than the configuration in the package directory. This allows the default options in packages to be overridden with a configuration file in the app/config folder.