Creating and Using Templates ¶

Twig Configuration ¶

Twig has several configuration options to define things like the format used to display numbers and dates, the template caching, etc. Read the Twig configuration reference to learn about them.

Template Naming ¶

Symfony recommends the following for template names:

• Use snake case for filenames and directories (e.g. blog_posts.html.twig, admin/default_theme/blog/index.html.twig, etc.);
  ファイル名とディレクトリにはスネーク ケースを使用します (例: blog_posts.html.twig,admin/default_theme/blog/index.html.twig など)。
• Define two extensions for filenames (e.g. index.html.twig or blog_posts.xml.twig) being the first extension (html, xml, etc.) the final format that the template will generate.
  ファイル名の 2 つの拡張子 (例: index.html.twig または blog_posts.xml.twig) を定義します。最初の拡張子 (html、xml など) は、テンプレートが生成する最終的な形式です。

Although templates usually generate HTML contents, they can generate any text-based format. That's why the two-extension convention simplifies the way templates are created and rendered for multiple formats.

Template Location ¶

Templates are stored by default in the templates/ directory. When a service or controller renders the product/index.html.twig template, they are actually referring to the <your-project>/templates/product/index.html.twig file.

The default templates directory is configurable with the twig.default_path option and you can add more template directories as explained later in this article.

Template Variables ¶

A common need for templates is to print the values stored in the templates passed from the controller or service. Variables usually store objects and arrays instead of strings, numbers and boolean values. That's why Twig provides quick access to complex PHP variables. Consider the following template:

1

<p>{{ user.name }} added this comment on {{ comment.publishedAt|date }}</p>

The user.name notation means that you want to display some information (name) stored in a variable (user). Is user an array or an object? Is name a property or a method? In Twig this doesn't matter.

When using the foo.bar notation, Twig tries to get the value of the variable in the following order:

1. $foo['bar'] (array and element);
   $foo['bar'] (配列と要素);
2. $foo->bar (object and public property);
   $foo->bar (オブジェクトとパブリック プロパティ);
3. $foo->bar() (object and public method);
   $foo->bar() (オブジェクトと公開メソッド);
4. $foo->getBar() (object and getter method);
   $foo->getBar() (オブジェクトと取得メソッド);
5. $foo->isBar() (object and isser method);
   $foo->isBar() (オブジェクトと isser メソッド);
6. $foo->hasBar() (object and hasser method);
   $foo->hasBar() (オブジェクトと hasser メソッド);
7. If none of the above exists, use null (or throw a Twig\Error\RuntimeError exception if the strict_variables option is enabled).
   上記のいずれも存在しない場合は、null を使用します (または、strict_variables オプションが有効になっている場合は Twig\Error\RuntimeErrorexception をスローします)。

This allows to evolve your application code without having to change the template code (you can start with array variables for the application proof of concept, then move to objects with methods, etc.)

Linking to Pages ¶

Instead of writing the link URLs by hand, use the path() function to generate URLs based on the routing configuration.

Later, if you want to modify the URL of a particular page, all you'll need to do is change the routing configuration: the templates will automatically generate the new URL.

Consider the following routing configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

// ...
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class BlogController extends AbstractController
{
    #[Route('/', name: 'blog_index')]
    public function index(): Response
    {
        // ...
    }

    #[Route('/article/{slug}', name: 'blog_post')]
    public function show(string $slug): Response
    {
        // ...
    }
}

1
2
3
4
5
6
7
8

# config/routes.yaml
blog_index:
    path:       /
    controller: App\Controller\BlogController::index

blog_post:
    path:       /article/{slug}
    controller: App\Controller\BlogController::show

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

<!-- config/routes.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<routes xmlns="http://symfony.com/schema/routing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/routing
        https://symfony.com/schema/routing/routing-1.0.xsd">

    <route id="blog_index"
        path="/"
        controller="App\Controller\BlogController::index"/>

    <route id="blog_post"
        path="/article/{slug}"
        controller="App\Controller\BlogController::show"/>
</routes>

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

// config/routes.php
use App\Controller\BlogController;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;

return function (RoutingConfigurator $routes) {
    $routes->add('blog_index', '/')
        ->controller([BlogController::class, 'index'])
    ;

    $routes->add('blog_post', '/articles/{slug}')
        ->controller([BlogController::class, 'show'])
    ;
};

Use the path() Twig function to link to these pages and pass the route name as the first argument and the route parameters as the optional second argument:

1
2
3
4
5
6
7
8
9
10
11

<a href="{{ path('blog_index') }}">Homepage</a>

{# ... #}

{% for post in blog_posts %}
    <h1>
        <a href="{{ path('blog_post', {slug: post.slug}) }}">{{ post.title }}</a>
    </h1>

    <p>{{ post.excerpt }}</p>
{% endfor %}

The path() function generates relative URLs. If you need to generate absolute URLs (for example when rendering templates for emails or RSS feeds), use the url() function, which takes the same arguments as path() (e.g. <a href="{{ url('blog_index') }}"> ... </a>).

Linking to CSS, JavaScript and Image Assets ¶

If a template needs to link to a static asset (e.g. an image), Symfony provides an asset() Twig function to help generate that URL. First, install the asset package:

1

$ composer require symfony/asset

You can now use the asset() function:

1
2
3
4
5
6
7
8

{# the image lives at "public/images/logo.png" #}
<img src="{{ asset('images/logo.png') }}" alt="Symfony!"/>

{# the CSS file lives at "public/css/blog.css" #}
<link href="{{ asset('css/blog.css') }}" rel="stylesheet"/>

{# the JS file lives at "public/bundles/acme/js/loader.js" #}
<script src="{{ asset('bundles/acme/js/loader.js') }}"></script>

The asset() function's main purpose is to make your application more portable. If your application lives at the root of your host (e.g. https://example.com), then the rendered path should be /images/logo.png. But if your application lives in a subdirectory (e.g. https://example.com/my_app), each asset path should render with the subdirectory (e.g. /my_app/images/logo.png). The asset() function takes care of this by determining how your application is being used and generating the correct paths accordingly.

If you need absolute URLs for assets, use the absolute_url() Twig function as follows:

1
2
3

<img src="{{ absolute_url(asset('images/logo.png')) }}" alt="Symfony!"/>

<link rel="shortcut icon" href="{{ absolute_url('favicon.png') }}">

Build, Versioning & More Advanced CSS, JavaScript and Image Handling ¶

For help building, versioning and minifying your JavaScript and CSS assets in a modern way, read about Symfony's Webpack Encore.

The App Global Variable ¶

Symfony creates a context object that is injected into every Twig template automatically as a variable called app. It provides access to some application information:

1
2
3
4
5

<p>Username: {{ app.user.username ?? 'Anonymous user' }}</p>
{% if app.debug %}
    <p>Request method: {{ app.request.method }}</p>
    <p>Application Environment: {{ app.environment }}</p>
{% endif %}

The app variable (which is an instance of AppVariable) gives you access to these variables:

app.user

The current user object or null if the user is not authenticated.

現在のユーザー オブジェクト、またはユーザーが認証されていない場合は null。

app.request

The Request object that stores the current request data (depending on your application, this can be a sub-request or a regular request).

現在のリクエスト データを格納する Request オブジェクト (アプリケーションによっては、これがサブ リクエスタまたは通常のリクエストになる場合があります)。

app.session

The Session object that represents the current user's session or null if there is none.

現在のユーザーのセッションを表す Session オブジェクト、または存在しない場合は null。

app.flashes

An array of all the flash messages stored in the session. You can also get only the messages of some type (e.g. app.flashes('notice')).

セッションに保存されたすべてのフラッシュ メッセージの配列。特定のタイプのメッセージのみを取得することもできます (例: app.flashes('notice'))。

app.environment

The name of the current configuration environment (dev, prod, etc).

現在の構成環境の名前 (dev、prod など)。

app.debug

True if in debug mode. False otherwise.

デバッグ モードの場合は true。それ以外の場合は偽。

app.token

A TokenInterface object representing the security token.

セキュリティ トークンを表す TokenInterface オブジェクト。

app.current_route

The name of the route associated with the current request or null if no request is available (equivalent to app.request.attributes.get('_route'))

現在のリクエストに関連付けられたルートの名前、または norequest が利用可能な場合は null (app.request.attributes.get('_route') と同等)

app.current_route_parameters

An array with the parameters passed to the route of the current request or an empty array if no request is available (equivalent to app.request.attributes.get('_route_params'))

現在のリクエストのルートに渡されたパラメータを含む配列、またはリクエストが利用できない場合は空の配列 (app.request.attributes.get('_route_params') と同等)

In addition to the global app variable injected by Symfony, you can also inject variables automatically to all Twig templates.

Rendering a Template in Controllers ¶

If your controller extends from the AbstractController, use the render() helper:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

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

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;

class ProductController extends AbstractController
{
    public function index(): Response
    {
        // ...

        // the `render()` method returns a `Response` object with the
        // contents created by the template
        return $this->render('product/index.html.twig', [
            'category' => '...',
            'promotions' => ['...', '...'],
        ]);

        // the `renderView()` method only returns the contents created by the
        // template, so you can use those contents later in a `Response` object
        $contents = $this->renderView('product/index.html.twig', [
            'category' => '...',
            'promotions' => ['...', '...'],
        ]);

        return new Response($contents);
    }
}

If your controller does not extend from AbstractController, you'll need to fetch services in your controller and use the render() method of the twig service.

Another option is to use the #[Template()] attribute on the controller method to define the template to render:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

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

use Symfony\Bridge\Twig\Attribute\Template;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;

class ProductController extends AbstractController
{
    #[Template('product/index.html.twig')]
    public function index()
    {
        // ...

        // when using the #[Template()] attribute, you only need to return
        // an array with the parameters to pass to the template (the attribute
        // is the one which will create and return the Response object).
        return [
            'category' => '...',
            'promotions' => ['...', '...'],
        ];
    }
}

Rendering a Template in Services ¶

Inject the twig Symfony service into your own services and use its render() method. When using service autowiring you only need to add an argument in the service constructor and type-hint it with the Environment class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// src/Service/SomeService.php
namespace App\Service;

use Twig\Environment;

class SomeService
{
    private $twig;

    public function __construct(Environment $twig)
    {
        $this->twig = $twig;
    }

    public function someMethod()
    {
        // ...

        $htmlContents = $this->twig->render('product/index.html.twig', [
            'category' => '...',
            'promotions' => ['...', '...'],
        ]);
    }
}

Rendering a Template in Emails ¶

Read the docs about the mailer and Twig integration.

Rendering a Template Directly from a Route ¶

Although templates are usually rendered in controllers and services, you can render static pages that don't need any variables directly from the route definition. Use the special TemplateController provided by Symfony:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# config/routes.yaml
acme_privacy:
    path:          /privacy
    controller:    Symfony\Bundle\FrameworkBundle\Controller\TemplateController
    defaults:
        # the path of the template to render
        template:  'static/privacy.html.twig'

        # the response status code (default: 200)
        statusCode: 200

        # special options defined by Symfony to set the page cache
        maxAge:    86400
        sharedAge: 86400

        # whether or not caching should apply for client caches only
        private: true

        # optionally you can define some arguments passed to the template
        context:
            site_name: 'ACME'
            theme: 'dark'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<!-- config/routes.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<routes xmlns="http://symfony.com/schema/routing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/routing https://symfony.com/schema/routing/routing-1.0.xsd">

    <route id="acme_privacy"
        path="/privacy"
        controller="Symfony\Bundle\FrameworkBundle\Controller\TemplateController">
        <!-- the path of the template to render -->
        <default key="template">static/privacy.html.twig</default>

        <!-- the response status code (default: 200) -->
        <default key="statusCode">200</default>

        <!-- special options defined by Symfony to set the page cache -->
        <default key="maxAge">86400</default>
        <default key="sharedAge">86400</default>

        <!-- whether or not caching should apply for client caches only -->
        <default key="private">true</default>

        <!-- optionally you can define some arguments passed to the template -->
        <default key="context">
            <default key="site_name">ACME</default>
            <default key="theme">dark</default>
        </default>
    </route>
</routes>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// config/routes.php
use Symfony\Bundle\FrameworkBundle\Controller\TemplateController;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;

return function (RoutingConfigurator $routes) {
    $routes->add('acme_privacy', '/privacy')
        ->controller(TemplateController::class)
        ->defaults([
            // the path of the template to render
            'template'  => 'static/privacy.html.twig',

            // the response status code (default: 200)
            'statusCode' => 200,

            // special options defined by Symfony to set the page cache
            'maxAge'    => 86400,
            'sharedAge' => 86400,

            // whether or not caching should apply for client caches only
            'private' => true,

            // optionally you can define some arguments passed to the template
            'context' => [
                'site_name' => 'ACME',
                'theme' => 'dark',
            ]
        ])
    ;
};

Checking if a Template Exists ¶

Templates are loaded in the application using a Twig template loader, which also provides a method to check for template existence. First, get the loader:

1
2
3
4
5
6
7
8
9
10
11

use Twig\Environment;

class YourService
{
    // this code assumes that your service uses autowiring to inject dependencies
    // otherwise, inject the service called 'twig' manually
    public function __construct(Environment $twig)
    {
        $loader = $twig->getLoader();
    }
}

Then, pass the path of the Twig template to the exists() method of the loader:

1
2
3
4

if ($loader->exists('theme/layout_responsive.html.twig')) {
    // the template exists, do something
    // ...
}

Linting Twig Templates ¶

The lint:twig command checks that your Twig templates don't have any syntax errors. It's useful to run it before deploying your application to production (e.g. in your continuous integration server):

1
2
3
4
5
6
7
8
9

# check all the application templates
$ php bin/console lint:twig

# you can also check directories and individual templates
$ php bin/console lint:twig templates/email/
$ php bin/console lint:twig templates/article/recent_list.html.twig

# you can also show the deprecated features used in your templates
$ php bin/console lint:twig --show-deprecations templates/email/

When running the linter inside GitHub Actions, the output is automatically adapted to the format required by GitHub, but you can force that format too:

1

$ php bin/console lint:twig --format=github

Inspecting Twig Information ¶

The debug:twig command lists all the information available about Twig (functions, filters, global variables, etc.). It's useful to check if your custom Twig extensions are working properly and also to check the Twig features added when installing packages:

1
2
3
4
5
6
7
8

# list general information
$ php bin/console debug:twig

# filter output by any keyword
$ php bin/console debug:twig --filter=date

# pass a template path to show the physical file which will be loaded
$ php bin/console debug:twig @Twig/Exception/error.html.twig

The Dump Twig Utilities ¶

Symfony provides a dump() function as an improved alternative to PHP's var_dump() function. This function is useful to inspect the contents of any variable and you can use it in Twig templates too.

First, make sure that the VarDumper component is installed in the application:

1

$ composer require --dev symfony/var-dumper

Then, use either the {% dump %} tag or the {{ dump() }} function depending on your needs:

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

{# templates/article/recent_list.html.twig #}
{# the contents of this variable are sent to the Web Debug Toolbar
   instead of dumping them inside the page contents #}
{% dump articles %}

{% for article in articles %}
    {# the contents of this variable are dumped inside the page contents
       and they are visible on the web page #}
    {{ dump(article) }}

    <a href="/article/{{ article.slug }}">
        {{ article.title }}
    </a>
{% endfor %}

To avoid leaking sensitive information, the dump() function/tag is only available in the dev and test configuration environments. If you try to use it in the prod environment, you will see a PHP error.

Including Templates ¶

If certain Twig code is repeated in several templates, you can extract it into a single "template fragment" and include it in other templates. Imagine that the following code to display the user information is repeated in several places:

1
2
3
4
5
6
7

{# templates/blog/index.html.twig #}

{# ... #}
<div class="user-profile">
    <img src="{{ user.profileImageUrl }}" alt="{{ user.fullName }}"/>
    <p>{{ user.fullName }} - {{ user.email }}</p>
</div>

First, create a new Twig template called blog/_user_profile.html.twig (the _ prefix is optional, but it's a convention used to better differentiate between full templates and template fragments).

Then, remove that content from the original blog/index.html.twig template and add the following to include the template fragment:

1
2
3
4

{# templates/blog/index.html.twig #}

{# ... #}
{{ include('blog/_user_profile.html.twig') }}

The include() Twig function takes as argument the path of the template to include. The included template has access to all the variables of the template that includes it (use the with_context option to control this).

You can also pass variables to the included template. This is useful for example to rename variables. Imagine that your template stores the user information in a variable called blog_post.author instead of the user variable that the template fragment expects. Use the following to rename the variable:

1
2
3
4

{# templates/blog/index.html.twig #}

{# ... #}
{{ include('blog/_user_profile.html.twig', {user: blog_post.author}) }}

Embedding Controllers ¶

Including template fragments is useful to reuse the same content on several pages. However, this technique is not the best solution in some cases.

Imagine that the template fragment displays the three most recent blog articles. To do that, it needs to make a database query to get those articles. When using the include() function, you'd need to do the same database query in every page that includes the fragment. This is not very convenient.

A better alternative is to embed the result of executing some controller with the render() and controller() Twig functions.

First, create the controller that renders a certain number of recent articles:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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

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

class BlogController extends AbstractController
{
    public function recentArticles(int $max = 3): Response
    {
        // get the recent articles somehow (e.g. making a database query)
        $articles = ['...', '...', '...'];

        return $this->render('blog/_recent_articles.html.twig', [
            'articles' => $articles
        ]);
    }
}

Then, create the blog/_recent_articles.html.twig template fragment (the _ prefix in the template name is optional, but it's a convention used to better differentiate between full templates and template fragments):

1
2
3
4
5
6

{# templates/blog/_recent_articles.html.twig #}
{% for article in articles %}
    <a href="{{ path('blog_show', {slug: article.slug}) }}">
        {{ article.title }}
    </a>
{% endfor %}

Now you can call to this controller from any template to embed its result:

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

{# templates/base.html.twig #}

{# ... #}
<div id="sidebar">
    {# if the controller is associated with a route, use the path() or url() functions #}
    {{ render(path('latest_articles', {max: 3})) }}
    {{ render(url('latest_articles', {max: 3})) }}

    {# if you don't want to expose the controller with a public URL,
       use the controller() function to define the controller to execute #}
    {{ render(controller(
        'App\\Controller\\BlogController::recentArticles', {max: 3}
    )) }}
</div>

When using the controller() function, controllers are not accessed using a regular Symfony route but through a special URL used exclusively to serve those template fragments. Configure that special URL in the fragments option:

1
2
3
4

# config/packages/framework.yaml
framework:
    # ...
    fragments: { path: /_fragment }

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

<!-- config/packages/framework.xml -->
<?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:framework="http://symfony.com/schema/dic/symfony"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/symfony https://symfony.com/schema/dic/symfony/symfony-1.0.xsd">

    <!-- ... -->
    <framework:config>
        <framework:fragment path="/_fragment"/>
    </framework:config>
</container>

1
2
3
4
5
6
7

// config/packages/framework.php
use Symfony\Config\FrameworkConfig;

return static function (FrameworkConfig $framework) {
    // ...
    $framework->fragments()->path('/_fragment');
};

Template Inheritance and Layouts ¶

As your application grows you'll find more and more repeated elements between pages, such as headers, footers, sidebars, etc. Including templates and embedding controllers can help, but when pages share a common structure, it's better to use inheritance.

The concept of Twig template inheritance is similar to PHP class inheritance. You define a parent template that other templates can extend from and child templates can override parts of the parent template.

Symfony recommends the following three-level template inheritance for medium and complex applications:

• templates/base.html.twig, defines the common elements of all application templates, such as <head>, <header>, <footer>, etc.;
  templates/base.html.twig は、 、 、 など、すべてのアプリケーション テンプレートの共通要素を定義します。
• templates/layout.html.twig, extends from base.html.twig and defines the content structure used in all or most of the pages, such as a two-column content + sidebar layout. Some sections of the application can define their own layouts (e.g. templates/blog/layout.html.twig);
  templates/layout.html.twig は、base.html.twig から拡張され、2 列のコンテンツ + サイドバー レイアウトなど、すべてまたはほとんどのページで使用されるコンテンツ構造を定義します。アプリケーションの一部のセクションでは、独自のレイアウトを定義できます (例: templates/blog/layout.html.twig)。
• templates/*.html.twig, the application pages which extend from the main layout.html.twig template or any other section layout.
  templates/*.html.twig、mainlayout.html.twig テンプレートまたはその他のセクション レイアウトから拡張されたアプリケーション ページ。

In practice, the base.html.twig template would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

{# templates/base.html.twig #}
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>{% block title %}My Application{% endblock %}</title>
        {% block stylesheets %}
            <link rel="stylesheet" type="text/css" href="/css/base.css"/>
        {% endblock %}
    </head>
    <body>
        {% block body %}
            <div id="sidebar">
                {% block sidebar %}
                    <ul>
                        <li><a href="{{ path('homepage') }}">Home</a></li>
                        <li><a href="{{ path('blog_index') }}">Blog</a></li>
                    </ul>
                {% endblock %}
            </div>

            <div id="content">
                {% block content %}{% endblock %}
            </div>
        {% endblock %}
    </body>
</html>

The Twig block tag defines the page sections that can be overridden in the child templates. They can be empty, like the content block or define a default content, like the title block, which is displayed when child templates don't override them.

The blog/layout.html.twig template could be like this:

1
2
3
4
5
6
7
8

{# templates/blog/layout.html.twig #}
{% extends 'base.html.twig' %}

{% block content %}
    <h1>Blog</h1>

    {% block page_contents %}{% endblock %}
{% endblock %}

The template extends from base.html.twig and only defines the contents of the content block. The rest of the parent template blocks will display their default contents. However, they can be overridden by the third-level inheritance template, such as blog/index.html.twig, which displays the blog index:

1
2
3
4
5
6
7
8
9
10
11

{# templates/blog/index.html.twig #}
{% extends 'blog/layout.html.twig' %}

{% block title %}Blog Index{% endblock %}

{% block page_contents %}
    {% for article in articles %}
        <h2>{{ article.title }}</h2>
        <p>{{ article.body }}</p>
    {% endfor %}
{% endblock %}

This template extends from the second-level template (blog/layout.html.twig) but overrides blocks of different parent templates: page_contents from blog/layout.html.twig and title from base.html.twig.

When you render the blog/index.html.twig template, Symfony uses three different templates to create the final contents. This inheritance mechanism boosts your productivity because each template includes only its unique contents and leaves the repeated contents and HTML structure to some parent templates.

1
2
3
4
5
6
7
8

{# app/Resources/views/blog/index.html.twig #}
{% extends 'base.html.twig' %}

{# the line below is not captured by a "block" tag #}
<div class="alert">Some Alert</div>

{# the following is valid #}
{% block content %}My cool blog posts{% endblock %}

Read the Twig template inheritance docs to learn more about how to reuse parent block contents when overriding templates and other advanced features.

Bundle Templates ¶

If you install packages/bundles in your application, they may include their own Twig templates (in the Resources/views/ directory of each bundle). To avoid messing with your own templates, Symfony adds bundle templates under an automatic namespace created after the bundle name.

For example, the templates of a bundle called AcmeFooBundle are available under the AcmeFoo namespace. If this bundle includes the template <your-project>/vendor/acmefoo-bundle/Resources/views/user/profile.html.twig, you can refer to it as @AcmeFoo/user/profile.html.twig.