Skip to content
  • About
    • What is Symfony?
    • Community
    • News
    • Contributing
    • Support
  • Documentation
    • Symfony Docs
    • Symfony Book
    • Screencasts
    • Symfony Bundles
    • Symfony Cloud
    • Training
  • Services
    • SensioLabs Professional services to help you with Symfony
    • Platform.sh for Symfony Best platform to deploy Symfony apps
    • SymfonyInsight Automatic quality checks for your apps
    • Symfony Certification Prove your knowledge and boost your career
    • Blackfire Profile and monitor performance of your apps
  • Other
  • Blog
  • Download
sponsored by SensioLabs
  1. Home
  2. Documentation
  3. Configuration
  4. Understanding how the Front Controller, Kernel and Environments Work together
  • Documentation
  • Book
  • Reference
  • Bundles
  • Cloud

Table of Contents

  • The Front Controller
  • The Kernel Class
  • The Environments

Understanding how the Front Controller, Kernel and Environments Work together

Edit this page

Warning: You are browsing the documentation for Symfony 3.0, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

Understanding how the Front Controller, Kernel and Environments Work together

The section How to Master and Create new Environments explained the basics on how Symfony uses environments to run your application with different configuration settings. This section will explain a bit more in-depth what happens when your application is bootstrapped. To hook into this process, you need to understand three parts that work together:

  • The Front Controller
  • The Kernel Class
  • The Environments

Note

Usually, you will not need to define your own front controller or AppKernel class as the Symfony Standard Edition provides sensible default implementations.

This documentation section is provided to explain what is going on behind the scenes.

The Front Controller

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

In the Symfony Standard Edition, this role is taken by the app.php and app_dev.php files in the web/ directory. These are the very first PHP scripts executed when a request is processed.

The main purpose of the front controller is to create an instance of the AppKernel (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 AppCache;
  • Enabling (or skipping) the ClassCache;
  • Enabling the Debug Component.

The front controller can be chosen by requesting URLs like:

1
http://localhost/app_dev.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 easily switch the front controller or use a custom one by placing it in the web/ directory (e.g. app_cache.php).

When using Apache and the RewriteRule shipped with the Symfony Standard Edition, you can omit the filename from the URL and the RewriteRule will use app.php as the default one.

Note

Pretty much every other web server should be able to achieve a behavior similar to that of the RewriteRule described above. Check your server documentation for details or see Configuring a Web Server.

Note

Make sure you appropriately secure your front controllers against unauthorized access. For example, you don't want to make a debugging environment available to arbitrary users in your production environment.

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 that make up your application and providing them with the application's configuration. It then creates the service container before serving requests in its handle() method.

There are two methods declared in the KernelInterface that are left unimplemented in Kernel and thus serve as template methods:

registerBundles()
It must return an array of all bundles needed to run the application.
registerContainerConfiguration()
It loads the application configuration.

To fill these (small) blanks, your application needs to subclass the Kernel and implement these methods. The resulting class is conventionally called the AppKernel.

Again, the Symfony Standard Edition provides an AppKernel in the app/ directory. 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 create. The logic for that is in registerBundles(), a method meant to be extended by you when you start adding bundles to your application.

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

Note

The name and location of the AppKernel is not fixed. When putting multiple Kernels into a single application, it might therefore make sense to add additional sub-directories, for example app/admin/AdminKernel.php and app/api/ApiKernel.php. All that matters is that your front controller is able to create an instance of the appropriate kernel.

Having different AppKernels might be useful to enable different front controllers (on potentially different servers) to run parts of your application independently (for example, the admin UI, the front-end UI and database migrations).

Note

There's a lot more the AppKernel can be used for, for example overriding the default directory structure. But odds are high that you don't need to change things like this on the fly by having several AppKernel implementations.

The Environments

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

Environments have been covered extensively in the previous chapter, and you probably remember that the Symfony Standard Edition comes with three of them - dev, prod and test.

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

The Symfony Standard Edition's AppKernel class implements this method by simply loading the app/config/config_*environment*.yml file. You are, of course, free to implement this method differently if you need a more sophisticated way of loading your configuration.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version
    We stand with Ukraine.
    Version:
    Symfony Code Performance Profiling

    Symfony Code Performance Profiling

    Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).

    Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).

    Symfony footer

    ↓ Our footer now uses the colors of the Ukrainian flag because Symfony stands with the people of Ukraine.

    Avatar of AmsTaFF, a Symfony contributor

    Thanks AmsTaFF (@amstaff) for being a Symfony contributor

    1 commit • 6 lines changed

    View all contributors that help us make Symfony

    Become a Symfony contributor

    Be an active part of the community and contribute ideas, code and bug fixes. Both experts and newcomers are welcome.

    Learn how to contribute

    Symfony™ is a trademark of Symfony SAS. All rights reserved.

    • What is Symfony?

      • Symfony at a Glance
      • Symfony Components
      • Case Studies
      • Symfony Releases
      • Security Policy
      • Logo & Screenshots
      • Trademark & Licenses
      • symfony1 Legacy
    • Learn Symfony

      • Symfony Docs
      • Symfony Book
      • Reference
      • Bundles
      • Best Practices
      • Training
      • eLearning Platform
      • Certification
    • Screencasts

      • Learn Symfony
      • Learn PHP
      • Learn JavaScript
      • Learn Drupal
      • Learn RESTful APIs
    • Community

      • SymfonyConnect
      • Support
      • How to be Involved
      • Code of Conduct
      • Events & Meetups
      • Projects using Symfony
      • Downloads Stats
      • Contributors
      • Backers
    • Blog

      • Events & Meetups
      • A week of symfony
      • Case studies
      • Cloud
      • Community
      • Conferences
      • Diversity
      • Documentation
      • Living on the edge
      • Releases
      • Security Advisories
      • SymfonyInsight
      • Twig
      • SensioLabs
    • Services

      • SensioLabs services
      • Train developers
      • Manage your project quality
      • Improve your project performance
      • Host Symfony projects

      Deployed on

    Follow Symfony