Twig: For a Good time with Templates

Unless you're building a pure API, Twig is your new best friend. Rarely do you find a library that's this much fun to use. It's also really easy, so let me just give you a quick intro.

{{ SaySomething }}, {% doSomething %}

Twig has two syntaxes: {{ }} - which is the "say something" tag - and {% %} - which is the "do something" tag. If you're printing something, you aways write {{ then a variable name, a string or any expression: Twig looks a lot like JavaScript.

But if you're writing code that won't print something - like an if statement a for loop, or setting a variable, you'll use {% %}.

Head over to Twig's website at twig.sensiolabs.org, click Documentation and scroll down. Ah, this is a list of everything Twig does.

Look at the Tags column first: this is the short list of all "do something" tags. Click on if to see some usage. Do something tags are always {% and then if or set or one of these "tags". The for tag - used as {% for %} is for looping. You'll probably end up only using 5 or 6 of these commonly.

Twig also has other things like functions... which are exactly like functions in every language ever. Filters are a bit more interesting: check out lower. Really, these are functions, but with a trendier syntax: just print something, then use the pipe (|) to pass that value into a filter. You can have filter after filter. And, you can create your own.

The dump() Function

Let's make some magic happen in our Twig template. Our Aquanauts will take notes about each genus, and those will render on this page. Create a cool $notes variable with some hardcoded text and pass it into our Twig template:

28 lines src/AppBundle/Controller/GenusController.php
... lines 1 - 8
class GenusController extends Controller
{
... lines 11 - 13
public function showAction($genusName)
{
$notes = [
'Octopus asked me a riddle, outsmarted me',
'I counted 8 legs... as they wrapped around me',
'Inked!'
];
return $this->render('genus/show.html.twig', array(
'name' => $genusName,
'notes' => $notes
));
}
}

But before we loop over this, I want to show you a small piece of awesome: the dump() function:

3 lines app/Resources/views/genus/show.html.twig
... lines 1 - 2
{{ dump() }}

This is like var_dump() in PHP, but better, and you can use it without any arguments to print details about every available variable.

Refresh the browser! There's the name variable, notes and a bonus: app - a global variable that Symfony adds to every template. More on that in the future. With the dump() function, you can expand the variables in really cool ways. Oh, and bonus time: you can also use dump() in PHP code: Symfony gives us that function.

Go Deeper!

See more usage examples of the dump() function in The dump Function for Debugging of the separate Twig screencast. chapter.

The for Tag

To print out the notes, add a <ul> and open up a for tag with {% for note in notes %}. Close it with an {% endfor %} tag. Now, it's simple: print out each note, which is a string:

8 lines app/Resources/views/genus/show.html.twig
... lines 1 - 2
<ul>
{% for note in notes %}
<li>{{ note }}</li>
{% endfor %}
</ul>

Back to the browser to see what we've got. Refresh! Well, it's not pretty yet, but it is working. Open the source: it's still just this html, there's no HTML layout. Time to fix that.

Leave a comment!

  • 2017-05-25 weaverryan

    Yo Terry Caliendo!

    > BTW: In the first sentence of #2 you put "dev" but meant "prod"

    Thank you! I fixed that above!

    If both dump() functions are enabled, one will override the other. I believe *you* function will win, as it's registered second - but it's not a normal situation to have two functions competing with each other. And that false versus true flag to AppKernel *is* what normally configures Symfony to hide or show errors. But, this flag isn't what controls the dump() function being available: it's the environment. If you look in AppKernel, the DebugBundle (which provides the function) is only enabled in the dev and test environments. If I *did* want to see my dumps temporarily, I would actually create a temporary new front controller with new AppKernel('dev', true) and run that - go full debug/dev mode :). But, I don't need to do this very often - the prod.log file usually has what I need (actually, we configure Monolog to send all errors to Slack, so we're basically pinged when something goes into this file) to be able to replicate something locally. But, we also *never* have bugs on production... ;)

    Cheers!

  • 2017-05-23 Terry Caliendo

    Thanks much. Knowing about the var/logs/prod.log will be very helpful and hopefully save me a lot of time in the future!

    For #2 - Haven't had a chance to try it yet, but what will happen if I need to see errors in the "prod" environment and set the debug parameter to "true" in the "prod" environment. Will one dump override the other?


    $kernel = new AppKernel('prod', false); // no dump conflict
    vs
    $kernel = new AppKernel('prod', true); // twig dump conflict?

    BTW: In the first sentence of #2 you put "dev" but meant "prod" (for any future readers)

  • 2017-05-22 weaverryan

    Hi Terry!

    Wow, you're right! This is absolutely a bug in the documentation - I've just verified the same behavior as you: https://github.com/symfony/...

    Now, let's get to your questions:

    1) Yes! Production errors are logged to var/logs/prod.log. This should show the issue (it did in my case). If an error is super-fatal (which it is not in this case), you will only see error in your web server log.

    2) The reason the dump() function isn't available is because the DebugBundle that provides it is not enabled in the prod environment. So yea, you could do this - and I don't see a big problem with it (to answer question #3). The simplest way would be to (A) create a Twig extension that implements a dump() function that does nothing then (B) register this as a service in config_prod.yml. We don't normally register services in that file... but this is an abnormal situation: we want that service (i.e. Twig extension) to be registered *only* in the prod environment, where the normal dump() doesn't exist.

    Sorry it took you so long to track down! Like with all errors, if you don't know where to look, then you're totally guessing (which sucks!)

    Cheers!

  • 2017-05-19 Terry Caliendo

    I've started testing my app in the production environment. It took me *forever* to narrow down the following error that started appearing:

    Oops! An Error Occurred
    The server returned a "500 Internal Server Error".
    Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.

    It turned out that I had a dump function in one of the templates.

    {{ dump() }}

    Actually I had the dump function enclosed in an if statement:

    {% if app.environment == 'dev' %}
    {{ dump() }}
    {{ dump(app.session.all) }}
    {{ dump(app.request.attributes) }}
    {% endif %}

    The documentation seems to indicate there is a dump function in the 'prod' environment, but that nothing will be dumped (it should indicate that it doesn't exist and will throw a difficlut-to-find error!):
    http://symfony.com/doc/curr...


    "The variables will only be dumped if Twig's debug setting (in config.yml) is true. By default this means that the variables will be dumped in the dev environment but not the prod environment."

    It turns out that the dump function doesn't exist in the production (with debug=false) environment.

    bin/console debug:twig --env=prod // no dump listed in the functions

    Thus, even enclosing the dump function in a check for the environment doesn't work as it still throws the non-specific error above. I'm assuming Symfony/twig's internal compiling of the template is failing when it hits the 'debug' in the 'prod' environment.

    Questions:
    1) Is there any logging for this type of error? When the above error was output, there were no errors written to the apache or php logs. I think this is just Symfony throwing out a '500' error on its own while fully executing as far as apache/php are concerned. Does symfony log these errors somewhere? (It was VERY difficult to debug this issue, because the issue happened in the 'prod' environment, but when I'd switch to 'dev' or 'prod'/test, everything suddenly worked, so there was nothing to debug!)

    2) I'm lazy and would like to keep my 'dump' functions in my code for all time and just protect them with the 'if' statement as above. Is there a way to create a 'silent' dump function that does nothing in the 'prod' non-testing environment?

    3) Is #2 bad practice?

  • 2017-01-25 Michael Stratford

    I have a vagrant box I'm using for this, so I'm not using the built in web server. I simply modified the app.php and set dev to true and it worked as expected. Thank you for pointing me in the right direction.

  • 2017-01-25 Victor Bocharsky

    Hey Michael,

    I bet you use it in prod, but keep in mind that the dump() Twig function works only in dev mode. It's just for security reasons, i.e. to prevent leaking data (credentials, etc.). Actually, dump() function should be used only for debug reasons, but not for the production, where you should look over logs or use some monitoring services.

    Cheers!

  • 2017-01-25 Michael Stratford

    Hello,

    I'm unable to call dump() in the twig template. I can use {{ name }} and see the array of notes in {{ notes }}, however adding {{ dump() }} anywhere in the twig file, either by itself or in addition to example code as you have shown results in a 500 error.

    I have tried flushing the cache and that doesn't seem to help. Additionally, I noticed when you started typing 'dump', you had annotations pop-up. My does not do that.

  • 2017-01-11 Teolan

    Yep, Ryan I see now

    Thank you very much!

    Cheers,
    Teo

  • 2017-01-10 weaverryan

    Hey Teo!

    They are definitely still used and relevant - check out this page: http://symfony.com/doc/curr.... The one you linked to is more of a marketing "preview" of Symfony. The link I posted is the real templating/Twig documentation in Symfony :). And it has all the details about each of those functions. We also have a reference section for all the custom things that are added to Twig by Symfony: http://symfony.com/doc/curr...

    I hope that helps! Cheers!

  • 2017-01-10 Teolan

    Hi Ryan,
    I read the Docs from:
    http://symfony.com/doc/curr...

    and I can't find the docs for: path(), url(), and asset() function in Twig docs or somethere else.
    are these depreciated?

    Thanks for your advice

    Teo

  • 2016-03-08 weaverryan

    Hi Pad!

    Oh that *is* weird - especially since PHPStorm can see the variables. Try this: remove all the variables (so that there aren't any errors anymore) and then just execute {{ dump() }}. This will dump out *all* the variables you have available to you. If there's some weird issue - you should see that your variables are *not* in this list. This isn't a solution exactly - but hopefully it'll take you to the next step of debugging.

    And btw, there really *shouldn't* be anything weird happening here - there's no magic to watch out for - it's probably some tiny error somewhere :). Let me know how it goes!

  • 2016-03-07 Pad Womack

    Hi there!
    I am having some trouble getting the variable being passed by my controller into the twig template. I'm returning it exactly as shown in the tutorial and PHPStorm can see it for auto completion but when I actually run the code in my browser it tells me the variable can't be found.