This PR was merged into the 2.x branch.
Discussion
----------
Fix the error handling for the optimized extension-based function calls
Triggering a Twig_Error_Runtime at compile-time breaks the contract of the Twig environment, as such exception is for errors during the rendering.
This moves back the exception to a runtime one (same behavior than before the optimization).
Another option would be to replace this with a `Twig_Error_Syntax` instead (reporting the error earlier), but that would change the exception being thrown for such case.
Commits
-------
9928ae14 Fix the error handling for the optimized extension-based function calls
This PR was merged into the 2.x branch.
Discussion
----------
Report the proper location for errors compiled in templates
The `{% use %}` and `{% with %}` tags are adding some runtime checks triggering exceptions in the compiled template. This ensures that they get the proper location.
While the guessing was generally working fine for the `{% with %}` (and so this only makes the code faster), the guessing was not working for `{% use %}` due to the exception happening in the class constructor rather than on display (and so the guessing was finding the template which was triggering the load of the faulty template).
Commits
-------
e4423576 Report the proper location for errors compiled in templates
This PR was merged into the 1.x branch.
Discussion
----------
Ensure that syntax errors are triggered with the right line
When throwing the syntax error without any line and source in these places, the guessing logic enters into action. For the main template, it won't find anything. But for included templates (or any other template loaded during the rendering of another one, even as main one), the guessing will find a template (the caller one) and set the source and line based on it. The source will then be replaced by the proper template by `\Twig_Environment::compileSource`, but the guessed line number will make no sense then.
I searched for all places triggering a syntax error in Twig, to ensure that they always set the actual line number or set the source directly (so that the guessing logic knows that the template it found is the wrong one and so does not try to use it for guessing). There were only a few missing ones.
Commits
-------
6fab6b0b Ensure that syntax errors are triggered with the right line
The {% use %} and {% with %} tags are adding some runtime checks triggering
exceptions in the compiled template. This ensures that they get the proper
location.
While the guessing was generally working fine for the {% with %} (and so this
only makes the code faster), the guessing was not working for {% use %} due
to the exception happening in the class constructor rather than on display
(and so the guessing was finding the template which was triggering the load
of the faulty template).
This PR was merged into the 2.x branch.
Discussion
----------
Deprecate using the spaceless tag at the root level of a child template (noop anyway)
~~WIP as I'd like to trigger a deprecation notice (which will only be possible with some other changes coming up in another PR) and add some tests for the deprecated behavior.~~
Commits
-------
b2dac7df deprecated using the spaceless tag at the root level of a child template (noop anyway)
This PR was merged into the 2.x branch.
Discussion
----------
Deprecate the possibility to define a block in a non-capturing block from a child template
fixes#351, #541, #703, #988, #1639, #1685, #2393
One recurring issue (see the probably non-exhaustive list of issues references above) is a misunderstanding of how blocks work in a child template.
For instance, there is no way to define a `block` conditionally:
```twig
{% extends "layout" %}
{% if ... %}
{% block content %}
...
{% endblock %}
{% endif %}
```
And wrapping a `block` definition with a `spaceless` tag does not work:
```twig
{% extends "layout" %}
{% spaceless %}
{% block content %}
...
{% endblock %}
{% endspaceless %}
```
The issue is that the above templates compile just fine, but not in a way people expect. Basically, the condition would be empty.
Interestingly enough, wrapping a `block` definition might be useful/work as expected when used with "capturing" tags like `set`:
```twig
{% extends "layout" %}
{% set content %}
{% block content %}
...
{% endblock %}
{% endset %}
```
Not sure if that's useful, but here, the `block` tag will serve as the blog definition AND it will also be displayed in place. I would not recommend such usages.
This pull request deprecates the cases where the compiled template would never reflect the developer intent, but keeps the "working" scenarii as is.
I've been trying to fix that issue for **years**. Very happy to have found a simple solution without breaking anything that worked fine.
Commits
-------
9b938887 deprecated the possibility to define a block in a non-capturing block from a child template
This PR was merged into the 2.x branch.
Discussion
----------
Move legacy tests that were not executed anymore in 2.x
While working on some new deprecations, I noticed that some fixtures were in a directory that was not used anymore in 2.x. I've moved the relevant one back to the main Fixtures directory and remove the other one, which is not relevant anymore.
Commits
-------
c412d0f4 moved legacy tests that were not executed anymore in 2.x
This PR was merged into the 1.x branch.
Discussion
----------
Fixed PHPDoc of Twig_Token::test
For exemple `Twig_TokenParser_Set` use `->test('endset')`
Commits
-------
35a1070a Fixed PHPDoc of Twig_Token::test
This PR was merged into the 1.x branch.
Discussion
----------
Add the Symfony ctype polyfill as a dependency
Commits
-------
5b9a70b3 added the Symfony ctype polyfill as a dependency
* 1.x:
fixed website URL
Fix cache update after uploading the template file (when auto-update is enabled).
Small optimization for Twig_NodeTraverser::traverseForVisitor
Add JSON escape strategy
This PR was submitted for the 2.x branch but it was merged into the 1.x branch instead (closes#2670).
Discussion
----------
Fix partial template caching after update when auto_reload is on
**Description of the bug:**
This bug manifests itself on production servers.
And with a high load the probability of getting on this bug tends to 100%
The bug results in the caching of a partial template and the failure of a part of the site working with this template. Can only be corrected by deleting the cache.
**What's happening:**
If in the process of uploading the template file, a render() is called, the partially uploaded file gets into the cache and after the template file is fully uploaded, the cache is not updated anymore.
**How to demonstrate:**
To demonstrate the bug, you can create 2 files:
File simulating the download of a file to the server (twig_test_write.php):
```
$classTwig = new Twig_Environment( new Twig_Loader_Filesystem(__DIR__."/../../site_templates/"), array(
'cache' => __DIR__.'/../../site_templates_cache',
'auto_reload'=>true
));
file_put_contents(__DIR__."/../../site_templates/"."test.twig","\n<br>Template start write to filesystem");
echo $classTwig->render("test.twig", array());
file_put_contents(__DIR__."/../../site_templates/"."test.twig"," - Template end write to filesystem",FILE_APPEND);
```
File for template rendering (twig_test_read.php):
```
$classTwig = new Twig_Environment( new Twig_Loader_Filesystem(__DIR__."/../../site_templates/"), array(
'cache' => __DIR__.'/../../site_templates_cache',
'auto_reload'=>true
));
echo $classTwig->render("test.twig", array());
```
Result executeing file twig_test_write.php:
```
Template start write to filesystem
```
Result executeing file twig_test_read.php:
```
Template start write to filesystem
```
**After this fix:**
Result executeing file twig_test_read.php:
```
Template start write to filesystem - Template end write to filesystem
```
Commits
-------
50d990e2 Fix cache update after uploading the template file (when auto-update is enabled).
If in the process of uploading the template file, a render() is called, the partially uploaded file gets into the cache and after the template file is fully uploaded, the cache is not updated anymore.
This PR was merged into the 2.x branch.
Discussion
----------
Fix links to repository in documentation
Commits
-------
e691f2a5 Fix links to repository in documentation
This PR was merged into the 2.x branch.
Discussion
----------
Reword installation docs
One must use Composer with Twig 2.x.
Commits
-------
ff9070f6 reworded installation docs
This PR was merged into the 1.x branch.
Discussion
----------
Small optimization for Twig_NodeTraverser::traverseForVisitor
During traversing a node tree `Twig_NodeTraverser::traverseForVisitor` (`Twig_NodeVisitorInterface::leaveNode`) often returns a same child node (a same object). So, there is no need to set it back to its parent.
This PR adds a check if a child node was changed. With this check a lot of calls to `Twig_Node::setNode` will be skipped.
Closes#2665
Commits
-------
555d01f3 Small optimization for Twig_NodeTraverser::traverseForVisitor
This PR was squashed before being merged into the 1.x branch (closes#2581).
Discussion
----------
Add JSON escape strategy
The `js` escape strategy used `\xNN`-style escape sequences. This is not allowed in JSON, only `\uNNNN` is allowed.
This PR adds a new escape strategy, `json` that is similar to `js` except that it does not use `\xNN` but uses `\uNNNN` instead.
I know that I can use `json_decode()`, but it came as a surprise to me that `escape('js')` did not work. You probably shouldn't be generating JSON structures in your templates, but sometimes it comes in handy. My use-case was generating a piece of [JSON-LD](https://json-ld.org).
A different approach that would perhaps be less confusing to users would be to change `js` to not use `\xNN`. This output is still valid JavaScript, it just uses two more bytes per occurrence. Let me know what you think.
Commits
-------
5c7b080b Add JSON escape strategy
Fabien Potencier
Christophe Coevoet
Christian Flothmann
Fabien Potencier
Grégoire Pineau
ismael-miguel
AY_W
Julien Falque
Andrey F. Mindubaev
Christian Schmidt