Form Theme Block Naming & Creating our Theme!

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

When Symfony renders the "label" part of a password field type... it should be looking for a password_label block name. And... it is. But... that block doesn't exist! What's going on?

Here's the situation: the label will look the same for probably every field type: there's no difference between how a label should render for a text field versus a choice drop-down. To avoid duplicating the label code over and over again, the block system has a fallback mechanism.

Block Prefixes

Go back to your browser, click on the form icon on the web debug toolbar and select plainPassword. Go check out the "View Variables". Ah, here it is: the very special block_prefixes variable! This is an array that Symfony uses when trying to find which block to use. For example, to render the "widget" for this field, Symfony first looks for a block named _user_registration_form_plainPassword_widget.

This super specific block name will allow us to change how the widget looks for just one field of the form. We'll do this a bit later. If it does not find that block, it next looks for password_widget, then text_widget, and finally form_widget. There is a password_widget block but, when the label is being rendered, there is not a password_label block. Ok, so it next looks for text_label. Let's see if that exists. Nope! Finally, it looks for form_label. Search for that. Got it!

This is the block that used to render every label for every field type.

The Form Rendering Big Picture

Open up register.html.twig: let's back up and make sure this all makes sense. When we call form_widget(registrationForm), that's a shortcut for calling form_row() on each field. That means that the "row" part of each field is rendered. Not surprisingly, the "row" looks exactly the same for all field types. In other words, in bootstrap_4_layout.html.twig, you probably won't find a password_row block, but you will find a form_row block. Keep searching until you find it... there it is!

Ah, I love it! It has some special logic on top, but then! Yes: it renders a div with a form-group class then calls the form_label(), form_widget() and form_help() functions! The reason you don't see form_errors() here is that it's called from inside of form_label() so we can get the correct Bootstrap markup.

Creating our Form Theme

We now know enough to be dangerous! If we could override this form_row block just for the registration form, we could simplify the markup to match what we need. How do we do that? By creating our own form theme... which is just a template that contains these fancy blocks.

If you create a form theme in its own template file - like bootstrap_4_layout.html.twig - you can reuse it across your entire app by adding it to twig.yaml after bootstrap. Or, you can add some code to your Twig template to use a specific form theme template only on certain forms.

But, we actually will not create a separate template for our form theme. Why not? If you only need to customize a single form, there's an easier way. At the top of the template where you form lives, add {% form_theme %}, the name of your form variable - registrationForm - and then _self.

... line 1
{% form_theme registrationForm _self %}
... lines 3 - 63

This says:

Yo form system! I want to use this template as a form theme template for the registrationForm object.

As soon as we do this, when Symfony renders the form, it will first look for form theme blocks right inside of this template. Yep, we could copy that form_row block from Bootstrap, paste it, and start customizing!

Let's do that! But, actually, the Bootstrap form_row block is a bit fancier than I need. Instead, open form_div_layout.html.twig and find the block there. Copy that and, in register.html.twig, paste this anywhere.

... lines 1 - 3
{% block form_row %}
{%- set widget_attr = {} -%}
{%- if help is not empty -%}
{%- set widget_attr = {attr: {'aria-describedby': id ~"_help"}} -%}
{%- endif -%}
<div>
{{- form_label(form) -}}
{{- form_errors(form) -}}
{{- form_widget(form, widget_attr) -}}
{{- form_help(form) -}}
</div>
{% endblock %}
... lines 17 - 63

Hmm - let's remove the wrapping <div> and see if this works! Deep breath - refresh! I saw something move! Inspect the form and... yes! That wrapping div is gone!

... lines 1 - 3
{% block form_row %}
{%- set widget_attr = {} -%}
{%- if help is not empty -%}
{%- set widget_attr = {attr: {'aria-describedby': id ~"_help"}} -%}
{%- endif -%}
{{- form_label(form) -}}
{{- form_errors(form) -}}
{{- form_widget(form, widget_attr) -}}
{{- form_help(form) -}}
{% endblock %}
... lines 15 - 61

When Symfony looks for the form_row() block it finds our block and uses it. All the other parts - like the widget and label blocks - are still coming from the Bootstrap theme. It's perfect.

But, we have more work to do! Next, let's learn a lot more about what we can do inside of these form theme blocks.

Leave a comment!

  • 2020-01-19 Coder

    thanks

  • 2020-01-06 weaverryan

    Hey Coder!

    Sorry for the slow reply!

    > There is a password_widget block but, when the label is being rendered, there is not a password_label block."
    > How does it know that it needs password_label block?

    Good question :). Here's what the process looks like internally:

    A) The form system starts to render the "label" for a "password" field. It asks: "which block should I use to render this"?

    B) To determine that, it first looks for a block called "password_label". It *always* first looks for a block that is the "field type" an underscore and then "label" (because it's rendering a label). For example, when the form system needs to render the label for a "textarea" it also looks for textarea_label first. By default, pretty much no field types have a custom "TYPE_label" block.

    C) Because there is no "password_label" block, the form system automatically then looks for "form_label". That's just how the system works - it always falls back to using "form".

    This is a slight over-simplification, but the general idea is accurate: it looks for password_label first and if it is not found, falls back to form_label. The reason you don't see this logic inside the form_widget_simple or password_widget blocks is that the logic lives one level higher: this logic lives at the layer that is responsible for rendering the blocks. It's a crazy function, but the logic that renders the blocks and has all this "fallback logic" is this one: https://github.com/symfony/...

    Cheers!

  • 2019-12-31 Coder

    "There is a password_widget block but, when the label is being rendered, there is not a password_label block."

    How does it know that it needs password_label block?

    In here I dont see:

    {%- block password_widget -%}
    {%- set type = type|default('password') -%}
    {{ block('form_widget_simple') }}
    {%- endblock password_widget -%}

    {%- block form_widget_simple -%}
    {%- set type = type|default('text') -%}
    {%- if type == 'range' or type == 'color' -%}
    {# Attribute "required" is not supported #}
    {%- set required = false -%}
    {%- endif -%}
    <input type="{{ type }}" {{="" block('widget_attributes')="" }}="" {%="" if="" value="" is="" not="" empty="" %}value="{{ value }}" {%="" endif="" %}=""/>
    {%- endblock form_widget_simple -%}