changed an exception to be consistent with other ones (and also to better help debugging problems)

bumped version to 1.12.3-DEV

prepared the 1.12.2 release

updated CHANGELOG

added some unit tests for previous merge

added some missing tests

merged branch andrewjbaker/force-timezone (PR #964)

This PR was merged into the master branch.

Commits
-------

999b1c4 Force timezone setting in date filter

Discussion
----------

Force timezone setting in date filter

In instances where the $time parameter to the DateTime ctor includes a timezone, the $timezone argument is ignored. This functionality extends to the date filter.

http://uk3.php.net/manual/en/datetime.construct.php

"The $timezone parameter and the current timezone are ignored when the $time parameter either is a UNIX timestamp (e.g. @946684800) or specifies a timezone (e.g. 2010-01-28T15:00:00+02:00)."

Accepting this pull request is dependent on whether the desired functionality of the date filter should honour the PHP way of doing things, or the more logical and natural functionality anticipated by a Twig template designer; always ensuring the timezone passed into the date filter is applied.

added a note about how to use quotes in strings (closes #973)

fixed globals when getGlobals is called early on (closes #990)

merged branch deadbeef84/getglobals-before-addglobal-bug (PR #990)

This PR was merged into the master branch.

Commits
-------

667b274 Added unit test for bug when calling getGlobals() before addGlobal() on Twig_Environment.

Discussion
----------

Bug when calling getGlobals() before addGlobal() on Twig_Environment.

There seems to be an issue when calling getGlobals() before addGlobal(), the globals wont get updated. It doesn't seem to matter if the global existed before the call to getGlobals(). An update of the globals can be forced by calling an additional getGlobals() after the addGlobal() call.

I believe the problem has something to do with runtimeInitialized/extensionInitialized being set to true during rendering, but globals don't get updated during that phase.

Not sure how to fix it so I'm just sending you a unit test showcasing the bug.

merged branch lyrixx/patch-5 (PR #989)

This PR was merged into the master branch.

Commits
-------

e2a068d [Doc] Updated template_from_string to use include function

Discussion
----------

[Doc] Updated template_from_string to use include function

instead of include tag

Added unit test for bug when calling getGlobals() before addGlobal() on Twig_Environment.

[Doc] Updated template_from_string to use include function

instead of include tag

merged branch fabpot/first-last (PR #977)

This PR was merged into the master branch.

Commits
-------

f8d4db4 added the first and last filters (closes #951)

Discussion
----------

added the first and last filters (closes #951)

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

by acasademont at 2013-01-26T20:45:23Z

:+1: great! Using twig_slice is a nice thing, we can have string and traversable objects work also with the new filters

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

by jankramer at 2013-01-30T17:39:31Z

:+1: Was actually just looking for this :) When do you think you'll merge this feature into master?

removed list of built-in items in the docs in favor of a link (easier to maintain and better for discoverability)

merged branch javiereguiluz/doc_fixes (PR #982)

This PR was merged into the master branch.

Commits
-------

aac6cb6 Fixes and minor additions to the docs.

Discussion
----------

Fixes and minor additions to the docs.

Fixes and minor additions to the docs.

merged branch eXtreme/patch-1 (PR #978)

This PR was merged into the master branch.

Commits
-------

8f28e78 Missing code-block in doc/templates.rst

Discussion
----------

Missing code-block in doc/templates.rst

Little tweak for docs.

Missing code-block in doc/templates.rst

added the first and last filters (closes #951)

added an exception when trying to render a template when no loader has been set (closes #975)

tweaked previous merge

merged branch rybakit/constant (PR #966)

This PR was merged into the master branch.

Commits
-------

a1b7ec5 Tweak twig_constant()

Discussion
----------

Tweak twig_constant()

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

by Tobion at 2013-01-16T10:52:56Z

Why is it better? The old version returns earlier.

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

by rybakit at 2013-01-16T11:25:39Z

It's better for several reasons, imho:
1. Negation has gone, which is better for perception
2. Single function exit point
3. The same functionality in less code

And what do you mean by "The old version returns earlier"?

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

by Tobion at 2013-01-16T13:33:22Z

It means the old version uses a variable less and we prefer early return statements when possible.

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

by rybakit at 2013-01-16T14:24:26Z

@Tobion, but how could it be "earlier"? In both cases the ```return``` statement goes exactly after the condition check:

1)
```php
if (!$object) {                   // 1. check condition
    return constant($constant);   // 2. return result
}
```
2)
```php
if ($object) {                    // 1. check condition
    // ...
}

return constant($constant);       // 2. return result
```
Do you want to say that case 1) is faster?

merged branch iamdto/master (PR #969)

This PR was merged into the master branch.

Commits
-------

9d25425 Fixed typo that messes up with syntax highlighting

Discussion
----------

[Documentation] Fixed typo

Fixed typo that messes up with syntax highlighting

removed SVN instructions

merged branch bamarni/patch-1 (PR #967)

This PR was merged into the master branch.

Commits
-------

d5de5e6 [doc] Installation - recommended Composer instead of tarball

Discussion
----------

[doc] Installation - recommended Composer instead of tarball

[doc] Installation - recommended Composer instead of tarball

Tweak twig_constant()

bumped version to 1.12.2-DEV

prepared the 1.12.1 release

tweaked previous merge

merged branch markstory/object-constants (PR #961)

This PR was merged into the master branch.

Commits
-------

8bb953c Fix doc block for twig_constant.
c7dafb7 Update documentation for constant()
cb921ce Implement getting constants from objects.
998b367 Add tests for getting constants from instances.

Discussion
----------

Object constants

Implement the changes discussed in #954.

relaxed globals management to avoid a BC break (closes #965)

Force timezone setting in date filter

Fix doc block for twig_constant.

Update documentation for constant()

Implement getting constants from objects.

Add tests for getting constants from instances.

merged branch Taluu/patch-1 (PR #953)

This PR was merged into the master branch.

Commits
-------

79c34d8 Update CHANGELOG

Discussion
----------

Update CHANGELOG

Fixes the year for the latest releases

We're not in 2012 anymore. I think.

Update CHANGELOG

Fixes the year for the latest releases

added support for {{ some_string[:2] }} (closes #952)

bumped version to 1.12.1-DEV

prepared the 1.12.0 release

tweaked CHANGELOG

forbid mixed usage of raw/verbatim

merged branch fabpot/verbatim (PR #947)

This PR was merged into the master branch.

Commits
-------

cd4ab0f renamed the raw tag to verbatim to avoid confusion with the raw filter

Discussion
----------

renamed the raw tag to verbatim to avoid confusion with the raw filter

In Twig, we have a `raw` tag and a raw filter. Unfortunately, they are totally unrelated and that is confusing.

I propose to rename the `raw` tag to `verbatim`. Of course, for BC reasons, the old `raw` tag will be kept around for the foreseeable future as an alias to `verbatim`.

For the record, `raw` is used by Jinja (http://jinja.pocoo.org/docs/templates/#escaping), whereas `verbatim` was introduced in Django in 1.5 (https://docs.djangoproject.com/en/dev/releases/1.5/#verbatim-template-tag).

renamed the raw tag to verbatim to avoid confusion with the raw filter

fixed tests on PHP 5.2

fixed tests on PHP 5.2

fixed registration of tests and functions as anonymous functions (closes #946)

updated license year

Revert "merged branch za-creature/patch-1 (PR #943)"

This reverts commit dc565f781fc885aafaceffe130121526774bc45e, reversing
changes made to 8447ca17185c082831c4d46e416f39bdeba937d9.

merged branch za-creature/patch-1 (PR #943)

This PR was merged into the master branch.

Commits
-------

15be13c Update lib/Twig/Autoloader.php

Discussion
----------

Update lib/Twig/Autoloader.php

Added the ability to register the autoloader at the top of the stack, useful in some situations.

Specifically, I need this because I want the last autoload function registered in my application to throw an exception instead of producing a class not found error, and I need *that* autoloader to be registered before twig's.

merged branch dantleech/globals_not_array (PR #944)

This PR was squashed before being merged into the master branch (closes #944).

Commits
-------

9f5fa53 Upgrade problem

Discussion
----------

Upgrade problem

Hi

When upgrading to HEAD I got the error

Warning: array_key_exists() expects parameter 2 to be array, null given
in /home/daniel/www/DCMS/vendor/twig/twig/lib/Twig/Environment.php line
975

Caused by adding globals in the initRuntime method in my extensions.

This patch makes addGlobal handle the case where Envieonment::$globals is null.

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

by stof at 2012-12-31T14:33:17Z

Your patch does not work properly. It will allow setting the ``bar`` global when you have not called ``getGlobals`` yet now (which is why your new test is failing on Travis)

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

by dantleech at 2012-12-31T14:45:28Z

Yes, sorry, I pushed the wrong version of Environment.php. Tests should pass now.

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

by stof at 2012-12-31T14:55:29Z

I think you are now forbidding to replace an existing global without calling ``getGlobals`` first when the runtime is initialized

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

by dantleech at 2012-12-31T15:12:20Z

I think that this is the correct logic.

Throw the Exception "Unable to add global "%s" as the runtime or  the extensions have already been initialized" IF the global has not already been registered.

So, if ``$globals === null`` then this is indeed the case. The logic is the same, it just supports the default NULL value for $globals. I think.

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

by stof at 2012-12-31T15:52:50Z

no, if ``$globals === null``, it means you have not yet loaded all the globals registered previously, so you cannot know if it has already been registered this way. What you need to do is calling ``initGlobals`` in this case to be sure they are initialized

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

by dantleech at 2013-01-01T09:18:45Z

ok. updated, I think I understand -- so it is required to use ``getGlobals`` to register globals, but we cannot add globals after/during ``initRuntime``. But we could replace them:

````php
public function getGlobals()
{
   return array(
     'existing' => $this->someGlobal
   );
}
pubic function initRuntime(\Twig_Environment $e)
{
  $e->addGlobal('existing', $this->foo);  // OK
  $e->addGlobal('non-existing', $this->bar);  // FAIL
}
````

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

by darklow at 2013-01-02T15:11:46Z

This error also gives us lot of headaches, after any twig file changed first reload, got this error on array_key_exists.
Hopefully this PR could be verified and approved. Thank you.

Upgrade problem

bumped version to 1.12.0-DEV

prepared the 1.12.0-RC1 release

Update lib/Twig/Autoloader.php

Added the ability to register the autoloader at the top of the stack, useful in some situations.

fixed typo in the docs

fixed wrong version in the docs

merged branch fabpot/performance-fix (PR #941)

This PR was merged into the master branch.

Commits
-------

2450f79 changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

Discussion
----------

changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

* Globals are now managed by themselves, independently of other elements
  contained in extensions

* A global variable value can now be changed after the runtime has been
  initialized (to be more BC with the way Twig 1.11 works)

* Extensions are not initialized anymore when rendering a template that
  is already in the cache (like in Twig 1.11)

removed PEAR related code

changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

* Globals are now managed by themselves, independently of other elements
  contained in extensions

* A global variable value can now be changed after the runtime has been
  initialized (to be more BC with the way Twig 1.11 works)

* Extensions are not initialized anymore when rendering a template that
  is already in the cache (like in Twig 1.11)

merged branch fabpot/render-function (PR #926)

This PR was merged into the master branch.

Commits
-------

f4f88a5 added an include function

Discussion
----------

added an include function

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

by stof at 2012-12-09T14:12:25Z

I see an issue with this naming: it will confuse Symfony users because of the ``render`` tag doing something different than the ``render`` function. And it will force to break BC for Silex users where the subrequest logic is using a ``render`` function right now

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

by fabpot at 2012-12-10T12:49:57Z

@stof: I know about the possible confusion. For Silex, as it is not stable yet, we don't need to keep BC. And I don't have any other better name. What I want to introduce next is a `render_request` function in both Silex and Symfony (which will do the same as the current render tag in Symfony and the render function in Silex).

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

by Taluu at 2012-12-10T14:13:31Z

Hi,

I may be absent-minded, but I don't really understand the difference between `render` function and the `include` tag... ?

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

by fabpot at 2012-12-10T14:16:09Z

@Taluu Using a function allows you to do whatever you want with the output (which is not possible with a tag), like a simple:

```jinja
{{ set content = render('some_template') }}
```

Also, semantically, using a tag to output some content is less correct.

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

by vicb at 2012-12-10T14:18:17Z

could it be named `include` ?

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

by tcz at 2012-12-10T14:18:40Z

I agree that it's confusing for Symfony users. It is the same as raw filter and raw tag. I would prefer execute as name or something like that

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

by Taluu at 2012-12-10T14:19:29Z

@fabpot so, does it means that it could replace the include tag ? Then, we could could name it `include` as @vicb suggested... ?

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

by titomiguelcosta at 2012-12-10T14:21:51Z

I agree with @stof, naming it render will be confusing, parse or execute or compile are other names that come to my mind for this purpose.

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

by silentworks at 2012-12-10T14:24:36Z

How about calling it `partial`? even though you are rendering a full template, it is being included in another so this could be seeing as a partial of that template.

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

by stof at 2012-12-10T14:26:05Z

@titomiguelcosta parse is totally wrong. The function is not parsing the string you give it. you don't pass the content of the template but its name. and ``compile`` is also wrong. It is not compiling a template but rendering it.

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

by jmather at 2012-12-10T14:30:53Z

I think `render` is probably the most appropriate name, but also may cause confusion, however I don't have another suggestion that is nearly as clear as to context and meaning.

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

by emgiezet at 2012-12-10T14:31:26Z

Can you pass the array of params as an argument to the `render` function?

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

by titomiguelcosta at 2012-12-10T14:31:59Z

@stof true that we pass the filename as argument, but we end up parsing the file.

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

by stof at 2012-12-10T14:32:48Z

@emgiezet you mean passing some variables available in the included template ? Sure you can. See the doc. the argument is named ``variables``

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

by stof at 2012-12-10T14:34:36Z

@titomiguelcosta But the goal of the function is not to parse the file (btw, it may not parse it if the template was already compiled in the cache). The goal is to render the template.

Btw, I agree with @jmather. As far as Twig is concerned, ``render`` is the best name. The only issue comes from the fact that Symfony already use a ``{% render %}`` tag with a different meaning

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

by emgiezet at 2012-12-10T14:39:02Z

@stof thx a lot didn't noticed the doc link. Maybe `render_partial` will be good in this case?

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

by tcz at 2012-12-10T14:44:13Z

In an ideal world the Symfony2 `render` tag would be renamed to `subrequest` or something like that and the new function in Twig would get the `render` name. The question is how many people use Twig because of Symfony2 and how many of them use it in itself (in my company we use standalone Twig for example).

I think it's important to avoid `raw`-style confusions for the former group.

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

by stof at 2012-12-10T15:16:28Z

@tcz The issue with renaming the tag in Symfony is that it would be a BC break. So we cannot simply drop the tag (we can provide a new name and deprecate the current one, but we would still keep it).

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

by Taluu at 2012-12-10T15:18:56Z

I think `partial` would be a good idea... But still, does it mean that the `include` tag would be deprecated in favor of `render` (or whatever the name will be) function ?

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

by tcz at 2012-12-10T15:19:49Z

@stof Yes :( hence my remark "in an ideal world"

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

by stof at 2012-12-10T15:27:52Z

@Taluu It depends if @fabpot wants to keep the compatibility with Jinja where possible (as it is where the ``include`` tag comes from)

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

by WouterJ at 2012-12-10T15:48:26Z

I like the function, but I don't like the name. I like the name `partial`.

I am a front-end developer from origin and all files you include in the base CSS stylesheet are called 'partials' in SASS or other preprosessors. Twig is used to make live easier for front-end developers and I think a function called `partial` is more familiair for them than `render`.

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

by silentworks at 2012-12-10T16:17:24Z

@stof I guess based on @fabpot wanting to keep Twig compatibility with Jinja, calling the tag `partial` rather than `render` shouldn't be a problem since Jinja doesn't have any of these.

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

by Taluu at 2012-12-10T16:19:25Z

@silentworks @stof was talking about my question, about why keep the `include` tag if the `render` (or whatever the name will be) is indeed inserted into Twig. :)

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

by stof at 2012-12-10T16:19:38Z

@silentworks I was not talking about the name of the function, but about the removal of the ``include`` tag

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

by silentworks at 2012-12-10T16:22:37Z

Thanks for clarity from both.

On the basis of keeping to conformity to Jinja, should this function not be a part of twig extensions rather than in the core?

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

by mvrhov at 2012-12-10T17:20:03Z

Well search and replace for symfony users when upgrading shouldn't be that hard so I'd say that we rename the symfony block into subrequest or sth similar.

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

by Taluu at 2012-12-10T17:26:22Z

If we were to follow your recommandations, we could say the same for all and every changes inducing a BC break huh...

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

by markstory at 2012-12-10T17:49:36Z

What about naming the function `include`?  It would share a name with the tag, but it also does the same type of thing as the tag.  The function has the advantage of having its return captured.  I think  `{{ include(template) }}` semantically does what it looks like it does when operating on the template object as well.

Other names that I think could fit well are `partial` and `display`. Render works well, but I understand people not wanting to overlap with existing symfony features that do very different things.

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

by Baachi at 2012-12-10T18:13:25Z

I think "partial" is a better name for this function and it would keep BC.

merged branch Baachi/fix-simple (PR #939)

This PR was merged into the master branch.

Commits
-------

a311fe0 Fix the registration of simple filters, test and functions

Discussion
----------

Fix the registration of simple filters, test and functions

Hey!

This PR fix the registration of `Twig_SimpleFilter`, `Twig_SimpleFunction` and `Twig_SimpleTest`.
See issue #937

Fix the registration of simple filters, test and functions

added an include function

added emacs in the IDE support section of the docs

fixed small typo in the docs

fixed regression

merged branch fabpot/callables-everywhere (PR #905)

This PR was merged into the master branch.

Commits
-------

1918ede added the ability to use any PHP callable to define filters, functions, and tests

Discussion
----------

added the ability to use any PHP callable to define filters, functions, and tests

Everything is in the title.

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

by Tobion at 2012-11-18T13:25:51Z

Are filters etc. slower when defined as closures (instead of function definitions)?

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

by fabpot at 2012-11-18T13:30:47Z

@Tobion No, it does not matter how they are defined. Speed will be the same. A function is probably slightly faster as we can optimize the compiled template more than when it is an anonymous function where we need to use `call_user_func`.

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

by Tobion at 2012-11-18T13:40:17Z

This slight difference is what I questioned. On top of that, PHP can also not precompile those `call_user_func` I guess (e.g. when using APC). But it's probably not a big deal.
Since you have many examples in the doc with closures, I hope that it does not become the standard way for people to define custom functions.

merged branch fabpot/loop-errors (PR #927)

This PR was merged into the master branch.

Commits
-------

811dfad added a syntax error when using a loop variable that is not defined (closes #925)
aa15cae simplified code

Discussion
----------

added a syntax error when using a loop variable that is not defined

refs #925

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

by stof at 2012-12-10T15:18:30Z

in the ifexpr, you should also check for ``loop.index`` & co as they are not yet incremented (and so cannot be used properly)

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

by fabpot at 2012-12-10T20:07:08Z

@stof fixed

added a syntax error when using a loop variable that is not defined (closes #925)

simplified code

added @deprecated tags on deprecated classes

added the ability to use any PHP callable to define filters, functions, and tests

added Twig_TemplateInterface in the list of deprecated interfaces

added a note about deprecated interfaces

added a note about the PEAR package

moved some code to the proper location

added an exception when misusing macro calls (refs #922)

merged branch javiereguiluz/master (PR #923)

This PR was merged into the master branch.

Commits
-------

33539fc Fixed a typo in the 'escape' filter documentation.

Discussion
----------

Fixed a typo in the 'escape' filter documentation.

This typo prevents the proper rendering of one code block.

Fixed a typo in the 'escape' filter documentation.

This typo prevents the proper rendering of one code block.

merged branch fabpot/twig-c-bug (PR #920)

This PR was merged into the master branch.

Commits
-------

df13370 added a missing test
33e690b fixed some tests when the extension is not enabled
51e707f merged branch char101/fix-ext-retval (PR #921)
014f459 added some missing test for Template::getAttribute()
e8d12da Fix empty string comparison
4311df3 added some missing test for Template::getAttribute()

Discussion
----------

The C extension does not behave in the same way as the PHP code

The added test shows that the C extension does not behave in the same way as the PHP code. I have no idea why. The problem is probably around line 1033 in the extension code: https://github.com/fabpot/Twig/blob/master/ext/twig/twig.c#L1033

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

by stof at 2012-12-05T17:07:00Z

The testsuite is broken when you run it without the C Twig extension. The test should be skipped when ``useExt`` is ``true`` and the extension is not available

added a missing test

fixed some tests when the extension is not enabled

merged branch char101/fix-ext-retval (PR #921)

This PR was merged into the twig-c-bug branch.

Commits
-------

e8d12da Fix empty string comparison
4311df3 added some missing test for Template::getAttribute()

Discussion
----------

Fix empty string comparison

Issue #920

added some missing test for Template::getAttribute()

Fix empty string comparison

added some missing test for Template::getAttribute()

removed uneeded condition (a filter node cannot be created if the filer does not exist)

added missing tests for sandbox support in Template::getAttribute()

added some missing tests for getAttribute (for isXXX methods)

merged branch fabpot/extension-registration (PR #917)

This PR was merged into the master branch.

Commits
-------

4487387 reverted the early registration of extensions (extensions are now loaded as before -- as late as possible) -- closes #910

Discussion
----------

reverted the early registration of extensions (extensions are now loaded as before -- as late as possible)

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

by stof at 2012-11-30T20:18:51Z

Looks good to me

reverted the early registration of extensions (extensions are now loaded as before -- as late as possible) -- closes #910

fixed typo

added some unit for previous merge

merged branch arthens/master (PR #916)

This PR was merged into the master branch.

Commits
-------

16dc94e Fix broken variable reference

Discussion
----------

Fix broken variable reference

The exception message is referencing a non-existing variable $token, renamed to $tokens.

Fix broken variable reference