If you would prefer not to use curl, or would prefer to just clone the FuelPHP repository in the command line, navigate to the folder where you would like the files to sit. For example:

$ cd /Users/ross/Sites
$ git clone --recursive git://github.com/fuel/fuel.git <project name>

This will create a folder called <project name> in your web server root. It will contain all the necessary FuelPHP files, including all the core packages.

$ php oil refine install
    Made writable: APPPATH/cache
    Made writable: APPPATH/logs
    Made writable: APPPATH/tmp
    Made writable: APPPATH/config

Now that you have installed FuelPHP, it's really easy to set up a new project. First, you will need to navigate to the folder where you would like to work from, for example, the Sites folder on Mac OS X. After this, run the following command:

php oil create <project name>

Then again, run:

$ cd ~/Sites/
$ php oil create book

This will install the core files and packages required to run FuelPHP. It will also set up Git submodules within the project. These can sometimes be tricky to work with, but FuelPHP uses them in an extremely versatile and powerful way. With submodules, you have fine-grained control over the versions of the packages you're using on the project. It also makes it really easy to upgrade or install security updates.

The structure created by FuelPHP is fairly straightforward:

/
   fuel/
      app/
      core/
      packages/
   public/
      .htaccess
      assets/
      index.php
   oil

Files like CSS and JavaScript are placed in the assets folder in the public directory. Once you have installed some packages, the majority of the changes you make for your project will take place in the fuel/app folder. We will run through these with examples in the next few chapters.

Submodules are a great way to work with multiple repositories in the project in a controlled manner. For example, it is possible to upgrade a version of the core FuelPHP framework while keeping other third-party packages on the old version. This makes it easier to test new functionality to ensure that it doesn't affect your project, or to highlight changes that you may need to make. In this section, we will run through some of the basics of using submodules, but if you would like to have more information I'd recommend looking at the Submodules section of the Git manual available at http://git-scm.com/book/en/Git-Tools-Submodules.

If you want to see which submodules are currently set for your project, navigate to the root of the project and then run the git submodule command, as shown:

$ cd ~/Sites/book
$ git submodule

As you can see, there are six submodules set up and used for each FuelPHP project.

If you would like to check what other versions of submodules are available, navigate to the folder for the submodule and then run the git branch -r command, as shown:

$ cd fuel/core
$ git branch -r

We can then copy the code from one of the other branches to test new features, or to roll back to a previous version of the code. For example, let's see what happens when we use the development version of FuelPHP:

$ git checkout origin/1.7/develop

Each submodule acts like its own repository and doesn't take into account the main project repository. If you want the main project to take into account the submodule changes, simply commit all the changes to the submodule, then navigate to the main project folder and commit the changes to the project repository, as shown:

$ cd ~/Sites/book
$ git status
$ git add fuel/core
$ git commit -m 'Upgrading Fuel Core to 1.7/develop'

When the project is set up, the Git settings will want to send the code to the FuelPHP repository. So, the first thing to do is to change this so that it goes to your project. We will be demonstrating this using GitHub, which is the same place where FuelPHP is stored.

First, create an account on GitHub (https://github.com/new), and then follow the instructions to create a repository. Once you have created the repository, copy the repository address, for example, [email protected]:digitales/Chapter2.git; you will need this shortly.

Once you have created your repository and copied the repository address, it's time to go back to your terminal. Navigate to your project directory in your terminal and then add a remote to the repository, for example:

$ cd ~/Sites/book
$ git remote rm origin 
$ git remote add origin [email protected]:digitales/Chapter2.git
$ git pull origin
$ git push origin master

Now that we've updated the origin, it's time to delve into a little about submodules, followed by configuration and some basics for the production environment configuration.

With more recent versions of FuelPHP, the Composer package manager is used to dynamically pull dependencies from Packagist, Github, or from a custom defined location. It's controlled using the composer.json file, which you will find in the root folder of your project's FuelPHP installation.

Normally, you'd need to manually install Composer, but FuelPHP includes the composer.phar library so that you can run Composer directly:

$ php composer.phar self-update
$ php composer.phar update

FuelPHP works on a configuration over convention method, with best practices and guidelines to follow. All application- or project-specific code is stored in the app/config folder with the main configuration file consisting of config.php. It is worth mentioning that you can pick and choose which configurations to override. Any unspecified keys or values will be loaded from the core configurations instead. This means that any changes to the default configurations will not be lost when upgrading versions of FuelPHP.

When you install FuelPHP, it defaults to thinking that it is in a development environment, but this can be changed quickly by setting the environment.

This can either be done in the virtual host (or similar) for the domain, or it can be done via the .htaccess file in the public folder for the application, using the following code:

Set FUEL_ENV production

By default, the environment will be set to a development environment in both the applications and in the command-line tasks. Running command-line tasks in the production environment will be covered in later chapters in this book.

Migrations are a great way of ensuring that the database is consistent in different environments, or between team members. It provides a systematic way of updating the datastore structure. Gone are the days of manually running SQL statements on a database and then wondering if the correct database structure has been updated. At any point of developing a site, the database can be changed moving forward or rolled back to an older version of the database structure.

Examples of migrations will form part of the project later in this book.