Commits
-------
71449e8 Remove optimization (covered by Optimization VAR_ACCESS anyway)
Discussion
----------
Remove optimization (covered by Optimization VAR_ACCESS anyway)
I have an own template class implementing getContext() and this one drove me completely mad after a twig upgrade.
After compilation the resulting templates have:
isset($context['bla'])
vs.
$this->getContext('bla')
Changing the Name Node however didn't have any effect and i saw that due to the optimizations by the SetTemp class twig doesn't even reach the Name Node. In fact SetTemp has the isset optimization hardcoded (which is ok).
I could simply fix my issue by setting optimizations to -9 (all optimizations except VAR_ACCESS). However the issue will reappear immediately when using PHP 5.4. Please remove the isset stuff from the non optimized node and let the optimization handler handle it (which i would disable in my case)
---------------------------------------------------------------------------
by m0ppers at 2012-01-24T17:42:07Z
some hackish script to test what i mean
<?php
require 'lib/Twig/Autoloader.php';
Twig_Autoloader::register();
abstract class Harxtemplate extends Twig_Template
{
public function getContext($context, $item, $ignoreStrictCheck = false)
{
if ($item == "hans") {
return "hund";
} else {
return parent::getContext($context, $item, $ignorStrictCheck);
}
}
}
$template = <<<EOT
Der {{ hans }} hat hund
{% if hans %}
hund
{% endif %}
EOT;
$loader = new Twig_Loader_String();
$options = array('base_template_class' => 'Harxtemplate',
// 'strict_variables' => true, // doesn't work
'debug' => true,
'optimizations' => -1, // 0 => works
);
$twig = new Twig_Environment($loader, $options);
echo $twig->render($template);
Commits
-------
95f8af7 cast $name to a string as $name can in fact be an object implementing __toString function as true in my case.
Discussion
----------
cast $name to a string ...
... because $name can be an object implementing __toString. I have Enum type implementation which implements __toString. Without the cast I'm getting the following exception:
"An exception has been thrown during the rendering of a template ("Warning: Illegal offset type in isset or empty in... "
---------------------------------------------------------------------------
by fabpot at 2012-01-18T08:43:23Z
From where do you call these methods? from your code? from a template?
---------------------------------------------------------------------------
by mvrhov at 2012-01-18T11:17:55Z
I put the enum object as variable into the template and then based on the enum value I display a block.
Commits
-------
e4590d0 Avoid creating unnecessary Twig_Markup instances, allows testing for falsiness of empty output
Discussion
----------
Avoid creating unnecessary Twig_Markup instances
This allows testing for falsiness of an empty output:
```jinja
{% set foo %}{% block lala %}{% endblock %}{% endset %}
{% if foo %}
some output with {{ foo }}
{% endif %}
```
Currently this requires `{% if foo|length %}` since the set tag will always return a Twig_Markup.
Commits
-------
5699753 added setTimezone to allow globally overriding the timezone when formating dates
Discussion
----------
Allow setting global timezone for date formatting
My API returns dates in a string format of 2012-02-14T00:35:37+00:00. When parsed by the DateTime constructor, the timezone for that new object is UTC. Without specifying every time I use the date filter there was no way to globally influence the timezone used.
I added setTimezone() to the core extension that functions similar to setDateFormat() except that there is no timezone set by default to allow for backwards compatibility.
Commits
-------
814cefd improve test coverage and support negative int for random function
Discussion
----------
improve test coverage and support negative int for random function
Commits
-------
a15e8f7 typo again
2561aa2 typo
faa90c9 updated doc for random function
fe66358 added tests for random function
6f5ceee Made the random function more versatile
Discussion
----------
Made the random function more versatile
The point is to meet user expectations and to make it more versatile, so it works under more circumstances.
At the moment the random function does only return the supplied parameter when it's not an array. That is not very useful. With this PR it will behave like
random() => integer as with mt_rand()
random(5) => integer between 0 and 5 as with mt_rand(0, 5)
random('foobar') => random character from 'foobar'
random(array(...)) => random element
I will add tests and documentation if you accept this PR.
---------------------------------------------------------------------------
by fabpot at 2012-01-26T07:29:35Z
Looks good to me. Can you update the docs and add some unit tests?
---------------------------------------------------------------------------
by Tobion at 2012-01-26T11:50:17Z
ready
Commits
-------
e81a9e2 Improved random function
Discussion
----------
Improved random function
- dealing with empty array (otherwise PHP warning is raised)
- using array_rand() and thus saving the $keys variable
---------------------------------------------------------------------------
by Tobion at 2012-01-25T12:41:32Z
How about allowing `mt_rand ( int $min , int $max )` with optional parameters to be used when the $values ist not an array?
This would solve use case #612
Commits
-------
0d656f5 Add comments
0255764 Updated CHANGELOG
b327a48 Protect the Parser against recursive parsing issues
Discussion
----------
Make the parser Inception-Proof
Spent half a day debugging before I realized what happened, but I'll try to keep a long story short:
When the cache is empty, and the first template containing an assetic `{% javascripts %}` or similar tag is parsed, it will build up the assetic "assets" or recipes cache, this in turn will tokenize and parse all your templates to find assetic tags and cache that information.
At this point the parser is parsing something else in the middle of a parse() call, and since there is a single instance in the environment, it means all the instance vars are messed up and contain incorrect references to the latest TokenStream that was parsed by assetic, etc.
This had two effects on my application, both appearing seemingly randomly because it highly depends on the order of things, the state of your cache and probably other factors:
- The first thing that happened is that a template was compiled using the wrong template filename, which means I had a `__TwigTemplate_abcd` in the file named `dcba.php`, and it would never find the right class.
- The second issue (could not reproduce but I assume it was caused by this as well) is that the parse tree is completely broken and you end up with a parse error because it thinks it's at the end when it's not, or similar problem.
The proposed fix basically pushes/pops all the vars into a stack whenever the parser starts/stops, which worked very effectively here and does not introduce much breakage or complexity.
---------------------------------------------------------------------------
by stof at 2012-01-24T17:28:06Z
@Seldaek are you able to create a reproducible testcase for this (which should be failing before this fix) ? It would avoid further regressions
---------------------------------------------------------------------------
by Seldaek at 2012-01-24T17:45:37Z
I'll try to improve on this according to feedback tomorrow. I saw this enough for today :)
---------------------------------------------------------------------------
by fabpot at 2012-01-24T17:45:49Z
I'm writing some unit tests
---------------------------------------------------------------------------
by Seldaek at 2012-01-24T17:47:02Z
Ok then I'll add @dzuelke's comments real quick.
Fabien Potencier
Jordi Boggiano
Matt Lehner
Victor Zamfir
Sylvain Dethier
Tobias Schultze