The Front Controller

The front controller is a design pattern; it is a section of code that all requests served by an application run through.

In the Symfony Skeleton, this role is taken by the index.php file in the public/ directory. This is the very first PHP script that is run when a request is processed.

The main purpose of the front controller is to create an instance of the Kernel (more on that in a second), make it handle the request and return the resulting response to the browser.

Because every request is routed through it, the front controller can be used to perform global initialization prior to setting up the kernel or to decorate the kernel with additional features. Examples include:

• Configuring the autoloader or adding additional autoloading mechanisms;
• Adding HTTP level caching by wrapping the kernel with an instance of HttpCache;
• Enabling the Debug component.

You can choose the front controller that's used by adding it in the URL, like:

1

http://localhost/index.php/some/path/...

As you can see, this URL contains the PHP script to be used as the front controller. You can use that to switch to a custom made front controller that is located in the public/ directory.

Technically, the bin/console script used when running Symfony on the command line is also a front controller, only that is not used for web, but for command line requests.

The Kernel Class

The Kernel is the core of Symfony. It is responsible for setting up all the bundles used by your application and providing them with the application's configuration. It then creates the service container before serving requests in its handle() method.

The kernel used in Symfony applications extends from Kernel and uses the MicroKernelTrait. The Kernel class leaves some methods from KernelInterface unimplemented and the MicroKernelTrait defines several abstract methods, so you must implement them all:

registerBundles()

It must return an array of all bundles needed to run the application.

configureRoutes()

It adds individual routes or collections of routes to the application (for example loading the routes defined in some config file).

configureContainer()

It loads the application configuration from config files or using the loadFromExtension() method and can also register new container parameters and services.

To fill these (small) blanks, your application needs to extend the Kernel class and use the MicroKernelTrait to implement these methods. Symfony provides by default that kernel in the src/Kernel.php file.

This class uses the name of the environment - which is passed to the Kernel's constructor method and is available via getEnvironment() - to decide which bundles to enable. The logic for that is in registerBundles().

You are free to create your own, alternative or additional Kernel variants. All you need is to adapt your (or add a new) front controller to make use of the new kernel.

1
2
3

# .env
# set it to 1 to enable the debug mode
APP_DEBUG=0

1
2
3
4
5

# Use the debug mode defined in the .env file
$ php bin/console command_name

# Ignore the .env file and enable the debug mode for this command
$ APP_DEBUG=1 php bin/console command_name

1
2
3

# config/packages/twig.yaml
twig:
    debug: '%kernel.debug%'

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:twig="http://symfony.com/schema/dic/twig"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/twig
        https://symfony.com/schema/dic/twig/twig-1.0.xsd">

    <twig:config debug="%kernel.debug%"/>

</container>

1
2
3
4
5
6
7

// config/packages/twig.php
use Symfony\Config\TwigConfig;

return static function (TwigConfig $twig) {
    // ...
    $twig->debug('%kernel.debug%');
};

The Environments

As mentioned above, the Kernel has to implement another method - configureContainer(). This method is responsible for loading the application's configuration from the right environment.

Configuration environments allow to execute the same code using different configuration. Symfony provides three environments by default called dev, prod and test.

More technically, these names are nothing more than strings passed from the front controller to the Kernel's constructor. This name can then be used in the configureContainer() method to decide which configuration files to load.

Symfony's default Kernel class implements this method by loading first the config files found on config/packages/* and then, the files found on config/packages/ENVIRONMENT_NAME/. You are free to implement this method differently if you need a more sophisticated way of loading your configuration.

1
2
3
4
5
6

your-project/
├─ var/
│  ├─ cache/
│  │  ├─ dev/   # cache directory for the *dev* environment
│  │  └─ prod/  # cache directory for the *prod* environment
│  ├─ ...