bumped version to 1.7.0-DEV

made usage of mergeContextWithGlobals in macros

fixed doc markup

fixed doc markup

fixed doc indexes

renamed a test

added compilation checks to avoid misuses of the sandbox tag

fixed Twig unit tests when a template must throw an exception

enhance error reporting in Twig unit tests

added doc for the sandbox tag

added a note about sandbox policy checks in the doc (refs #677)

fixed filesystem loader freshness logic for high traffic websites (closes #682)

bumped version to 1.6.4-DEV

prepared the 1.6.4 release

updated CHANGELOG

fixed file permission

merged branch Nami-Doc/patch-1 (PR #680)

Commits
-------

27ffef0 The question I'm asking myself now is : how could I get $trace['line'] is not set if there's a check before the <= ? anyway, fixed
36618fe fix a bug where when an error would be thrown through the loader (Twig_Error_Loader by Twig_Loader_Filesystem, ie) the $trace['line'] would not be set (since we're not in a template)

Discussion
----------

fix a bug where when an error would be thrown through the loader

(Twig_Error_Loader by Twig_Loader_Filesystem, ie) the $trace['line'] would not be set (since we're not in a template)

thanks

---------------------------------------------------------------------------

by Nami-Doc at 2012-03-31T20:00:31Z

fixed, thanks @stof. Now I wonder (as I just wrote) : how could I get the error with that isset here ?

---------------------------------------------------------------------------

by stof at 2012-03-31T20:05:45Z

@Nami-Doc what was the exact error you got ?

---------------------------------------------------------------------------

by Nami-Doc at 2012-03-31T20:09:51Z

Php states that $trace['line'] isn't set

---------------------------------------------------------------------------

by Nami-Doc at 2012-03-31T20:23:33Z

O.K., got it. this has been fixed in #675, but composer (great tool) installed me last tag, but I think it's better to check it outside the loop anyway (micro-micro-optimisation)

fixed performance when compiling large files

The question I'm asking myself now is : how could I get $trace['line'] is not set if there's a check before the <= ? anyway, fixed

fix a bug where when an error would be thrown through the loader (Twig_Error_Loader by Twig_Loader_Filesystem, ie) the $trace['line'] would not be set (since we're not in a template)

made a small optimization when there is only one trait used in a template

optimized parent template creation when the template does not use dynamic inheritance

merged branch lyrixx/error-guess (PR #675)

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.

Fixed notice in Twig_Error::guessTemplateLine

merged branch carbonatethis/Documentation (PR #674)

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

Added code snippet to documentation to describe handling null values with date filter

bumped version to 1.6.4-DEV

prepared the 1.6.3 release

added documentation for the trim filter

fixed usage of Z_ADDREF_P for PHP 5.2 in the C extension

merged branch shieldo/patch-1 (PR #670)

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. :)

simplified code

fixed incorrect docblock

fixed compilation of numeric values used in templates when using a locale where the decimal separator is not a dot

simplified tests

made the strategy used to guess the real template file name and line number in exception messages much faster and more accurate (refs #647)

bumped version to 1.7.0-DEV

prepared the 1.6.2 release

fixed sandbox mode when used with inheritance (closes #656)

The checkSecurity() method must be called by each template as we are not
using inheritance.

added preserveKeys support for the slice filter (closes #669)

fixed the date filter when a DateTime instance is passed with a specific timezone (closes #660)

merged branch stof/trim_filter (PR #662)

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.

merged branch raulfraile/patch-1 (PR #665)

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.

Updated 'convert_encoding' filter documentation

Added a trim filter

Closes #634

merged branch andrerom/patch-1 (PR #658)

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.

Added @return doc on Twig_LoaderInterface->isFresh()

Added missing @throws in Twig_LoaderInterface

Based on Twig_Loader_Chain implementation, this seems to be the possible exceptions that can be thrown by loaders.

fixed typo

fixed previous commit

merged branch robo47/docs-install-via-composer (PR #648)

Commits
-------

7153ff6 Installing twig via composer

Discussion
----------

Installing twig via composer

Installing twig via composer

bumped Twig version

fixed typo in the doc

fixed typos in the doc

prepared the 1.6.1 release

fixed Twig C extension

fixed CS

added some unit tests

Installing twig via composer

added some more information on the spaceless tag documentation

added some information about Twig_Template::getContext() and made it final

Revert "merged branch m0ppers/master (PR #611)"

This reverts commit 5f4e6d7a0eae30791e9e1433c90b157bcb5dc8f7, reversing
changes made to a61d42084caeadc4cc8c3bd1caded87631c12636.

updated CHANGELOG

merged branch m0ppers/master (PR #611)

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);

clarified documentation (closes #602)

merged branch mvrhov/patch-1 (PR #603)

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.

updated CHANGELOG

merged branch Seldaek/markup (PR #638)

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.

Avoid creating unnecessary Twig_Markup instances, allows testing for falsiness of empty output

added phpdoc (closes #627)

updated the CHANGELOG and documentation for previous merge

fixed previous merge

merged branch mlehner/default_timezone (PR #635)

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.

added setTimezone to allow globally overriding the timezone when formating dates

merged branch webwizard/patch-1 (PR #628)

Commits
-------

904dfef fixed typo

Discussion
----------

fixed typo

fixed typo

removed usage of assertInstanceOf as if is not available when using PHPUnit on PHP 5.2.*

added more safeguards in unit tests to support different configuraitons

updated CHANGELOG

added some unit tests for previous merge

fixes CS

merged branch sv1l/master (PR #623)

Commits
-------

b6007f1 Fixed slice filter w/ null length for string values

Discussion
----------

Fixed issue #622: strings slice filter w/ no length

Fixed issue [#622](https://github.com/fabpot/Twig/issues/622)

Fixed slice filter w/ null length for string values

fixed the creation of the cache directory in case of a race condition (closes #620)

bumped version to 1.7.0-DEV

prepared the 1.6.0 release

added missing entry in the doc

fixed raw blocks when used with the whitespace trim option (closes #617)

added some unit tests for the reverse filter when charset is not UTF-8

added some unit tests for random() when charset is not UTF-8

fixed previous commit

fixed the random() function on strings when the charset is not UTF-8
(refs #614)

fixed CS

merged branch Tobion/test-coverage (PR #615)

Commits
-------

814cefd improve test coverage and support negative int for random function

Discussion
----------

improve test coverage and support negative int for random function

improve test coverage and support negative int for random function

tweaked doc

merged branch Tobion/patch-4 (PR #614)

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

typo again

typo

updated doc for random function