Consider appropriate usage of theme() from within Twig templates

No, this is different.

diff --git a/core/lib/Drupal/Core/Template/TwigFactory.php b/core/lib/Drupal/Core/Template/TwigFactory.php
index ef1a40d..91dd369 100644
--- a/core/lib/Drupal/Core/Template/TwigFactory.php
+++ b/core/lib/Drupal/Core/Template/TwigFactory.php
@@ -93,6 +96,7 @@ public static function get() {
 
     // @todo Remove URL function once http://drupal.org/node/1778610 is resolved.
     $twig->addFunction('url', new \Twig_Function_Function('url'));
+    $twig->addFunction('theme', new \Twig_Function_Function('theme'));
     return $twig;
   }
 }

Please apply to front-end.

Applied to frontend branch

11555f703d690a5b0f3975a7eb7e31fc23da5a4a

Some questions and concerns here. I believe from conversations in IRC earlier this week, we decided that everything sent to a Twig template would be renderable and that Twig template variables should know how to render themselves. Therefore, variable addressability in Twig, by definition, means that it should be renderable, and it is up to the render array to define this structure in an extensible and flexible way.

So, instead of calling theme('node', $node) from Twig, we'd simply be able to do {{ node }} and it would understand. It was via this principle where I started doing some tinkering around here https://gist.github.com/4061841 as a conceptual demo.

Can someone provide some insight here as to why theme function calls should be available via Twig as opposed to having Twig template variables understand their inherent printing method?

This is needed to include another template of your own choice, while calling suggestions, etc. without being dependent that preprocess set things up correctly in a render array.

It completes that {% include is not calling suggestions, pre-process, etc, but rather hard-codes the template to be used.

Moving this to the core queue from Twig sandbox. Attached patch allows use of theme() within Twig templates.

Thanks, steveoliver.

According to the prototype of theme we don't need the arguments by reference, such we can and probably should use:

new \Twig_Function_Function('theme')

as per #11

As expressed in November, I still think this is a bad idea. theme() functions are just (poor) abstractions of nested renderables. A grep for this usage yields the following 3 calls:

./core/themes/stark/templates/filter/filter-guidelines.html.twig:  {{ theme('filter-tips') }}
./core/themes/stark/templates/theme.inc/table.html.twig:        {{ theme('table_cell', cell) }} {# Note: <th> returned by table_cell. #}
./core/themes/stark/templates/theme.inc/table.html.twig:          {{ theme('table_cell', cell) }} {# Note: <td> returned by table_cell. #}

These are minimal, and I think can be removed. Does it seem logical that we can change this issue to simply eliminate the use of theme() in Twig templates and refactor the above instances? What do you guys think?

This rides the line of where our theme "system" calls something done, vs. done-done*. ;)

I agree, c4rl, we should be done-done by now (within a template).

I see the theme layer(s) as this

1. Theme data (PHP data objects) - theme()
2. Theme object (Twig renderables) - [pre]process()
3. Theme output (HTML markup) - templates

I agree, let's not call theme() in templates.

We really do need these lines drawn. I think c4rl you've got just the right vision on this. I'm in 'just effin' make it work' mode. :)

*Thanks, sdboyer :)

Moving this back to the sandbox, where we've been calling theme() within templates, but should stop. :)

...working on this, incorporating #1778624: rework theme_filter_tips to use the new Attributes, and call theme('item_list) while we're at it

I updated the issue summary here.

Since we are allowing theme() in templates for the time being, I've fixed various fatal errors related to += / array_merge issues by registering the theme() function as a \Twig_Function_Function rather than a TwigReferenceFunction in git commit 249490c.

Better title. Let's postpone this for now given that we have some disagreement?

Here is further information:

#1905694: Introduce theme_to_render helper function

I've updated #1905694: Introduce theme_to_render helper function to reflect that instead of using theme() calls at all, we should use render arrays:

$vars['foo'] = theme('bar', array('baz' => $node));

becomes

$vars['foo'] = array(
  '#theme' => 'bar',
  '#baz' => $node,
);

Marking this one as fixed.