added more unit tests

removed some loop variable when using an if statement in a for loop

made a markup refactoring

fixed algorithm that determines if a template using inheritance is valid (no output between block definitions)

tweaked an error message

renamed a class in unit test to avoid confusion with PHPStorm

fixed resolveTemplate() method (we only catch loader exceptions)

added better support for encoding problems when escaping a string (available as of PHP 5.4)

From the PHP CHANGELOG:

The flag ENT_SUBSTITUTE makes invalid multibyte sequences be replaced by
U+FFFD (UTF-8) or &#FFFD; by htmlspecialchars and htmlentities. It is an
alternative to the default behavior, which just returns an empty string and to
ENT_IGNORE, which is a security risk. The behavior follows the recommendations
of Unicode Technical Report #36.

simplified previous merge

fixed CS

merged branch Brouznouf/patch-1 (PR #425)

Commits
-------

4dc490f Removing array_shift for optimisation.

Discussion
----------

Removing array_shift for optimisation.

For example we check if a template and use exception to redirect to a default template

Before : We checked ~1000 times => 100sec due to array_shift
After  : ~1sec

Removing array_shift for optimisation.

For example we check if a template and use exception to redirect to a default template

Before : We checked ~1000 times => 100sec due to array_shift
After  : ~1sec

fixed markup in the doc

added support for an array of templates to the "extends" tag

added a way to ignore a missing template when using the "include" tag

added support for an array of templates to the include tag

updated CHANGELOG

merged branch jturmel/master (PR #403)

Commits
-------

c2c01de Add bitwise operators to core

Discussion
----------

Added bitwise operators (and, xor, or) to core

* Added bitwise operators (and, xor, or) to core

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

by nikic at 2011/08/02 21:02:14 -0700

I'm not sure bitwise ops really belong into a templateing language...

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

by jturmel at 2011/08/02 21:06:02 -0700

That's a general statement to make without knowing why it was implemented at all... no one is forced to use them, however when you do need them, them not being available makes you have relegate something that should be in the view in the particular case I needed them, to be done in a controller instead, which would be quite a bit nastier in my case.

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

by nikic at 2011/08/02 23:23:30 -0700

@jturmel: I do not doubt that there are some cases where bitwise operations are useful. I can't think of one of the top of my head, though I imagine that it could be useful when using bitwise right management or something like that. What I was trying to say is, that I don't really believe that there are enough significant use cases for bitwise ops to justify adding them to the core (I know, "You Don't Have To Use It!", but it isn't good to clutter the core with features nearly no one uses). Maybe you could give an example of what you needed them for?

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

by jturmel at 2011/08/02 23:41:36 -0700

It would be one thing if I was implementing some operator that didn't normally exist in PHP itself, but it seems a bit odd to even say that it's cluttering it up, it's 3 lines of code that add 3 missing standard operators from PHP.

Simply put, I have an object that gets passed to the template that has many properties, these properties are bit values, I need to do checks on them to select/deselect various checkboxes in a grid... this is the cleanest way to do it without mudding up controller code with view logic.

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

by jalliot at 2011/08/03 01:42:56 -0700

Why not adding ``<<`` and ``>>`` then @jturmel?
I don't have a particular use case but I think that if Twig includes those 3 operators, it should also support these 2 to be "complete". What do you think?

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

by jturmel at 2011/08/03 06:07:46 -0700

Of course, if you guys think we need the shifting operators as well, we can... but modifying data in the view seems much less practical than the one's I added, although I did miss NOT.

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

by jalliot at 2011/08/03 06:16:38 -0700

I forgot about ``~`` but sure it should be included as well.
As for ``<<`` and ``>>``, they could also be used for verifying grant access for example in some implementations.
``{% if some_var << some_other_var & 1 %}``

replace file_exists() by is_file() as this is semantically more correct (we don't want dirs to match)

replaced usage of array_replace by array_merge (for 5.2 compatibility)

added the "attribute" function to allow getting dynamic attributes on variables

added Twig_Loader_Chain

renamed a test file

added Twig_LoaderArray::setTemplate()

switcher PHPUnit colors to true

merged branch videlalvaro/patch-1 (PR #419)

Commits
-------

0ef1cb0 Edited doc/templates.rst via GitHub

Discussion
----------

Edited doc/templates.rst via GitHub

I fixed a typo: Variables can by for Variables can be

Edited doc/templates.rst via GitHub

changed unit tests so that they work for PHP 5.2

moved some logic to the constructor (that's allows visitors to have the real node that will be compiled)

added an optimization for the set tag when used to capture a large chunk of static text

removed unneeded implementation of Template::getTemplateName()

changed name regex to allow more characters (the same as PHP - works for blocks, tags, functions, filters, and macros - closes #376)

merged branch nikic/doNotUseNameNodeForFuncNames (PR #410)

Commits
-------

da4d964 Do not use Node_Expression_Name for function names, just use strings for those

Discussion
----------

Do not use Node_Expression_Name for function names

This patch remove the use of Node_Expression_Name for function names and instead uses normal strings for those. This is mainly to prevent problems with static analysis (e.g. using a loop() function would have triggered with_loop), but it also slightly reduces complexity.

Do not use Node_Expression_Name for function names, just use strings for those

removed obsolete code

refactored code

added the possibility to test for exceptions in integration tests

removed the possibility to use the extends tag from a block (as it is semantically incorrect and it probably does not work as you expect it to in this case)

moved Template::getParent() logic to the base class

added documentation for previous merge

fixed unit tests for previous merge

merged branch kotas/master (PR #362)

Commits
-------

f5b9df9 added `if` modifier support to for loop like {% for k in v if k is odd %}

Discussion
----------

[1.2] added `if` modifier support to for loop

Hi.

I'm one of Twig users who love it so much. :)

I've made a patch for adding `if` modifier support to `for` loop in Twig.

Example:
<pre>
{% for n in range(0, 5) if n is odd %}
  {{ n }}
{% endfor %}
</pre>

Output:
<pre>
1
3
5
</pre>

This idea comes from Python's list comprehensions. (like `[n for n in range(0,6) if n % 2 == 1]`)

Here is another example.

Before:
<pre>
{% set no_items = true %}
{% for item in items %}
  {% if item.available %}
    {% set no_items = false %}
    {{ item.name }}
  {% endif %}
{% endfor %}
{% if no_items %}
  No items available.
{% endif %}
</pre>

After:
<pre>
{% for item in items if item.available %}
  {{ item.name }}
{% else %}
  No items available.
{% endfor %}
</pre>

I hope you like it. But If not, just ignore this request. :)

Thanks.

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

by fabpot at 2011/06/24 01:33:33 -0700

I like it! I will schedule it for inclusion in Twig 1.2. Thanks.

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

by hhamon at 2011/06/26 16:43:26 -0700

+1

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

by nikic at 2011/06/27 00:42:14 -0700

I think the idea per se is interesting. But I just checked all Twig templates in my whole codebase and couldn't find any use for it. What was your practical use for this feature @kotas?

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

by kotas at 2011/06/27 01:52:48 -0700

@nikic My practical use is shown as the second example in the body of this pull request.

Sometimes you need to "filter" an array by seeing its element's property like "item.available" or by some condition like "item.price >= 500".

To do this, in the current version of Twig, you have to write "for" and "if" as nested scopes. And if you want to write {% else %} of the "for" loop, you have to make a temporary variable to see if all elements are skipped.

I think this feature is not essential, but makes templates clean.

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

by nikic at 2011/06/27 06:23:24 -0700

The thing about `else` seems plausible. +1

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

by chucktrukk at 2011/08/02 17:39:16 -0700

Also +1. that makes some very clean template code.

added GtkSourceView support in doc

merged branch igorw/recipes-highlight (PR #405)

Commits
-------

0580f19 fix highlighting of snippet in recipes doc

Discussion
----------

fix highlighting of snippet in recipes doc

fix highlighting of snippet in recipes doc

bumped version to 1.2.0-DEV

prepared 1.1.2 released

fixed Parser bug when a child node is null

fixed Parser bug

Add bitwise operators to core

* Added bitwise operators (and, xor, or) to core

fixed unit test, updated CHANGELOG

merged branch JEDIBC/master (PR #401)

Commits
-------

755ea99 Correction of a BC break with json_encode and PHP 5.2.x

Discussion
----------

BC break with json_encode and php 5.2.x

Hi,

json_encode on php 5.2.x doesn't take the $options parameter wich result in a warning and the function return nothing.

Cheers.

Correction of a BC break with json_encode and PHP 5.2.x

simplified code for previous merge/commits

changed previous commit to preserve better BC

fixed CS on template output

updated CHANGELOG

fixed previous merge

merged branch hason/optimizer (PR #399)

Commits
-------

3c5c512 fixed optimization for rendering blocks with variable name

Discussion
----------

Fixed bug in optimization

fixed optimization for rendering blocks with variable name

updated CHANGELOG

fixed inherited templates when an empty body

merged branch netzhuffle/master (PR #396)

Commits
-------

7b154d6 Switched a tab to four spaces
29d3cb2 Added testcase for #395
4fc7a8d Merge remote-tracking branch 'upstream/master'
c890cf2 Fixed existing tests
9822ac4 Changed Module.php to pass existing tests
fab8c72 fixed issue #395

Discussion
----------

Fix for issue #395

Fix for #395
I hope you can use it.

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

by fabpot at 2011/07/25 00:07:50 -0700

Can you add some unit tests?

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

by netzhuffle at 2011/07/25 13:57:55 -0700

Here you are.

removed comment

fixed compilation of templates when the body of a child template is not empty

Switched a tab to four spaces

Added testcase for #395

Merge remote-tracking branch 'upstream/master'

Fixed existing tests

Changed Module.php to pass existing tests

simplified CHANGELOG

updated CHANGELOG

fixed output when a macro throws an exception

fixed PHPDocs for the Token parsers

fixed PHPDocs for the Core extension

merged branch pulse00/master (PR #389)

Commits
-------

351910b added twig comments
2b7e8d9 added phpDocs for TokenParsers, filters and tests

Discussion
----------

PHPDocs updated

fixed copy/paste errors and added docs to Sandbox and Use tags

fixed a parsing problem when a large chunk of text is enclosed in a comment tag

fixed issue #395

added filename when throwing an exception when we know it

added twig comments

added phpDocs for TokenParsers, filters and tests

prepared 1.1.1 release

made a small optimization on Core functions

added an optimization to the Optimizer

updated CHANGELOG

fixed CS

merged branch nikic/improveIsDefinedPerformanceInNonStrictMode (PR #381)

Commits
-------

e4b8371 Improve performance of is defined in non strict mode

Discussion
----------

Improve performance of is defined in non strict mode

Addresses issue #380: This gives a good performance improvement on defined tests in non-strict code. About 2x.

Reasoning: It doesn't make sense to propagate the `is_defined_test` flag into deeper levels in non-strict mode, because all getAttr functions and name accesses will just return `null` if it doesn't exist and `null` is just as good as `false`.

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

by nikic at 2011/07/02 03:22:53 -0700

Though, do not merge yet please. Changes behavior concerning methods.

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

by nikic at 2011/07/02 13:34:32 -0700

Hm, I really don't know what I was thinking when I wrote my last comment. There shouldn't be any behavior changes introduced by that change (and tests pass).

merged branch nikic/optimizeVariableAccess2 (PR #382)

Commits
-------

5b91f12 Update tests
a5ef326 Use Template->getContext in non-strict mode too

Discussion
----------

Use Template->getContext() when in non-strict mode, too

As described in #380 using the current `isset($context['test']) ? $context['test'] : null` approach can cause problems in some cases: The ternary operator always returns by value and thus PHP's copy-on-write concept does not apply. So `$context['test']` needs to be copied in any case, even though a write never happens to it. Basically Twig is copying the values of all variables ever used inside Twig if it operates in non-strict mode. This is problematic when `$context['test']` contains big arrays as the whole array is copied.

In this patch I change Twig to use `Template->getContext` when in non-strict mode too and add an `isStrictVariables` check in there.

merged branch real-chocopanda/ob_fix (PR #379)

Commits
-------

75748a5 revert accidental mode change
681d2b8 fix nested buffers issue #374

Discussion
----------

fix nested buffers issue #374

see #374 for details

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

by fabpot at 2011/07/09 01:02:50 -0700

You have inadvertently changed the mode to 0755. Should stay at 0644.

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

by macolu at 2011/07/09 03:07:42 -0700

Mode change reverted.

About this Windows bug... Are you talking about the zlib issue? When zlib compression is activated, it adds a buffer level that ob_end_clean() can't close. So  ob_get_level() never go below 1.

http://cksource.com/forums/viewtopic.php?t=21653
http://www.php.net/manual/fr/function.ob-get-level.php#52945

In that case, the first ob_get_level() call will always return something greater than 0. So $level var will be > 0. This should avoid infinite loops.

updated VERSION

revert accidental mode change

Update tests

Use Template->getContext in non-strict mode too

Improve performance of is defined in non strict mode

fix nested buffers issue #374

updated CHANGELOG

merged branch markstory/fix-308 (PR #373)

Commits
-------

eaa8995 Grammatical fix.

Discussion
----------

Grammatical fix.

A small grammatical fix for #308 + PR #372

Grammatical fix.

merged branch markstory/fix-308 (PR #372)

Commits
-------

c178c28 Making docs more explict as to what kind of object can be used with Twig_Function_Method. Fixes #308

Discussion
----------

Fix for #308

Making docs more explict as to what kind of object can be used with Twig_Function_Method.
Fixes #308

Making docs more explict as to what kind of object can be
used with Twig_Function_Method.
Fixes #308