This PR was merged into the master branch.
Discussion
----------
Revert "merged branch pierrejoye/master (PR #855)"
This reverts commit 347bc81d6e
This commit make compilation failed for PHP5.2 with thread-safe enabled (see https://travis-ci.org/fabpot/Twig/jobs/5523865)
Commits
-------
4383388 Revert "merged branch pierrejoye/master (PR #855)"
This PR was merged into the master branch.
Commits
-------
c6ef23a Update striptags.rst
Discussion
----------
Update striptags.rst
Hello
I just changed
{% some_html|striptags %}
to
{{ some_html|striptags }}
Regards
Julien
This PR was merged into the master branch.
Commits
-------
59d0eed Update merge.rst
Discussion
----------
Update merge.rst
Typo in first line:
The merge filter merges an array with [removed: the] another array
This PR was merged into the master branch.
Commits
-------
c82308a deprecated use, -4 files to include.
Discussion
----------
Depraceted use of Twig_Filter_Function in Core Extension
Simple fix, that reduces included files count by 4 (in default configuration).
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.
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.
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
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
👍 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
👍 Was actually just looking for this :) When do you think you'll merge this feature into master?
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.
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.
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?
This PR was merged into the master branch.
Commits
-------
9d25425 Fixed typo that messes up with syntax highlighting
Discussion
----------
[Documentation] Fixed typo
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
Fabien Potencier
Tugdual Saunier
specialguest
Pascal Borreli
carlwitt
Tobias Schultze
Michał Pawłowski
Grégoire Pineau
Luiz “Felds” Liscia
Jesper Ek
Javier Eguiluz
Jacek Jędrzejewski
iamdto
Bilal Amarni
Eugene Leonovich