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
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.
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.
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).
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.
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.
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)
Jesper Ek
Fabien Potencier
Javier Eguiluz
Jacek Jędrzejewski
iamdto
Bilal Amarni
Eugene Leonovich
Mark Story
Baptiste Clavié
dantleech
za-creature