Add the render function, deprecate the include one

[fabpot]

No description provided.

[fabpot]

Maybe it would be good to also deprecate the include tag in 3.15.
My only "concern" is about the embed tag that is kind of a glorified include node behind the scene.

[alexander-schranz]

@fabpot wanted to give some feedback. I really like the new include decision without context by default. Even I'm not a fan of renaming it render, but I understand from BC reasons for better transparency. I'm working the last two years where we only use with_context = false to make things more transparent what variables are accessed by components. Only case which was confusing is the embed tag which we use for things like overlays, fieldsets, ...

Typically looks like this:

{# overlay.html.twig #}
<dialog>
   <h3>
       {% block title %}{% endblock %}
   </h3>
   
   <div>
       {% block content %}{% endblock %}
   </div>
</dialog>

{# using.html.twig #}
{% set title = 'Title' %}
{% set content = 'Content' %}

{% embed "overlay.html.twig" only %}
    {% block title %}
        {{ title }} {# not available #}
    {% endblock %}
    {% block content %}
        <div>
            {{ content }} {# not available #}
        </div>
    {% endblock %}
{% endembed %}

To get this work I need give the variables also to overlay.html.twig which may have similar variables defined.

{# using.html.twig #}
{% set title = 'Title' %}
{% set content = 'Content' %}

{% embed "overlay.html.twig" {title: title, content: content} only %}
    {% block title %}
        {{ title }}
    {% endblock %}
    {% block content %}
        <div>
            {{ content }}
        </div>
    {% endblock %}
{% endembed %}

So it is a little bit strange. That I need to give the variables to the overlay.html.twig to access them in my own twig file. Better would be only have to give variables in it which are really used by the overlay.html.twig and block of the embed still has access to the one by its own file:

{# using.html.twig #}
{% set title = 'Title' %}
{% set content = 'Content' %}

{% embed "overlay.html.twig" only %}
    {% block title %}
        {{ title }} {# still have access to this one #}
    {% endblock %}
    {% block content %}
        <div>
            {{ content }} {# still have access to this one #}
        </div>
    {% endblock %}
{% endembed %}

Another solution would be maybe make it transparency on the embed block e.g.:

{# using.html.twig #}
{% set title = 'Title' %}
{% set content = 'Content' %}

{% embed "overlay.html.twig" only %}
    {% embedblock title with { title: title} %}
        {{ title }}
    {% endembedblock %}

    {% embedblock content with { content: content} %}
        <div>
            {{ content }}
        </div>
    {% endembedblock %}
{% endembed %}

I hope I did make it understandable where the issues with the embed tag is.

[stof]

render will conflict with the Symfony function rendering the response of a sub-request, which exists since 10 years in the Symfony ecosystem ? https://github.com/symfony/symfony/blob/v7.1.6/src/Symfony/Bridge/Twig/Extension/HttpKernelExtension.php#L28

[stof]

@alexander-schranz the {% embed %} tag actually defines an anonymous template extending the provided template name, with the body of the tag being the body of that anonymous template. The blocks inside it are normal blocks, but they are blocks defined by the anonymous template.

Your proposed syntax will not work, because blocks are rendered with the context from the caller (i.e. the parent template). they have no way to access the context of the place including the template.

[alexander-schranz]

@stof I understand that it is a technical challange to change that behaviour. Just wanted to give feedback that from end user perspective it just felled for me strange how it behaves currently.

[willrowe]

@fabpot is the new terminology variables as opposed to context or does context have a different meaning?