This PR was submitted for the master branch but it was merged into the 2.x branch instead (closes#2254).
Discussion
----------
Clean ups
Commits
-------
1f6fd67 Clean ups
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 submitted for the master branch but it was merged into the 2.x branch instead (closes#2253).
Discussion
----------
Use ** operator over function pow()
With Twig PHP dep. raised to 5.6 the arithmetic operator [`**`](http://php.net/manual/en/language.operators.arithmetic.php) can be used.
Besides slightly faster it is also harder to override an operator than it is the `pow()` function.
Commits
-------
97f8159 Use ** operator over function pow()
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
This PR was merged into the 1.x branch.
Discussion
----------
added 'is defined' support for constant
Commits
-------
c81bae4 added 'is defined' support for constant
This PR was merged into the 1.x branch.
Discussion
----------
Add "is defined" support for block()
replaces #1831, fixes#1821
I think reusing the semantic of the `defined` test is more idiomatic and easily discoverable.
/cc @hason
Commits
-------
3ce06af added 'is defined' support for block()
4f013e0 Add test to check if a block exists
This PR was merged into the 1.x branch.
Discussion
----------
removed old code that is not needed anymore
Commits
-------
60bed59 removed old code that is not needed anymore
This PR was merged into the 1.x branch.
Discussion
----------
added a proper error message when block() is called without arguments
Commits
-------
a63ee7c added a proper error message when block() is called without arguments
Fabien Potencier
SpacePossum
Martin Hasoň