In the previous tutorial (Fat Free Framework – 3. Creating a configuration file) we learned about configuration files, and how to import them into our app. Let’s look into our main index.php:
<?php
require_once('vendor/autoload.php');
$f3 = Base::instance();
$f3->config('App/Config/setup.cfg');
$f3->route('GET /', 'Homepage->index');
$f3->run();
As you can see we have a route defined in there, which tells our app that when someone tries to access the homepage, it should serve the Homepage controller with its index() method.
By using the same steps, let us create another file in our App/Config directory named routes.cfg. By the way… the routes file can have almost any extension… i think… But in the Fat-Free Framework documentation we can see that the .cfg extension is used. In the file we will transfer the route from the index.php file like this:
[routes] GET /=Homepage->index
As you can probably see, when the homepage is accessed by the GET method, the app will try to access Homepage->index.
Now we return to our main index.php, remove the line that defines the route, and create a line that will import the routes from the routes configuration file:
<?php
require_once('vendor/autoload.php');
$f3 = Base::instance();
$f3->config('App/Config/setup.cfg');
$f3->config('App/Config/routes.cfg');
$f3->run();
Looks cleaner, doesn’t it?
As you can see we’ve defined the globals (in the previous tutorials) and the routes by using a “title” for them: [globals] and [routes]. These are predefined section names, and are important for the framework to see what goes where. If now section name is mentioned in the configuration file(s), the framework will assume you are referring to the global variables, so take care.
Related to how Fat-Free Framework handles URLs, the framework also has two more section names: [redirects] and [maps].
The [redirects] does exactly what you would have expected. It… redirects people that land on pages that you deem not worthy of their eyes. For example, an obsolete page can be redirected to another page. Let us try to do an example.
First let us create a controller named Contact.php inside our App/Controllers directory:
<?php
class Contact {
function index(){
echo 'hello from contact controller';
}
}
Now, after we’ve created the page, we need to route the url “/contact” to this controller->method. So, in routes.php we will define it:
[routes] GET /=Homepage->index GET /contact=Contact->index
And, now the magic. If we now visit oursite.com/contact… oups… nothing… Why? Because the server doesn’t know that it should send all requests to the main index.php file. So, let’s make a .htaccess file that we will put in the public directory:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php [L,QSA]
Now, if we visit again the page, we should be greeted by the contact controller.
Cool! All fine and well.
Now, assuming we had an old page (and we couldn’t simply route the contactus url to that controller…), we put the following at the bottom of our routes.cfg:
[routes] GET /=Homepage->index GET /contact=Contact->index [redirects] GET|HEAD /contactus=/contact
As you can see (if you visit oursite.com/contactus), we will be redirected to the contact url if you access.
The [maps] section allows you to map HTTP methods of an controller providing an alias for them. We’ll talk about them later.
Done.