Commits
-------
d0ae029 Fixed notice in Twig_Error::guessTemplateLine
Discussion
----------
Fixed notice in Twig_Error::guessTemplateLine
Sometimes, `trace['line']` is not available and makes notice.
You can see tests in https://github.com/lyrixx/Silex-Kitchen-Edition/tree/composer.
Commits
-------
bf0cc53 Added code snippet to documentation to describe handling null values with date filter
Discussion
----------
Date filter docs update
Added code snippet to documentation to describe handling null values with date filter
Commits
-------
7f0cca0 fixed incorrect docblock
Discussion
----------
fixed incorrect docblock
---------------------------------------------------------------------------
by shieldo at 2012-03-19T18:15:41Z
True, and done.
---------------------------------------------------------------------------
by fabpot at 2012-03-19T18:19:33Z
Can you rebase your PR and squash your commits so that we don't have the merge? Thanks.
---------------------------------------------------------------------------
by shieldo at 2012-03-19T18:43:28Z
Sorry about that. Done. :)
Commits
-------
d942d11 Added a trim filter
Discussion
----------
Added a trim filter
This adds a trim filter in Twig as most people thought it deserves being in the core rather than in the extensions.
Closes#634
---------------------------------------------------------------------------
by fabpot at 2012-03-13T16:47:15Z
I would have added a second option to control whether you trim on both side, only on the left, or only the right. What do you think?
---------------------------------------------------------------------------
by nikic at 2012-03-13T17:15:43Z
@fabpot In that case I'd rather add two additional functions `trim_left` (mapping to `ltrim`) and `trim_right` (mapping to `rtrim`). Should be more obvious than some flag at the end :)
---------------------------------------------------------------------------
by stof at 2012-03-13T18:47:38Z
I tend to think that separate filters would indeed be more obvious. What do you prefer @fabpot ?
And for the flag, how would you specify the option to use ? Using a string ? Using boolean flags is not appropriate here (as we have 3 meaningful cases) and I don't really like the string solution.
---------------------------------------------------------------------------
by fabpot at 2012-03-13T18:53:08Z
I don't like the idea of having 3 different filter just for trimming. That seems overkill to me.
---------------------------------------------------------------------------
by stof at 2012-03-13T19:14:12Z
which API do you suggest for the filter then ?
---------------------------------------------------------------------------
by fabpot at 2012-03-13T19:23:51Z
I've no definitive idea. So, perhaps we can just merge what you've done for now.
---------------------------------------------------------------------------
by Koc at 2012-03-13T20:17:17Z
+1 for merge this. There are different filters for different trimming.
I cannot remember but there are some situations when we got string with whitespaces in variable and `{{- my_variable -}}` couldn't help and we cann't use `spaceless` filter because `my_vaiable` contains not html for example.
upd: oh, sorry, I haven't noticed comment from @nikic .
---------------------------------------------------------------------------
by Tobion at 2012-03-13T21:05:09Z
I suggest `function trim($left = true, $right = true)` but `left` and `right` could also be strings.
That would cover all cases.
---------------------------------------------------------------------------
by raulfraile at 2012-03-13T23:43:28Z
I think 3 different filters would be much clearer than using string/boolean parameters. IMO is the same case than strtolower/strtoupper.
Commits
-------
0519419 Updated 'convert_encoding' filter documentation
Discussion
----------
Updated 'convert_encoding' filter documentation
Updated 'convert_encoding' filter documentation to clarify which extension will be used in case both `iconv` and `mbstring` are installed.
Commits
-------
be07174 Added @return doc on Twig_LoaderInterface->isFresh()
8315992 Added missing @throws in Twig_LoaderInterface
Discussion
----------
Added missing @throws in Twig_LoaderInterface
Based on Twig_Loader_Chain implementation, this seems to be the possible exception that can be thrown by loaders.
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.
Fabien Potencier
Grégoire Pineau
cb
Douglas Greenshields
Raul Fraile
Christophe Coevoet
andrerom
Benjamin Steininger
Jordi Boggiano