Add a render function to Twig (same as existing render_var function but a nicer name)

Looks good.

Just kidding, making vuvuzela

Ok for real this time;)

Has tests

1. +++ b/core/lib/Drupal/Core/Template/TwigExtension.php
   @@ -69,6 +69,9 @@ public function setLinkGenerator(LinkGeneratorInterface $link_generator) {
   +      // render and render_var do the same thing. render_var is only kept for
   

   Should the filters be quoted or something in the docs to distinguish them from other words?

2. +++ b/core/modules/system/src/Tests/Theme/TwigFunctionTest.php
   @@ -0,0 +1,57 @@
   +      '#template' => '{% set cats = render(animals.some_cats_i_know) %}{{ cats }}',
   ...
   +        'some_dogs_i_know' => [
   

   Who left the dogs out?

+++ b/core/modules/system/src/Tests/Theme/TwigFunctionTest.php
@@ -0,0 +1,57 @@
+          '#title' => t('Some cats I know'),
...
+          '#title' => t('Some dogs I know'),

The answer is actually don't put the t function in here because we aren't testing it:) Minimum viable code to test the feature.

That looks like the ticket. Has tests, tests only fails in #1 as it should, very simple addition for TX/DX. Beta evaluation is in the Issue Summary.

Just food for thought, the reason render was changed to render_var, was that Symfony already has a 'render' function:

http://symfony.com/doc/current/reference/twig_reference.html#functions

So we have a name clash here. As the symfony thing is not a filter, it is less of a nameclash.

Maybe we need to use drupal_render? (which is known from D7 at least) as name?

Assigning to alexpott for core committer feedback:

#1873442: Refactored core Twig integration renamed render to render_var for this exact reason.

If we rename it back now its a regression to our Symfony integration and while I am not a fan (for various reasons), I don't think its good to undo a commit of the opposite effect.

Why do we have the expectation that our twig functions and filters won't clash with https://github.com/symfony/TwigBridge? If we do have that expectation things seem really fragile.

It seems even render_var() is a namespace clash given:

new \Twig_SimpleFunction('render_*', array($this, 'renderFragmentStrategy'), array('is_safe' => array('html'))),

From https://github.com/symfony/TwigBridge/blob/e848d30c148ceb0a0dc573bba383d...

I talked to @Fabianx about this in IRC - he said:

I was under the impression we supported symfony running while Drupal is running with the same Kernel.

I not sure I understand what this means and whether or not this is a reasonable expectation.

This fine to go in, symfony should use render_esi, render_[etc.] instead when they need it or provide a symfony drupal bridge to use symfonyRender instead.

As there are ways of symfony projects using twig bridge to circumvent this and as usually a strategy is chosen, this is fine to go in.

I still feel odd about reverting a change that the lead developer of twig implemented.

So some more background:

The main concern was especially about the DrupalTwigExtension in regards to the automatic adding of passing all renderable output through 'twig_render_var'.

Because the NodeVisitor would also run for Symfony integrated code, it would have called the Symfony 'render' then (if the extension was registered afterwards).

Also this was at a time where the function was registered always in twig and not in a pluggable extension, so maybe Symfony now does not load the twig extension at all anymore ...

However in this patch 'render' is only added as a convenience / consistency function, so it would at least be possible to override all contrib/ custom/ themes templates with one that has no 'render' function in it.

Given our coding standards advise to use the filter |render, this is likely not too big a problem either.

Edit:

So this is not actually reverting the original change, but adding a conflicting function name back into our namespace.

I'm leaning towards closing this as won't fix - but before I do I want to talk with @Cottser on IRC.

What is this postponed on? It isn't clear to me from @Cottser's message.

Here is the documentation of render_var function in case you came here from Google.