This PR was merged into the 1.x branch.
Discussion
----------
Deprecate usage of undefined blocks
Alternative to #2277.
Commits
-------
75d474a Deprecate usage of undefined blocks
This PR was merged into the 1.x branch.
Discussion
----------
Deprecate support for mbstring.func_overload != 0
see https://wiki.php.net/rfc/deprecations_php_7_2
Commits
-------
6668d47 deprecated support for mbstring.func_overload != 0
This PR was squashed before being merged into the 1.x branch (closes#2272).
Discussion
----------
Fix unconsistent behavior with "get" and "is"
Commits
-------
8fb35d5 Fix unconsistent behavior with "get" and "is"
This PR was merged into the 1.x branch.
Discussion
----------
Bugfix: When rendering blocks of other templates, don't pass the local blocks array
This PR fixessymfony/symfony#20556.
When referring to a block of another template from within a template that also has a block with the same name, Twig renders the wrong block.
Commits
-------
8c090a7 added tests for block() when using a template argument
a5526f3 fixed block() is defined call when using a template argument
c04d077 Bugfix: When rendering blocks of other templates, don't pass the local blocks array.
This PR was merged into the 1.x branch.
Discussion
----------
fixed render block with template wrapper
Commits
-------
159bfec fixed render block with template wrapper
This PR was merged into the 1.x branch.
Discussion
----------
Add support for PHP 7 null coalescing operator
This is just one case where we can "optimize" the ternary operator. PHP 7 also supports more complex expressions that can return `null`. The rule here seems to be that you cannot have more than one level of undefinedness.
So, for instance, if `log` is defined, `log("foo") ?? "NOPE"` works, but `log($a["foo"]) ?? "NOPE"` does not if `$a["foo"]` is not defined. If we want to convert the code to always use `??` when possible, this should probably be implemented in the Optimizer node visitor, not here. But the question is: is it worth it in terms of performance? It cleans up the generated code quite a bit though.
closes#1979
Commits
-------
cfc3931 added support for PHP 7 null coalescing operator
This PR was merged into the 1.x branch.
Discussion
----------
Expose a way to access template data and methods in a portable way
`Twig_Template` is an internal class, and most of its methods are marked as being `@internal` as they are not "safe" to use by end users.
But some of its features are interesting like `renderBlock()` which is very useful when rendering emails for instance (see #1873).
This PR tries to address both issues by marking the whole `Twig_Template` class as being internal and by exposing a new way to safely interact with a template besides the obvious `render()`/`display()` methods via `$twig->load("...")`.
If also add some convenient methods like `hasBlock()` or `getBlocks()` (see ~#1831~ and #1882):
```php
$template = $twig->load('index');
echo $template->render($context);
$template->display($context);
if ($template->hasBlock('name') {
$template->displayBlock('name', $context);
}
foreach ($template->getBlocks() as $block) {
echo $template->render($block, $context);
}
```
Commits
-------
d7062f3 exposed a way to access template data and methods in a portable way
This PR was merged into the 1.x branch.
Discussion
----------
Remove optimization as it's not compatible with Symfony cache system
fixes#2243
@nicolas-grekas Instead of fixing Symfony cache system (which will only happen in a new patch release), I propose to revert these changes. It means no optimization for Twig 1.x, but the optimization is the default in Twig 2.0. So, I don't think this is a big deal.
Commits
-------
d64d320 removed optimization as it's not compatible with Symfony cache system
This PR was merged into the 1.x branch.
Discussion
----------
added support for PHP 7 null coalescing operator
fixes#1979
Commits
-------
6effc9a changed context access to use the PHP 7 null coalescing operator when available
This PR was merged into the 1.x branch.
Discussion
----------
renamed blockExists to hasBlock
As `hasBlock()` is marked as internal and because it's not even used anywhere in Twig, I've replaced its implementation with the one of `blockExists()`, and I also kept BC with a deprecation notice just in case someone is using it.
Commits
-------
59770a3 renamed blockExists to hasBlock
This PR was merged into the 1.x branch.
Discussion
----------
Add a "with" tag
Closes#719, alternative implementation of #1054
Commits
-------
4366907 added with tag
This PR was merged into the 1.x branch.
Discussion
----------
added support for a custom template on the block() function
`block()` allows one to render a block of the current template.
This PR adds the possibility to use `block()` to render a block of another template:
```twig
{{ block('footer', template_name) }}
```
As it uses the same logic as for the regular `block()`, you can also use it in a test:
```twig
{% if block('footer', template_name) is defined %}
...
{% endif %}
```
This removes the needs to use the internal `Twig_Template::renderBlock()` method in the Symfony Web Profiler for instance. And combined with #2236, it allows us to really mark the whole `Twig_Template` class as being internal.
I'm aware that #1302 asked for being able to pass a context to `block()` (implemented in #1433), but I prefer not to in favor of adding the `with` tag (see #719 and #1054).
When the `with` will be implemented, the code in the Symfony Web Profiler will become something along the lines of:
```twig
{% with {
'collector': profile.getcollector(name),
'profiler_url': profiler_url,
'token': profile.token,
'name': name
} %}
{{ block('toolbar', template) }}
{% endwith %}
```
Commits
-------
5ed59be added support for a custom template on the block() function
Fabien Potencier
Julien Falque
Cyril PERROT
Alexander M. Turek
Marco Dania
SpacePossum