Provide inline_template tag within Twig that inlines a template for usage with a render array

Tagging

And here is the first part of it:

* Added a key #render_function to support from theme().

That was surprisingly simple.

For non-theme drupal_render still needs a way to "get variable-like output" for things like #type => link.

And here is a first implementation that can be tested with the following drush script:

$link = array(
  '#type' => 'link',
  '#href' => 'node',
  '#title' => 'foo',
);

$twig = Drupal::service('twig');
$name = 'test-it.html.twig';

print $twig->loadTemplate($name)->render(array('link' => $link, 'foo' => 'wrong output' ));

test-it.html.twig:

{{ link['#href'] }}
{% inline_template link %}
<a href="{{ link.url }}">More text</a>
{% endinline_template %}

Note: The "link" prefix is hardcoded for now.

This really shows that there is a HUGE gap between #type and #theme.

Ideal would be if we could define a #theme => link that is purely internal to Drupal and neither allows theme_link nor templates however and can only be used for inline-templating, because #type obviously has no variables definition / idea at all ... So giving an example as link-type.html.twig.example would be nice.

But it works and is nearer to drillability than we ever have been before.

Uhhh, yes.

How to create 115k exceptions with one change :-D.

Put render to the right array ...

.

OMG! I have made drillability for field possible with that for https://github.com/jenlampton/twigified!

( inlining what before was a suggestion for a field )

New plan for this issue:

* Move the #type specific things to a follow-up
** Create the follow-up and make clear what the problems are.

* Fix syntax and make it possible to specify an identifier and an expression, if the expression is a render array, hide and show will work (remove hard-coded "link")
** Like: {% inline_template "link" link %}
** Or like: {% inline_template "link" { '#type': 'link', '#href': 'node', '#title': 'hi' } %}

* Clean-up, docs and get this committed

no time to finish currently.

Its DrupalCon!

Re-opening for potential 8.1.x - no API change needed.

Nope, this is something different.

I've worked out a plan:

- Copy the block tag node (Twig\Node\Twig_Block.php) to a different tag for the inner part
- Create a new node for the direct calling of the function
- Use a closure and pass the parent context as 'parent_context' variable.

Generated PHP code then looks something like:

$self = $this;
print $this->drupalExtension->inlineTemplateOverride($context['some_var'], function($variables) use ($context, $self) {
  $variables['parent_context'] = $context;
  ob_start();
  $self->inlineTemplate_[hash]($variables);
  return ob_end_clean();
}));

A different possibility would be to dynamically return the code of the template (similar to how the other #inline_template works), but that might have caching challenges as it already now is difficult to create all templates in advance.

Here is a first patch that already works using code like this:

{% inline_template some_entity %}
  Label: {{ label }}
  User: {{ parent_context.some_entity.user }}
{% endinline_template %}

--

Still todo:

- Ensure that exceptions are showing the original source line (non-inlined)
- Ensure that we don't need to pin twig to 1.26.0
- Cleanup
- Tests

#39: This issue still needs an IS update, I don't think with and only give much value here, when the full parent context is available as 'parent_context'.

I am thinking about this some more and there is 2 different things:

One: Being able to include an inline template like possible in render arrays:

e.g.

{% include inline_template('{{ label }}') %}

but that is less useful obviously without a different scope.

99% can be done without needing extends or whatever, so:

{% inline_template field_awesome %}
  Label: {{ label }}
{% endinline_template %}

can be implemented purely with blocks.

And if you really need a new template, you can use:

{% inline_template field_awesome %}
{% filter render_inline_template %}{% verbatim %}
  {% extends 'foo.html.twig' %}
  {% block label %}
  Label: {{ label }}
  {% endblock %}
{%endfilter}{% endverbatim %}
{% endinline_template %}

As that is only for advanced use cases AND the 1-2% case, I feel it is okay to have more verbose syntax for that case.

And more than one verbatim is not supported, period.

For the 99% case the generated PHP code looks like:

function block___internal_[hash]($context, $blocks = array) {
  echo "Label: ";
  echo isset($context['label']) ? $context['label'] : '';
}

For the 1% case the generated PHP code looks something like:

function block___internal_[hash]($context, $blocks = array) {
  echo $this->env->renderInlineTemplate('Label: {{ label }}', $context);
}

The advantage is that the inline_template tag can be a _simple_ callback and advanced functionality is added via composition and not via hacks.

We also no longer need getSource() access then and performance increases slightly.

In the theory case we ever want to support more than one verbatim, we can have the inner verbatims be called verbatim_1, verbatim_2 and replace them per nesting level we are on ... But that can be a follow-up - if ever needed.

So likely good to have parent_context, but also inline_template_level == 1,2,3,4, ...

---

So a full win.