Controller

A controller is a PHP function you create that reads information from the Request object and creates and returns a Response object. The response could be an HTML page, JSON, XML, a file download, a redirect, a 404 error or anything else. The controller runs whatever arbitrary logic your application needs to render the content of a page.

Tip

If you haven't already created your first working page, check out /page_creation and then come back!

A Basic Controller

While a controller can be any PHP callable (function, method on an object, or a Closure), a controller is usually a method inside a controller class:

// src/Controller/LuckyController.php
namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class LuckyController
{
    #[Route('/lucky/number/{max}', name: 'app_lucky_number')]
    public function number(int $max): Response
    {
        $number = random_int(0, $max);

        return new Response(
            '<html><body>Lucky number: '.$number.'</body></html>'
        );
    }
}

The controller is the number() method, which lives inside the controller class LuckyController.

This controller is pretty straightforward:

line 2: Symfony takes advantage of PHP's namespace functionality to namespace the entire controller class.
line 4: Symfony again takes advantage of PHP's namespace functionality: the use keyword imports the Response class, which the controller must return.
line 7: The class can technically be called anything, but it's suffixed with Controller by convention.
line 10: The action method is allowed to have a $max argument thanks to the {max} wildcard in the route </routing>.
line 14: The controller creates and returns a Response object.

Mapping a URL to a Controller

In order to view the result of this controller, you need to map a URL to it via a route. This was done above with the #[Route('/lucky/number/{max}')] route attribute <attribute-routes>.

To see your page, go to this URL in your browser: http://localhost:8000/lucky/number/100

For more information on routing, see /routing.

The Base Controller Class & Services

To aid development, Symfony comes with an optional base controller class called Symfony\\Bundle\\FrameworkBundle\\Controller\\AbstractController. It can be extended to gain access to helper methods.

Add the use statement atop your controller class and then modify LuckyController to extend it:

// src/Controller/LuckyController.php
namespace App\Controller;

use SymfonyBundleFrameworkBundleControllerAbstractController;

class LuckyController

class LuckyController extends AbstractController { // ... }

That's it! You now have access to methods like $this->render() <controller-rendering-templates> and many others that you'll learn about next.

Generating URLs

The Symfony\\Bundle\\FrameworkBundle\\Controller\\AbstractController::generateUrl method is just a helper method that generates the URL for a given route:

$url = $this->generateUrl('app_lucky_number', ['max' => 10]);

Redirecting

If you want to redirect the user to another page, use the redirectToRoute() and redirect() methods:

use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Response;

// ...
public function index(): RedirectResponse
{
    // redirects to the "homepage" route
    return $this->redirectToRoute('homepage');

    // redirectToRoute is a shortcut for:
    // return new RedirectResponse($this->generateUrl('homepage'));

    // does a permanent HTTP 301 redirect
    return $this->redirectToRoute('homepage', [], 301);
    // if you prefer, you can use PHP constants instead of hardcoded numbers
    return $this->redirectToRoute('homepage', [], Response::HTTP_MOVED_PERMANENTLY);

    // redirect to a route with parameters
    return $this->redirectToRoute('app_lucky_number', ['max' => 10]);

    // redirects to a route and maintains the original query string parameters
    return $this->redirectToRoute('blog_show', $request->query->all());

    // redirects to the current route (e.g. for Post/Redirect/Get pattern):
    return $this->redirectToRoute($request->attributes->get('_route'));

    // redirects externally
    return $this->redirect('http://symfony.com/doc');
}

Danger

The redirect() method does not check its destination in any way. If you redirect to a URL provided by end-users, your application may be open to the unvalidated redirects security vulnerability.

Rendering Templates

If you're serving HTML, you'll want to render a template. The render() method renders a template and puts that content into a Response object for you:

// renders templates/lucky/number.html.twig
return $this->render('lucky/number.html.twig', ['number' => $number]);

Templating and Twig are explained more in the Creating and Using Templates article </templates>.

Fetching Services

Symfony comes packed with a lot of useful classes and functionalities, called services </service_container>. These are used for rendering templates, sending emails, querying the database and any other "work" you can think of.

If you need a service in a controller, type-hint an argument with its class (or interface) name. Symfony will automatically pass you the service you need:

use Psr\Log\LoggerInterface;
use Symfony\Component\HttpFoundation\Response;
// ...

#[Route('/lucky/number/{max}')]
public function number(int $max, LoggerInterface $logger): Response
{
    $logger->info('We are logging!');
    // ...
}

Awesome!

What other services can you type-hint? To see them, use the debug:autowiring console command:

$ php bin/console debug:autowiring

Tip

If you need control over the exact value of an argument, or require a parameter, you can use the #[Autowire] attribute:

// ...
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\Attribute\Autowire;
use Symfony\Component\HttpFoundation\Response;

class LuckyController extends AbstractController
{
    public function number(
        int $max,

        // inject a specific logger service
        #[Autowire(service: 'monolog.logger.request')]
        LoggerInterface $logger,

        // or inject parameter values
        #[Autowire('%kernel.project_dir%')]
        string $projectDir
    ): Response
    {
        $logger->info('We are logging!');
        // ...
    }
}

You can read more about this attribute in autowire-attribute.

Like with all services, you can also use regular constructor injection <services-constructor-injection> in your controllers.

For more information about services, see the /service_container article.

Generating Controllers

To save time, you can install Symfony Maker and tell Symfony to generate a new controller class:

$ php bin/console make:controller BrandNewController

created: src/Controller/BrandNewController.php
created: templates/brandnew/index.html.twig

If you want to generate an entire CRUD from a Doctrine entity </doctrine>, use:

$ php bin/console make:crud Product

created: src/Controller/ProductController.php
created: src/Form/ProductType.php
created: templates/product/_delete_form.html.twig
created: templates/product/_form.html.twig
created: templates/product/edit.html.twig
created: templates/product/index.html.twig
created: templates/product/new.html.twig
created: templates/product/show.html.twig

Managing Errors and 404 Pages

When things are not found, you should return a 404 response. To do this, throw a special type of exception:

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

// ...
public function index(): Response
{
    // retrieve the object from database
    $product = ...;
    if (!$product) {
        throw $this->createNotFoundException('The product does not exist');

        // the above is just a shortcut for:
        // throw new NotFoundHttpException('The product does not exist');
    }

    return $this->render(/* ... */);
}

The Symfony\\Bundle\\FrameworkBundle\\Controller\\AbstractController::createNotFoundException method is just a shortcut to create a special Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException object, which ultimately triggers a 404 HTTP response inside Symfony.

If you throw an exception that extends or is an instance of Symfony\\Component\\HttpKernel\\Exception\\HttpException, Symfony will use the appropriate HTTP status code. Otherwise, the response will have a 500 HTTP status code:

// this exception ultimately generates a 500 status error
throw new \Exception('Something went wrong!');

In every case, an error page is shown to the end user and a full debug error page is shown to the developer (i.e. when you're in "Debug" mode - see page-creation-environments).

To customize the error page that's shown to the user, see the /controller/error_pages article.

The Request object as a Controller Argument

What if you need to read query parameters, grab a request header or get access to an uploaded file? That information is stored in Symfony's Request object. To access it in your controller, add it as an argument and type-hint it with the Request class:

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
// ...

public function index(Request $request): Response
{
    $page = $request->query->get('page', 1);

    // ...
}

Keep reading <request-object-info> for more information about using the Request object.

Automatic Mapping Of The Request

It is possible to automatically map request's payload and/or query parameters to your controller's action arguments with attributes.

Mapping Query Parameters Individually

Let's say a user sends you a request with the following query string: https://example.com/dashboard?firstName=John&lastName=Smith&age=27. Thanks to the Symfony\\Component\\HttpKernel\\Attribute\\MapQueryParameter attribute, arguments of your controller's action can be automatically fulfilled:

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryParameter;

// ...

public function dashboard(
    #[MapQueryParameter] string $firstName,
    #[MapQueryParameter] string $lastName,
    #[MapQueryParameter] int $age,
): Response
{
    // ...
}

#[MapQueryParameter] can take an optional argument called filter. You can use the Validate Filters constants defined in PHP:

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryParameter;

// ...

public function dashboard(
    #[MapQueryParameter(filter: \FILTER_VALIDATE_REGEXP, options: ['regexp' => '/^\w+$/'])] string $firstName,
    #[MapQueryParameter] string $lastName,
    #[MapQueryParameter(filter: \FILTER_VALIDATE_INT)] int $age,
): Response
{
    // ...
}

Mapping The Whole Query String

Another possibility is to map the entire query string into an object that will hold available query parameters. Let's say you declare the following DTO with its optional validation constraints:

namespace App\Model;

use Symfony\Component\Validator\Constraints as Assert;

class UserDTO
{
    public function __construct(
        #[Assert\NotBlank]
        public string $firstName,

        #[Assert\NotBlank]
        public string $lastName,

        #[Assert\GreaterThan(18)]
        public int $age,
    ) {
    }
}

You can then use the Symfony\\Component\\HttpKernel\\Attribute\\MapQueryString attribute in your controller:

use App\Model\UserDTO;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryString;

// ...

public function dashboard(
    #[MapQueryString] UserDTO $userDto
): Response
{
    // ...
}

You can customize the validation groups used during the mapping and also the HTTP status to return if the validation fails:

use Symfony\Component\HttpFoundation\Response;

// ...

public function dashboard(
    #[MapQueryString(
        validationGroups: ['strict', 'edit'],
        validationFailedStatusCode: Response::HTTP_UNPROCESSABLE_ENTITY
    )] UserDTO $userDto
): Response
{
    // ...
}

The default status code returned if the validation fails is 404.

If you need a valid DTO even when the request query string is empty, set a default value for your controller arguments:

use App\Model\UserDTO;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryString;

// ...

public function dashboard(
    #[MapQueryString] UserDTO $userDto = new UserDTO()
): Response
{
    // ...
}

Mapping Request Payload

When creating an API and dealing with other HTTP methods than GET (like POST or PUT), user's data are not stored in the query string but directly in the request payload, like this:

{
    "firstName": "John",
    "lastName": "Smith",
    "age": 28
}

In this case, it is also possible to directly map this payload to your DTO by using the Symfony\\Component\\HttpKernel\\Attribute\\MapRequestPayload attribute:

use App\Model\UserDTO;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapRequestPayload;

// ...

public function dashboard(
    #[MapRequestPayload] UserDTO $userDto
): Response
{
    // ...
}

This attribute allows you to customize the serialization context as well as the class responsible of doing the mapping between the request and your DTO:

public function dashboard(
    #[MapRequestPayload(
        serializationContext: ['...'],
        resolver: App\Resolver\UserDtoResolver
    )]
    UserDTO $userDto
): Response
{
    // ...
}

You can also customize the validation groups used, the status code to return if the validation fails as well as supported payload formats:

use Symfony\Component\HttpFoundation\Response;

// ...

public function dashboard(
    #[MapRequestPayload(
        acceptFormat: 'json',
        validationGroups: ['strict', 'read'],
        validationFailedStatusCode: Response::HTTP_NOT_FOUND
    )] UserDTO $userDto
): Response
{
    // ...
}

The default status code returned if the validation fails is 422.

Tip

If you build a JSON API, make sure to declare your route as using the JSON format <routing-format-parameter>. This will make the error handling output a JSON response in case of validation errors, rather than an HTML page:

#[Route('/dashboard', name: 'dashboard', format: 'json')]

Make sure to install phpstan/phpdoc-parser and phpdocumentor/type-resolver if you want to map a nested array of specific DTOs:

public function dashboard(
    #[MapRequestPayload()] EmployeesDTO $employeesDto
): Response
{
    // ...
}

final class EmployeesDTO
{
    /**
     * @param UserDTO[] $users
     */
    public function __construct(
        public readonly array $users = []
    ) {}
}

Instead of returning an array of DTO objects, you can tell Symfony to transform each DTO object into an array and return something like this:

[
    {
        "firstName": "John",
        "lastName": "Smith",
        "age": 28
    },
    {
        "firstName": "Jane",
        "lastName": "Doe",
        "age": 30
    }
]

To do so, map the parameter as an array and configure the type of each element using the type option of the attribute:

public function dashboard(
    #[MapRequestPayload(type: UserDTO::class)] array $users
): Response
{
    // ...
}

7.1

The type option of #[MapRequestPayload] was introduced in Symfony 7.1.

Mapping Uploaded Files

Symfony provides an attribute called #[MapUploadedFile] to map one or more UploadedFile objects to controller arguments:

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\File\UploadedFile;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapUploadedFile;
use Symfony\Component\Routing\Attribute\Route;

class UserController extends AbstractController
{
    #[Route('/user/picture', methods: ['PUT'])]
    public function changePicture(
        #[MapUploadedFile] UploadedFile $picture,
    ): Response {
        // ...
    }
}

In this example, the associated argument resolver <controller/value_resolver> fetches the UploadedFile based on the argument name ($picture). If no file is submitted, an HttpException is thrown. You can change this by making the controller argument nullable:

#[MapUploadedFile]
?UploadedFile $document

The #[MapUploadedFile] attribute also allows to pass a list of constraints to apply to the uploaded file:

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\File\UploadedFile;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapUploadedFile;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Validator\Constraints as Assert;

class UserController extends AbstractController
{
    #[Route('/user/picture', methods: ['PUT'])]
    public function changePicture(
        #[MapUploadedFile([
            new Assert\File(mimeTypes: ['image/png', 'image/jpeg']),
            new Assert\Image(maxWidth: 3840, maxHeight: 2160),
        ])]
        UploadedFile $picture,
    ): Response {
        // ...
    }
}

The validation constraints are checked before injecting the UploadedFile into the controller argument. If there's a constraint violation, an HttpException is thrown and the controller's action is not executed.

If you need to upload a collection of files, map them to an array or a variadic argument. The given constraint will be applied to all files and if any of them fails, an HttpException is thrown:

#[MapUploadedFile(new Assert\File(mimeTypes: ['application/pdf']))]
array $documents

#[MapUploadedFile(new Assert\File(mimeTypes: ['application/pdf']))]
UploadedFile ...$documents

Use the name option to rename the uploaded file to a custom value:

#[MapUploadedFile(name: 'something-else')]
UploadedFile $document

In addition, you can change the status code of the HTTP exception thrown when there are constraint violations:

#[MapUploadedFile(
    constraints: new Assert\File(maxSize: '2M'),
    validationFailedStatusCode: Response::HTTP_REQUEST_ENTITY_TOO_LARGE
)]
UploadedFile $document

7.1

The #[MapUploadedFile] attribute was introduced in Symfony 7.1.

Managing the Session

You can store special messages, called "flash" messages, on the user's session. By design, flash messages are meant to be used exactly once: they vanish from the session automatically as soon as you retrieve them. This feature makes "flash" messages particularly great for storing user notifications.

For example, imagine you're processing a form </forms> submission:

.. configuration-block::

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
// ...

public function update(Request $request): Response
{
    // ...

    if ($form->isSubmitted() && $form->isValid()) {
        // do some sort of processing

        $this->addFlash(
            'notice',
            'Your changes were saved!'
        );
        // $this->addFlash() is equivalent to $request->getSession()->getFlashBag()->add()

        return $this->redirectToRoute(/* ... */);
    }

    return $this->render(/* ... */);
}

Reading <session-intro> for more information about using Sessions.

The Request and Response Object

As mentioned earlier <controller-request-argument>, Symfony will pass the Request object to any controller argument that is type-hinted with the Request class:

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

public function index(Request $request): Response
{
    $request->isXmlHttpRequest(); // is it an Ajax request?

    $request->getPreferredLanguage(['en', 'fr']);

    // retrieves GET and POST variables respectively
    $request->query->get('page');
    $request->getPayload()->get('page');

    // retrieves SERVER variables
    $request->server->get('HTTP_HOST');

    // retrieves an instance of UploadedFile identified by foo
    $request->files->get('foo');

    // retrieves a COOKIE value
    $request->cookies->get('PHPSESSID');

    // retrieves an HTTP request header, with normalized, lowercase keys
    $request->headers->get('host');
    $request->headers->get('content-type');
}

The Request class has several public properties and methods that return any information you need about the request.

Like the Request, the Response object has a public headers property. This object is of the type Symfony\\Component\\HttpFoundation\\ResponseHeaderBag and provides methods for getting and setting response headers. The header names are normalized. As a result, the name Content-Type is equivalent to the name content-type or content_type.

In Symfony, a controller is required to return a Response object:

use Symfony\Component\HttpFoundation\Response;

// creates a simple Response with a 200 status code (the default)
$response = new Response('Hello '.$name, Response::HTTP_OK);

// creates a CSS-response with a 200 status code
$response = new Response('<style> ... </style>');
$response->headers->set('Content-Type', 'text/css');

To facilitate this, different response objects are included to address different response types. Some of these are mentioned below. To learn more about the Request and Response (and different Response classes), see the HttpFoundation component documentation <component-http-foundation-request>.

Accessing Configuration Values

To get the value of any configuration parameter <configuration-parameters> from a controller, use the getParameter() helper method:

// ...
public function index(): Response
{
    $contentsDir = $this->getParameter('kernel.project_dir').'/contents';
    // ...
}

Returning JSON Response

To return JSON from a controller, use the json() helper method. This returns a JsonResponse object that encodes the data automatically:

use Symfony\Component\HttpFoundation\JsonResponse;
// ...

public function index(): JsonResponse
{
    // returns '{"username":"jane.doe"}' and sets the proper Content-Type header
    return $this->json(['username' => 'jane.doe']);

    // the shortcut defines three optional arguments
    // return $this->json($data, $status = 200, $headers = [], $context = []);
}

If the serializer service </serializer> is enabled in your application, it will be used to serialize the data to JSON. Otherwise, the json_encode function is used.

Streaming File Responses

You can use the Symfony\\Bundle\\FrameworkBundle\\Controller\\AbstractController::file helper to serve a file from inside a controller:

use Symfony\Component\HttpFoundation\BinaryFileResponse;
// ...

public function download(): BinaryFileResponse
{
    // send the file contents and force the browser to download it
    return $this->file('/path/to/some_file.pdf');
}

The file() helper provides some arguments to configure its behavior:

use Symfony\Component\HttpFoundation\File\File;
use Symfony\Component\HttpFoundation\ResponseHeaderBag;
// ...

public function download(): BinaryFileResponse
{
    // load the file from the filesystem
    $file = new File('/path/to/some_file.pdf');

    return $this->file($file);

    // rename the downloaded file
    return $this->file($file, 'custom_name.pdf');

    // display the file contents in the browser instead of downloading it
    return $this->file('invoice_3241.pdf', 'my_invoice.pdf', ResponseHeaderBag::DISPOSITION_INLINE);
}

Sending Early Hints

Early hints tell the browser to start downloading some assets even before the application sends the response content. This improves perceived performance because the browser can prefetch resources that will be needed once the full response is finally sent. These resources are commonly Javascript or CSS files, but they can be any type of resource.

Note

In order to work, the SAPI you're using must support this feature, like FrankenPHP.

You can send early hints from your controller action thanks to the Symfony\\Bundle\\FrameworkBundle\\Controller\\AbstractController::sendEarlyHints method:

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\WebLink\Link;

class HomepageController extends AbstractController
{
    #[Route("/", name: "homepage")]
    public function index(): Response
    {
        $response = $this->sendEarlyHints([
            new Link(rel: 'preconnect', href: 'https://fonts.google.com'),
            (new Link(href: '/style.css'))->withAttribute('as', 'stylesheet'),
            (new Link(href: '/script.js'))->withAttribute('as', 'script'),
        ]);

        // prepare the contents of the response...

        return $this->render('homepage/index.html.twig', response: $response);
    }
}

Technically, Early Hints are an informational HTTP response with the status code 103. The sendEarlyHints() method creates a Response object with that status code and sends its headers immediately.

This way, browsers can start downloading the assets immediately; like the style.css and script.js files in the above example. The sendEarlyHints() method also returns the Response object, which you must use to create the full response sent from the controller action.

Final Thoughts

In Symfony, a controller is usually a class method which is used to accept requests, and return a Response object. When mapped with a URL, a controller becomes accessible and its response can be viewed.

To facilitate the development of controllers, Symfony provides an AbstractController. It can be used to extend the controller class allowing access to some frequently used utilities such as render() and redirectToRoute(). The AbstractController also provides the createNotFoundException() utility which is used to return a page not found response.

In other articles, you'll learn how to use specific services from inside your controller that will help you persist and fetch objects from a database, process form submissions, handle caching and more.

Keep Going!

Next, learn all about rendering templates with Twig </templates>.

Learn more about Controllers

controller/*

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

controller.rst

controller.rst

Controller

A Basic Controller

Mapping a URL to a Controller

The Base Controller Class & Services

Generating URLs

Redirecting

Rendering Templates

Fetching Services

Generating Controllers

Managing Errors and 404 Pages

The Request object as a Controller Argument

Automatic Mapping Of The Request

Mapping Query Parameters Individually

Mapping The Whole Query String

Mapping Request Payload

Mapping Uploaded Files

Managing the Session

The Request and Response Object

Accessing Configuration Values

Returning JSON Response

Streaming File Responses

Sending Early Hints

Final Thoughts

Keep Going!

Learn more about Controllers

Files

controller.rst

Latest commit

History

controller.rst

File metadata and controls

Controller

A Basic Controller

Mapping a URL to a Controller

The Base Controller Class & Services

Generating URLs

Redirecting

Rendering Templates

Fetching Services

Generating Controllers

Managing Errors and 404 Pages

The Request object as a Controller Argument

Automatic Mapping Of The Request

Mapping Query Parameters Individually

Mapping The Whole Query String

Mapping Request Payload

Mapping Uploaded Files

Managing the Session

The Request and Response Object

Accessing Configuration Values

Returning JSON Response

Streaming File Responses

Sending Early Hints

Final Thoughts

Keep Going!

Learn more about Controllers