Final website

Twig/.editorconfig

+; top-most EditorConfig file
+root = true
+
+; Unix-style newlines
+[*]
+end_of_line = LF
+
+[*.php]
+indent_style = space
+indent_size = 4
+
+[*.test]
+indent_style = space
+indent_size = 4
+
+[*.rst]
+indent_style = space
+indent_size = 4

Twig/.gitignore

+/build
+/composer.lock
+/ext/twig/autom4te.cache/
+/phpunit.xml
+/vendor

Twig/.php_cs.dist

+<?php
+
+return PhpCsFixer\Config::create()
+    ->setRules([
+        '@Symfony' => true,
+        '@Symfony:risky' => true,
+        'array_syntax' => ['syntax' => 'short'],
+        'php_unit_fqcn_annotation' => true,
+        'no_unreachable_default_argument_value' => false,
+        'braces' => ['allow_single_line_closure' => true],
+        'heredoc_to_nowdoc' => false,
+        'ordered_imports' => true,
+        'phpdoc_types_order' => ['null_adjustment' => 'always_last', 'sort_algorithm' => 'none'],
+        'native_function_invocation' => ['include' => ['@compiler_optimized'], 'scope' => 'all'],
+    ])
+    ->setRiskyAllowed(true)
+    ->setFinder(PhpCsFixer\Finder::create()->in(__DIR__))
+;

Twig/.travis.yml

+language: php
+
+sudo: false
+
+cache:
+    directories:
+        - vendor
+        - $HOME/.composer/cache/files
+
+php:
+    - 5.4
+    - 5.5
+    - 5.6
+    - 7.0
+    - 7.1
+    - 7.2
+    - 7.3
+
+env:
+    - TWIG_EXT=no
+
+before_install:
+    # turn off XDebug
+    - phpenv config-rm xdebug.ini || return 0
+
+install:
+    - travis_retry composer install
+
+before_script:
+    - if [ "$TWIG_EXT" == "yes" ]; then sh -c "cd ext/twig && phpize && ./configure --enable-twig && make && make install"; fi
+    - if [ "$TWIG_EXT" == "yes" ]; then echo "extension=twig.so" >> `php --ini | grep "Loaded Configuration" | sed -e "s|.*:\s*||"`; fi
+
+script: ./vendor/bin/simple-phpunit
+
+matrix:
+    fast_finish: true
+    include:
+        - php: 5.4
+          env: TWIG_EXT=yes
+        - php: 5.5
+          env: TWIG_EXT=yes
+        - php: 5.6
+          env: TWIG_EXT=yes

Twig/LICENSE

+Copyright (c) 2009-2019 by the Twig Team.
+
+Some rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+    * Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+
+    * Redistributions in binary form must reproduce the above
+      copyright notice, this list of conditions and the following
+      disclaimer in the documentation and/or other materials provided
+      with the distribution.
+
+    * The names of the contributors may not be used to endorse or
+      promote products derived from this software without specific
+      prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Twig/README.rst

+Twig, the flexible, fast, and secure template language for PHP
+==============================================================
+
+Twig is a template language for PHP, released under the new BSD license (code
+and documentation).
+
+Twig uses a syntax similar to the Django and Jinja template languages which
+inspired the Twig runtime environment.
+
+More Information
+----------------
+
+Read the `documentation`_ for more information.
+
+.. _documentation: https://twig.symfony.com/documentation

Twig/composer.json

+{
+    "name": "twig/twig",
+    "type": "library",
+    "description": "Twig, the flexible, fast, and secure template language for PHP",
+    "keywords": ["templating"],
+    "homepage": "https://twig.symfony.com",
+    "license": "BSD-3-Clause",
+    "authors": [
+        {
+            "name": "Fabien Potencier",
+            "email": "fabien@symfony.com",
+            "homepage": "http://fabien.potencier.org",
+            "role": "Lead Developer"
+        },
+        {
+            "name": "Twig Team",
+            "homepage": "https://twig.symfony.com/contributors",
+            "role": "Contributors"
+        },
+        {
+            "name": "Armin Ronacher",
+            "email": "armin.ronacher@active-4.com",
+            "role": "Project Founder"
+        }
+    ],
+    "require": {
+        "php": ">=5.4.0",
+        "symfony/polyfill-ctype": "^1.8"
+    },
+    "require-dev": {
+        "symfony/phpunit-bridge": "^3.4.19|^4.1.8",
+        "symfony/debug": "^2.7",
+        "psr/container": "^1.0"
+    },
+    "autoload": {
+        "psr-0" : {
+            "Twig_" : "lib/"
+        },
+        "psr-4" : {
+            "Twig\\" : "src/"
+        }
+    },
+    "extra": {
+        "branch-alias": {
+            "dev-master": "1.39-dev"
+        }
+    }
+}

Twig/doc/coding_standards.rst

+Coding Standards
+================
+
+When writing Twig templates, we recommend you to follow these official coding
+standards:
+
+* Put one (and only one) space after the start of a delimiter (``{{``, ``{%``,
+  and ``{#``) and before the end of a delimiter (``}}``, ``%}``, and ``#}``):
+
+  .. code-block:: jinja
+
+    {{ foo }}
+    {# comment #}
+    {% if foo %}{% endif %}
+
+  When using the whitespace control character, do not put any spaces between
+  it and the delimiter:
+
+  .. code-block:: jinja
+
+    {{- foo -}}
+    {#- comment -#}
+    {%- if foo -%}{%- endif -%}
+
+* Put one (and only one) space before and after the following operators:
+  comparison operators (``==``, ``!=``, ``<``, ``>``, ``>=``, ``<=``), math
+  operators (``+``, ``-``, ``/``, ``*``, ``%``, ``//``, ``**``), logic
+  operators (``not``, ``and``, ``or``), ``~``, ``is``, ``in``, and the ternary
+  operator (``?:``):
+
+  .. code-block:: jinja
+
+     {{ 1 + 2 }}
+     {{ foo ~ bar }}
+     {{ true ? true : false }}
+
+* Put one (and only one) space after the ``:`` sign in hashes and ``,`` in
+  arrays and hashes:
+
+  .. code-block:: jinja
+
+     {{ [1, 2, 3] }}
+     {{ {'foo': 'bar'} }}
+
+* Do not put any spaces after an opening parenthesis and before a closing
+  parenthesis in expressions:
+
+  .. code-block:: jinja
+
+    {{ 1 + (2 * 3) }}
+
+* Do not put any spaces before and after string delimiters:
+
+  .. code-block:: jinja
+
+    {{ 'foo' }}
+    {{ "foo" }}
+
+* Do not put any spaces before and after the following operators: ``|``,
+  ``.``, ``..``, ``[]``:
+
+  .. code-block:: jinja
+
+    {{ foo|upper|lower }}
+    {{ user.name }}
+    {{ user[name] }}
+    {% for i in 1..12 %}{% endfor %}
+
+* Do not put any spaces before and after the parenthesis used for filter and
+  function calls:
+
+  .. code-block:: jinja
+
+     {{ foo|default('foo') }}
+     {{ range(1..10) }}
+
+* Do not put any spaces before and after the opening and the closing of arrays
+  and hashes:
+
+  .. code-block:: jinja
+
+     {{ [1, 2, 3] }}
+     {{ {'foo': 'bar'} }}
+
+* Use lower cased and underscored variable names:
+
+  .. code-block:: jinja
+
+     {% set foo = 'foo' %}
+     {% set foo_bar = 'foo' %}
+
+* Indent your code inside tags (use the same indentation as the one used for
+  the target language of the rendered template):
+
+  .. code-block:: jinja
+
+     {% block foo %}
+         {% if true %}
+             true
+         {% endif %}
+     {% endblock %}

Twig/doc/deprecated.rst

+Deprecated Features
+===================
+
+This document lists all deprecated features in Twig. Deprecated features are
+kept for backward compatibility and removed in the next major release (a
+feature that was deprecated in Twig 1.x is removed in Twig 2.0).
+
+Deprecation Notices
+-------------------
+
+As of Twig 1.21, Twig generates deprecation notices when a template uses
+deprecated features. See :ref:`deprecation-notices` for more information.
+
+Macros
+------
+
+As of Twig 2.0, macros imported in a file are not available in child templates
+anymore (via an ``include`` call for instance). You need to import macros
+explicitly in each file where you are using them.
+
+Token Parsers
+-------------
+
+* As of Twig 1.x, the token parser broker sub-system is deprecated. The
+  following class and interface will be removed in 2.0:
+
+  * ``Twig_TokenParserBrokerInterface``
+  * ``Twig_TokenParserBroker``
+
+* As of Twig 1.27, ``\Twig\Parser::getFilename()`` is deprecated. From a token
+  parser, use ``$this->parser->getStream()->getSourceContext()->getPath()`` instead.
+
+* As of Twig 1.27, ``\Twig\Parser::getEnvironment()`` is deprecated.
+
+Extensions
+----------
+
+* As of Twig 1.x, the ability to remove an extension is deprecated and the
+  ``\Twig\Environment::removeExtension()`` method will be removed in 2.0.
+
+* As of Twig 1.23, the ``\Twig\Extension\ExtensionInterface::initRuntime()`` method is
+  deprecated. You have two options to avoid the deprecation notice: if you
+  implement this method to store the environment for your custom filters,
+  functions, or tests, use the ``needs_environment`` option instead; if you
+  have more complex needs, explicitly implement
+  ``\Twig\Extension\InitRuntimeInterface`` (not recommended).
+
+* As of Twig 1.23, the ``\Twig\Extension\ExtensionInterface::getGlobals()`` method is
+  deprecated. Implement ``\Twig\Extension\GlobalsInterface`` to avoid
+  deprecation notices.
+
+* As of Twig 1.26, the ``\Twig\Extension\ExtensionInterface::getName()`` method is
+  deprecated and it is not used internally anymore.
+
+PEAR
+----
+
+PEAR support has been discontinued in Twig 1.15.1, and no PEAR packages are
+provided anymore. Use Composer instead.
+
+Filters
+-------
+
+* As of Twig 1.x, use ``\Twig\TwigFilter`` to add a filter. The following
+  classes and interfaces will be removed in 2.0:
+
+  * ``Twig_FilterInterface``
+  * ``Twig_FilterCallableInterface``
+  * ``Twig_Filter``
+  * ``Twig_Filter_Function``
+  * ``Twig_Filter_Method``
+  * ``Twig_Filter_Node``
+
+* As of Twig 2.x, the ``\Twig\TwigFilter`` class is deprecated and will be
+  removed in Twig 3.x (use ``Twig_Filter`` instead). In Twig 2.x,
+  ``\Twig\TwigFilter`` is just an alias for ``Twig_Filter``.
+
+Functions
+---------
+
+* As of Twig 1.x, use ``\Twig\TwigFunction`` to add a function. The following
+  classes and interfaces will be removed in 2.0:
+
+  * ``Twig_FunctionInterface``
+  * ``Twig_FunctionCallableInterface``
+  * ``Twig_Function``
+  * ``Twig_Function_Function``
+  * ``Twig_Function_Method``
+  * ``Twig_Function_Node``
+
+* As of Twig 2.x, the ``\Twig\TwigFunction`` class is deprecated and will be
+  removed in Twig 3.x (use ``Twig_Function`` instead). In Twig 2.x,
+  ``\Twig\TwigFunction`` is just an alias for ``Twig_Function``.
+
+Tests
+-----
+
+* As of Twig 1.x, use ``\Twig\TwigTest`` to add a test. The following classes
+  and interfaces will be removed in 2.0:
+
+  * ``Twig_TestInterface``
+  * ``Twig_TestCallableInterface``
+  * ``Twig_Test``
+  * ``Twig_Test_Function``
+  * ``Twig_Test_Method``
+  * ``Twig_Test_Node``
+
+* As of Twig 2.x, the ``\Twig\TwigTest`` class is deprecated and will be
+  removed in Twig 3.x (use ``Twig_Test`` instead). In Twig 2.x,
+  ``\Twig\TwigTest`` is just an alias for ``Twig_Test``.
+
+* The ``sameas`` and ``divisibleby`` tests are deprecated in favor of ``same
+  as`` and ``divisible by`` respectively.
+
+Tags
+----
+
+* As of Twig 1.x, the ``raw`` tag is deprecated. You should use ``verbatim``
+  instead.
+
+Nodes
+-----
+
+* As of Twig 1.x, ``Node::toXml()`` is deprecated and will be removed in Twig
+  2.0.
+
+* As of Twig 1.26, ``Node::$nodes`` should only contains ``\Twig\Node\Node``
+  instances, storing a ``null`` value is deprecated and won't be possible in
+  Twig 2.x.
+
+* As of Twig 1.27, the ``filename`` attribute on ``\Twig\Node\ModuleNode`` is
+  deprecated. Use ``getName()`` instead.
+
+* As of Twig 1.27, the ``\Twig\Node\Node::getFilename()/\Twig\Node\Node::getLine()``
+  methods are deprecated, use
+  ``\Twig\Node\Node::getTemplateName()/\Twig\Node\Node::getTemplateLine()`` instead.
+
+Interfaces
+----------
+
+* As of Twig 2.x, the following interfaces are deprecated and empty (they will
+  be removed in Twig 3.0):
+
+* ``Twig_CompilerInterface``     (use ``\Twig\Compiler`` instead)
+* ``Twig_LexerInterface``        (use ``\Twig\Lexer`` instead)
+* ``Twig_NodeInterface``         (use ``\Twig\Node\Node`` instead)
+* ``Twig_ParserInterface``       (use ``\Twig\Parser`` instead)
+* ``\Twig\Loader\ExistsLoaderInterface`` (merged with ``\Twig\Loader\LoaderInterface``)
+* ``\Twig\Loader\SourceContextLoaderInterface`` (merged with ``\Twig\Loader\LoaderInterface``)
+* ``Twig_TemplateInterface``     (use ``\Twig\Template`` instead, and use
+  those constants \Twig\Template::ANY_CALL, \Twig\Template::ARRAY_CALL,
+  \Twig\Template::METHOD_CALL)
+
+Compiler
+--------
+
+* As of Twig 1.26, the ``\Twig\Compiler::getFilename()`` has been deprecated.
+  You should not use it anyway as its values is not reliable.
+
+* As of Twig 1.27, the ``\Twig\Compiler::addIndentation()`` has been deprecated.
+  Use ``\Twig\Compiler::write('')`` instead.
+
+Loaders
+-------
+
+* As of Twig 1.x, ``Twig_Loader_String`` is deprecated and will be removed in
+  2.0. You can render a string via ``\Twig\Environment::createTemplate()``.
+
+* As of Twig 1.27, ``\Twig\Loader\LoaderInterface::getSource()`` is deprecated.
+  Implement ``\Twig\Loader\SourceContextLoaderInterface`` instead and use
+  ``getSourceContext()``.
+
+Node Visitors
+-------------
+
+* Because of the removal of ``Twig_NodeInterface`` in 2.0, you need to extend
+  ``\Twig\NodeVisitor\AbstractNodeVisitor`` instead of implementing ``\Twig\NodeVisitor\NodeVisitorInterface``
+  directly to make your node visitors compatible with both Twig 1.x and 2.x.
+
+Globals
+-------
+
+* As of Twig 2.x, the ability to register a global variable after the runtime
+  or the extensions have been initialized is not possible anymore (but
+  changing the value of an already registered global is possible).
+
+* As of Twig 1.x, using the ``_self`` global variable to get access to the
+  current ``\Twig\Template`` instance is deprecated; most usages only need the
+  current template name, which will continue to work in Twig 2.0. In Twig 2.0,
+  ``_self`` returns the current template name instead of the current
+  ``\Twig\Template`` instance. If you are using ``{{ _self.templateName }}``,
+  just replace it with ``{{ _self }}``.
+
+Miscellaneous
+-------------
+
+* As of Twig 1.x, ``\Twig\Environment::clearTemplateCache()``,
+  ``\Twig\Environment::writeCacheFile()``,
+  ``\Twig\Environment::clearCacheFiles()``,
+  ``\Twig\Environment::getCacheFilename()``,
+  ``\Twig\Environment::getTemplateClassPrefix()``,
+  ``\Twig\Environment::getLexer()``, ``\Twig\Environment::getParser()``, and
+  ``\Twig\Environment::getCompiler()`` are deprecated and will be removed in 2.0.
+
+* As of Twig 1.x, ``\Twig\Template::getEnvironment()`` and
+  ``Twig_TemplateInterface::getEnvironment()`` are deprecated and will be
+  removed in 2.0.
+
+* As of Twig 1.21, setting the environment option ``autoescape`` to ``true`` is
+  deprecated and will be removed in 2.0. Use ``"html"`` instead.
+
+* As of Twig 1.27, ``\Twig\Error\Error::getTemplateFile()`` and
+  ``\Twig\Error\Error::setTemplateFile()`` are deprecated. Use
+  ``\Twig\Error\Error::getTemplateName()`` and ``\Twig\Error\Error::setTemplateName()``
+  instead.
+
+* As of Twig 1.27, ``\Twig\Template::getSource()`` is deprecated. Use
+  ``\Twig\Template::getSourceContext()`` instead.
+
+* As of Twig 1.27, ``\Twig\Parser::addHandler()`` and
+  ``\Twig\Parser::addNodeVisitor()`` are deprecated and will be removed in 2.0.
+
+* As of Twig 1.29, some classes are marked as being final via the `@final`
+  annotation. Those classes will be marked as final in 2.0.

Twig/doc/filters/abs.rst

+``abs``
+=======
+
+The ``abs`` filter returns the absolute value.
+
+.. code-block:: jinja
+
+    {# number = -5 #}
+
+    {{ number|abs }}
+
+    {# outputs 5 #}
+
+.. note::
+
+    Internally, Twig uses the PHP `abs`_ function.
+
+.. _`abs`: https://secure.php.net/abs

Twig/doc/filters/batch.rst

+``batch``
+=========
+
+.. versionadded:: 1.12.3
+    The ``batch`` filter was added in Twig 1.12.3.
+
+The ``batch`` filter "batches" items by returning a list of lists with the
+given number of items. A second parameter can be provided and used to fill in
+missing items:
+
+.. code-block:: jinja
+
+    {% set items = ['a', 'b', 'c', 'd', 'e', 'f', 'g'] %}
+
+    <table>
+    {% for row in items|batch(3, 'No item') %}
+        <tr>
+            {% for column in row %}
+                <td>{{ column }}</td>
+            {% endfor %}
+        </tr>
+    {% endfor %}
+    </table>
+
+The above example will be rendered as:
+
+.. code-block:: jinja
+
+    <table>
+        <tr>
+            <td>a</td>
+            <td>b</td>
+            <td>c</td>
+        </tr>
+        <tr>
+            <td>d</td>
+            <td>e</td>
+            <td>f</td>
+        </tr>
+        <tr>
+            <td>g</td>
+            <td>No item</td>
+            <td>No item</td>
+        </tr>
+    </table>
+
+Arguments
+---------
+
+* ``size``: The size of the batch; fractional numbers will be rounded up
+* ``fill``: Used to fill in missing items

Twig/doc/filters/capitalize.rst

+``capitalize``
+==============
+
+The ``capitalize`` filter capitalizes a value. The first character will be
+uppercase, all others lowercase:
+
+.. code-block:: jinja
+
+    {{ 'my first car'|capitalize }}
+
+    {# outputs 'My first car' #}

Twig/doc/filters/convert_encoding.rst

+``convert_encoding``
+====================
+
+.. versionadded:: 1.4
+    The ``convert_encoding`` filter was added in Twig 1.4.
+
+The ``convert_encoding`` filter converts a string from one encoding to
+another. The first argument is the expected output charset and the second one
+is the input charset:
+
+.. code-block:: jinja
+
+    {{ data|convert_encoding('UTF-8', 'iso-2022-jp') }}
+
+.. note::
+
+    This filter relies on the `iconv`_ or `mbstring`_ extension, so one of
+    them must be installed. In case both are installed, `mbstring`_ is used by
+    default (Twig before 1.8.1 uses `iconv`_ by default).
+
+Arguments
+---------
+
+* ``to``:   The output charset
+* ``from``: The input charset
+
+.. _`iconv`:    https://secure.php.net/iconv
+.. _`mbstring`: https://secure.php.net/mbstring

Twig/doc/filters/date.rst

+``date``
+========
+
+.. versionadded:: 1.1
+    The timezone support has been added in Twig 1.1.
+
+.. versionadded:: 1.5
+    The default date format support has been added in Twig 1.5.
+
+.. versionadded:: 1.6.1
+    The default timezone support has been added in Twig 1.6.1.
+
+.. versionadded:: 1.11.0
+    The introduction of the false value for the timezone was introduced in Twig 1.11.0
+
+The ``date`` filter formats a date to a given format:
+
+.. code-block:: jinja
+
+    {{ post.published_at|date("m/d/Y") }}
+
+The format specifier is the same as supported by `date`_,
+except when the filtered data is of type `DateInterval`_, when the format must conform to
+`DateInterval::format`_ instead.
+
+The ``date`` filter accepts strings (it must be in a format supported by the
+`strtotime`_ function), `DateTime`_ instances, or `DateInterval`_ instances. For
+instance, to display the current date, filter the word "now":
+
+.. code-block:: jinja
+
+    {{ "now"|date("m/d/Y") }}
+
+To escape words and characters in the date format use ``\\`` in front of each
+character:
+
+.. code-block:: jinja
+
+    {{ post.published_at|date("F jS \\a\\t g:ia") }}
+
+If the value passed to the ``date`` filter is ``null``, it will return the
+current date by default. If an empty string is desired instead of the current
+date, use a ternary operator:
+
+.. code-block:: jinja
+
+    {{ post.published_at is empty ? "" : post.published_at|date("m/d/Y") }}
+
+If no format is provided, Twig will use the default one: ``F j, Y H:i``. This
+default can be easily changed by calling the ``setDateFormat()`` method on the
+``core`` extension instance. The first argument is the default format for
+dates and the second one is the default format for date intervals:
+
+.. code-block:: php
+
+    $twig = new \Twig\Environment($loader);
+    $twig->getExtension('\Twig\Extension\CoreExtension')->setDateFormat('d/m/Y', '%d days');
+
+    // before Twig 1.26
+    $twig->getExtension('core')->setDateFormat('d/m/Y', '%d days');
+
+Timezone
+--------
+
+By default, the date is displayed by applying the default timezone (the one
+specified in php.ini or declared in Twig -- see below), but you can override
+it by explicitly specifying a timezone:
+
+.. code-block:: jinja
+
+    {{ post.published_at|date("m/d/Y", "Europe/Paris") }}
+
+If the date is already a DateTime object, and if you want to keep its current
+timezone, pass ``false`` as the timezone value:
+
+.. code-block:: jinja
+
+    {{ post.published_at|date("m/d/Y", false) }}
+
+The default timezone can also be set globally by calling ``setTimezone()``:
+
+.. code-block:: php
+
+    $twig = new \Twig\Environment($loader);
+    $twig->getExtension('\Twig\Extension\CoreExtension')->setTimezone('Europe/Paris');
+
+    // before Twig 1.26
+    $twig->getExtension('core')->setTimezone('Europe/Paris');
+
+Arguments
+---------
+
+* ``format``:   The date format
+* ``timezone``: The date timezone
+
+.. _`strtotime`:            https://secure.php.net/strtotime
+.. _`DateTime`:             https://secure.php.net/DateTime
+.. _`DateInterval`:         https://secure.php.net/DateInterval
+.. _`date`:                 https://secure.php.net/date
+.. _`DateInterval::format`: https://secure.php.net/DateInterval.format

Twig/doc/filters/date_modify.rst

+``date_modify``
+===============
+
+.. versionadded:: 1.9.0
+    The date_modify filter has been added in Twig 1.9.0.
+
+The ``date_modify`` filter modifies a date with a given modifier string:
+
+.. code-block:: jinja
+
+    {{ post.published_at|date_modify("+1 day")|date("m/d/Y") }}
+
+The ``date_modify`` filter accepts strings (it must be in a format supported
+by the `strtotime`_ function) or `DateTime`_ instances. You can easily combine
+it with the :doc:`date<date>` filter for formatting.
+
+Arguments
+---------
+
+* ``modifier``: The modifier
+
+.. _`strtotime`: https://secure.php.net/strtotime
+.. _`DateTime`:  https://secure.php.net/DateTime

Twig/doc/filters/default.rst

+``default``
+===========
+
+The ``default`` filter returns the passed default value if the value is
+undefined or empty, otherwise the value of the variable:
+
+.. code-block:: jinja
+
+    {{ var|default('var is not defined') }}
+
+    {{ var.foo|default('foo item on var is not defined') }}
+
+    {{ var['foo']|default('foo item on var is not defined') }}
+
+    {{ ''|default('passed var is empty')  }}
+
+When using the ``default`` filter on an expression that uses variables in some
+method calls, be sure to use the ``default`` filter whenever a variable can be
+undefined:
+
+.. code-block:: jinja
+
+    {{ var.method(foo|default('foo'))|default('foo') }}
+
+.. note::
+
+    Read the documentation for the :doc:`defined<../tests/defined>` and
+    :doc:`empty<../tests/empty>` tests to learn more about their semantics.
+
+Arguments
+---------
+
+* ``default``: The default value

Twig/doc/filters/escape.rst

+``escape``
+==========
+
+.. versionadded:: 1.9.0
+    The ``css``, ``url``, and ``html_attr`` strategies were added in Twig
+    1.9.0.
+
+.. versionadded:: 1.14.0
+    The ability to define custom escapers was added in Twig 1.14.0.
+
+The ``escape`` filter escapes a string for safe insertion into the final
+output. It supports different escaping strategies depending on the template
+context.
+
+By default, it uses the HTML escaping strategy:
+
+.. code-block:: jinja
+
+    {{ user.username|escape }}
+
+For convenience, the ``e`` filter is defined as an alias:
+
+.. code-block:: jinja
+
+    {{ user.username|e }}
+
+The ``escape`` filter can also be used in other contexts than HTML thanks to
+an optional argument which defines the escaping strategy to use:
+
+.. code-block:: jinja
+
+    {{ user.username|e }}
+    {# is equivalent to #}
+    {{ user.username|e('html') }}
+
+And here is how to escape variables included in JavaScript code:
+
+.. code-block:: jinja
+
+    {{ user.username|escape('js') }}
+    {{ user.username|e('js') }}
+
+The ``escape`` filter supports the following escaping strategies:
+
+* ``html``: escapes a string for the **HTML body** context.
+
+* ``js``: escapes a string for the **JavaScript context**.
+
+* ``css``: escapes a string for the **CSS context**. CSS escaping can be
+  applied to any string being inserted into CSS and escapes everything except
+  alphanumerics.
+
+* ``url``: escapes a string for the **URI or parameter contexts**. This should
+  not be used to escape an entire URI; only a subcomponent being inserted.
+
+* ``html_attr``: escapes a string for the **HTML attribute** context.
+
+.. note::
+
+    Internally, ``escape`` uses the PHP native `htmlspecialchars`_ function
+    for the HTML escaping strategy.
+
+.. caution::
+
+    When using automatic escaping, Twig tries to not double-escape a variable
+    when the automatic escaping strategy is the same as the one applied by the
+    escape filter; but that does not work when using a variable as the
+    escaping strategy:
+
+    .. code-block:: jinja
+
+        {% set strategy = 'html' %}
+
+        {% autoescape 'html' %}
+            {{ var|escape('html') }}   {# won't be double-escaped #}
+            {{ var|escape(strategy) }} {# will be double-escaped #}
+        {% endautoescape %}
+
+    When using a variable as the escaping strategy, you should disable
+    automatic escaping:
+
+    .. code-block:: jinja
+
+        {% set strategy = 'html' %}
+
+        {% autoescape 'html' %}
+            {{ var|escape(strategy)|raw }} {# won't be double-escaped #}
+        {% endautoescape %}
+
+Custom Escapers
+---------------
+
+You can define custom escapers by calling the ``setEscaper()`` method on the
+``core`` extension instance. The first argument is the escaper name (to be
+used in the ``escape`` call) and the second one must be a valid PHP callable:
+
+.. code-block:: php
+
+    $twig = new \Twig\Environment($loader);
+    $twig->getExtension('\Twig\Extension\CoreExtension')->setEscaper('csv', 'csv_escaper');
+
+    // before Twig 1.26
+    $twig->getExtension('core')->setEscaper('csv', 'csv_escaper');
+
+When called by Twig, the callable receives the Twig environment instance, the
+string to escape, and the charset.
+
+.. note::
+
+    Built-in escapers cannot be overridden mainly they should be considered as
+    the final implementation and also for better performance.
+
+Arguments
+---------
+
+* ``strategy``: The escaping strategy
+* ``charset``:  The string charset
+
+.. _`htmlspecialchars`: https://secure.php.net/htmlspecialchars

Twig/doc/filters/first.rst

+``first``
+=========
+
+.. versionadded:: 1.12.2
+    The ``first`` filter was added in Twig 1.12.2.
+
+The ``first`` filter returns the first "element" of a sequence, a mapping, or
+a string:
+
+.. code-block:: jinja
+
+    {{ [1, 2, 3, 4]|first }}
+    {# outputs 1 #}
+
+    {{ { a: 1, b: 2, c: 3, d: 4 }|first }}
+    {# outputs 1 #}
+
+    {{ '1234'|first }}
+    {# outputs 1 #}
+
+.. note::
+
+    It also works with objects implementing the `Traversable`_ interface.
+
+.. _`Traversable`: https://secure.php.net/manual/en/class.traversable.php

Twig/doc/filters/format.rst

+``format``
+==========
+
+The ``format`` filter formats a given string by replacing the placeholders
+(placeholders follows the `sprintf`_ notation):
+
+.. code-block:: jinja
+
+    {{ "I like %s and %s."|format(foo, "bar") }}
+
+    {# outputs I like foo and bar
+       if the foo parameter equals to the foo string. #}
+
+.. _`sprintf`: https://secure.php.net/sprintf
+
+.. seealso:: :doc:`replace<replace>`

Twig/doc/filters/index.rst

+Filters
+=======
+
+.. toctree::
+    :maxdepth: 1
+
+    abs
+    batch
+    capitalize
+    convert_encoding
+    date
+    date_modify
+    default
+    escape
+    first
+    format
+    join
+    json_encode
+    keys
+    last
+    length
+    lower
+    merge
+    nl2br
+    number_format
+    raw
+    replace
+    reverse
+    round
+    slice
+    sort
+    spaceless
+    split
+    striptags
+    title
+    trim
+    upper
+    url_encode

Twig/doc/filters/join.rst

+``join``
+========
+
+.. versionadded:: 1.37 and 2.6.1
+    The ``and`` argument was added in Twig 1.37 and 2.6.1.
+
+The ``join`` filter returns a string which is the concatenation of the items
+of a sequence:
+
+.. code-block:: jinja
+
+    {{ [1, 2, 3]|join }}
+    {# returns 123 #}
+
+The separator between elements is an empty string per default, but you can
+define it with the optional first parameter:
+
+.. code-block:: jinja
+
+    {{ [1, 2, 3]|join('|') }}
+    {# outputs 1|2|3 #}
+    
+A second parameter can also be provided that will be the separator used between
+the last two items of the sequence:
+
+.. code-block:: jinja
+
+    {{ [1, 2, 3]|join(', ', ' and ') }}
+    {# outputs 1, 2 and 3 #}
+    
+Arguments
+---------
+
+* ``glue``: The separator
+* ``and``: The separator for the last pair of input items

Twig/doc/filters/json_encode.rst

+``json_encode``
+===============
+
+The ``json_encode`` filter returns the JSON representation of a value:
+
+.. code-block:: jinja
+
+    {{ data|json_encode() }}
+
+.. note::
+
+    Internally, Twig uses the PHP `json_encode`_ function.
+
+Arguments
+---------
+
+* ``options``: A bitmask of `json_encode options`_: ``{{
+  data|json_encode(constant('JSON_PRETTY_PRINT')) }}``.
+  Combine constants using :ref:`bitwise operators<template_logic>`:
+  ``{{ data|json_encode(constant('JSON_PRETTY_PRINT') b-or constant('JSON_HEX_QUOT')) }}``
+
+.. _`json_encode`: https://secure.php.net/json_encode
+.. _`json_encode options`: https://secure.php.net/manual/en/json.constants.php

Twig/doc/filters/keys.rst

+``keys``
+========
+
+The ``keys`` filter returns the keys of an array. It is useful when you want to
+iterate over the keys of an array:
+
+.. code-block:: jinja
+
+    {% for key in array|keys %}
+        ...
+    {% endfor %}

Twig/doc/filters/last.rst

+``last``
+========
+
+.. versionadded:: 1.12.2
+    The ``last`` filter was added in Twig 1.12.2.
+
+The ``last`` filter returns the last "element" of a sequence, a mapping, or
+a string:
+
+.. code-block:: jinja
+
+    {{ [1, 2, 3, 4]|last }}
+    {# outputs 4 #}
+
+    {{ { a: 1, b: 2, c: 3, d: 4 }|last }}
+    {# outputs 4 #}
+
+    {{ '1234'|last }}
+    {# outputs 4 #}
+
+.. note::
+
+    It also works with objects implementing the `Traversable`_ interface.
+
+.. _`Traversable`: https://secure.php.net/manual/en/class.traversable.php

Twig/doc/filters/length.rst

+``length``
+==========
+
+.. versionadded:: 1.33
+
+    Support for the ``__toString()`` magic method has been added in Twig 1.33.
+
+The ``length`` filter returns the number of items of a sequence or mapping, or
+the length of a string.
+
+For objects that implement the ``Countable`` interface, ``length`` will use the
+return value of the ``count()`` method.
+
+For objects that implement the ``__toString()`` magic method (and not ``Countable``),
+it will return the length of the string provided by that method.
+
+For objects that implement the ``IteratorAggregate`` interface, ``length`` will use the return value of the ``iterator_count()`` method.
+
+.. code-block:: jinja
+
+    {% if users|length > 10 %}
+        ...
+    {% endif %}

Twig/doc/filters/lower.rst

+``lower``
+=========
+
+The ``lower`` filter converts a value to lowercase:
+
+.. code-block:: jinja
+
+    {{ 'WELCOME'|lower }}
+
+    {# outputs 'welcome' #}

Twig/doc/filters/merge.rst

+``merge``
+=========
+
+The ``merge`` filter merges an array with another array:
+
+.. code-block:: jinja
+
+    {% set values = [1, 2] %}
+
+    {% set values = values|merge(['apple', 'orange']) %}
+
+    {# values now contains [1, 2, 'apple', 'orange'] #}
+
+New values are added at the end of the existing ones.
+
+The ``merge`` filter also works on hashes:
+
+.. code-block:: jinja
+
+    {% set items = { 'apple': 'fruit', 'orange': 'fruit', 'peugeot': 'unknown' } %}
+
+    {% set items = items|merge({ 'peugeot': 'car', 'renault': 'car' }) %}
+
+    {# items now contains { 'apple': 'fruit', 'orange': 'fruit', 'peugeot': 'car', 'renault': 'car' } #}
+
+For hashes, the merging process occurs on the keys: if the key does not
+already exist, it is added but if the key already exists, its value is
+overridden.
+
+.. tip::
+
+    If you want to ensure that some values are defined in an array (by given
+    default values), reverse the two elements in the call:
+
+    .. code-block:: jinja
+
+        {% set items = { 'apple': 'fruit', 'orange': 'fruit' } %}
+
+        {% set items = { 'apple': 'unknown' }|merge(items) %}
+
+        {# items now contains { 'apple': 'fruit', 'orange': 'fruit' } #}
+        
+.. note::
+
+    Internally, Twig uses the PHP `array_merge`_ function. It supports
+    Traversable objects by transforming those to arrays.
+
+.. _`array_merge`: https://secure.php.net/array_merge

Twig/doc/filters/nl2br.rst

+``nl2br``
+=========
+
+.. versionadded:: 1.5
+    The ``nl2br`` filter was added in Twig 1.5.
+
+The ``nl2br`` filter inserts HTML line breaks before all newlines in a string:
+
+.. code-block:: jinja
+
+    {{ "I like Twig.\nYou will like it too."|nl2br }}
+    {# outputs
+
+        I like Twig.<br />
+        You will like it too.
+
+    #}
+
+.. note::
+
+    The ``nl2br`` filter pre-escapes the input before applying the
+    transformation.

Twig/doc/filters/number_format.rst

+``number_format``
+=================
+
+.. versionadded:: 1.5
+    The ``number_format`` filter was added in Twig 1.5
+
+The ``number_format`` filter formats numbers.  It is a wrapper around PHP's
+`number_format`_ function:
+
+.. code-block:: jinja
+
+    {{ 200.35|number_format }}
+
+You can control the number of decimal places, decimal point, and thousands
+separator using the additional arguments:
+
+.. code-block:: jinja
+
+    {{ 9800.333|number_format(2, '.', ',') }}
+
+To format negative numbers, wrap the number with parentheses (needed because of
+Twig's :ref:`precedence of operators <twig-expressions>`:
+
+.. code-block:: jinja
+
+    {{ -9800.333|number_format(2, '.', ',') }} {# outputs : -9 #}
+    {{ (-9800.333)|number_format(2, '.', ',') }} {# outputs : -9,800.33 #}
+
+If no formatting options are provided then Twig will use the default formatting
+options of:
+
+* 0 decimal places.
+* ``.`` as the decimal point.
+* ``,`` as the thousands separator.
+
+These defaults can be easily changed through the core extension:
+
+.. code-block:: php
+
+    $twig = new \Twig\Environment($loader);
+    $twig->getExtension('\Twig\Extension\CoreExtension')->setNumberFormat(3, '.', ',');
+
+    // before Twig 1.26
+    $twig->getExtension('core')->setNumberFormat(3, '.', ',');
+
+The defaults set for ``number_format`` can be over-ridden upon each call using the
+additional parameters.
+
+Arguments
+---------
+
+* ``decimal``:       The number of decimal points to display
+* ``decimal_point``: The character(s) to use for the decimal point
+* ``thousand_sep``:   The character(s) to use for the thousands separator
+
+.. _`number_format`: https://secure.php.net/number_format

Twig/doc/filters/raw.rst

+``raw``
+=======
+
+The ``raw`` filter marks the value as being "safe", which means that in an
+environment with automatic escaping enabled this variable will not be escaped
+if ``raw`` is the last filter applied to it:
+
+.. code-block:: jinja
+
+    {% autoescape %}
+        {{ var|raw }} {# var won't be escaped #}
+    {% endautoescape %}
+
+.. note::
+
+    **This note only applies to Twig before versions 1.39 and 2.8**.
+
+    Be careful when using the ``raw`` filter inside expressions:
+
+    .. code-block:: jinja
+
+        {% autoescape %}
+            {% set hello = '<strong>Hello</strong>' %}
+            {% set hola = '<strong>Hola</strong>' %}
+
+            {{ false ? '<strong>Hola</strong>' : hello|raw }}
+            does not render the same as
+            {{ false ? hola : hello|raw }}
+            but renders the same as
+            {{ (false ? hola : hello)|raw }}
+        {% endautoescape %}
+
+    The first ternary statement is not escaped: ``hello`` is marked as being
+    safe and Twig does not escape static values (see
+    :doc:`escape<../tags/autoescape>`). In the second ternary statement, even
+    if ``hello`` is marked as safe, ``hola`` remains unsafe and so is the whole
+    expression. The third ternary statement is marked as safe and the result is
+    not escaped.

Twig/doc/filters/replace.rst

+``replace``
+===========
+
+The ``replace`` filter formats a given string by replacing the placeholders
+(placeholders are free-form):
+
+.. code-block:: jinja
+
+    {{ "I like %this% and %that%."|replace({'%this%': foo, '%that%': "bar"}) }}
+
+    {# outputs I like foo and bar
+       if the foo parameter equals to the foo string. #}
+
+    {# using % as a delimiter is purely conventional and optional #}
+
+    {{ "I like this and --that--."|replace({'this': foo, '--that--': "bar"}) }}
+
+    {# outputs I like foo and bar #}
+
+Arguments
+---------
+
+* ``from``: The placeholder values
+
+.. seealso:: :doc:`format<format>`

Twig/doc/filters/reverse.rst

+``reverse``
+===========
+
+.. versionadded:: 1.6
+    Support for strings has been added in Twig 1.6.
+
+The ``reverse`` filter reverses a sequence, a mapping, or a string:
+
+.. code-block:: jinja
+
+    {% for user in users|reverse %}
+        ...
+    {% endfor %}
+
+    {{ '1234'|reverse }}
+
+    {# outputs 4321 #}
+
+.. tip::
+
+    For sequences and mappings, numeric keys are not preserved. To reverse
+    them as well, pass ``true`` as an argument to the ``reverse`` filter:
+
+    .. code-block:: jinja
+
+        {% for key, value in {1: "a", 2: "b", 3: "c"}|reverse %}
+            {{ key }}: {{ value }}
+        {%- endfor %}
+
+        {# output: 0: c    1: b    2: a #}
+
+        {% for key, value in {1: "a", 2: "b", 3: "c"}|reverse(true) %}
+            {{ key }}: {{ value }}
+        {%- endfor %}
+
+        {# output: 3: c    2: b    1: a #}
+
+.. note::
+
+    It also works with objects implementing the `Traversable`_ interface.
+
+Arguments
+---------
+
+* ``preserve_keys``: Preserve keys when reversing a mapping or a sequence.
+
+.. _`Traversable`: https://secure.php.net/Traversable

Twig/doc/filters/round.rst

+``round``
+=========
+
+.. versionadded:: 1.15.0
+    The ``round`` filter was added in Twig 1.15.0.
+
+The ``round`` filter rounds a number to a given precision:
+
+.. code-block:: jinja
+
+    {{ 42.55|round }}
+    {# outputs 43 #}
+
+    {{ 42.55|round(1, 'floor') }}
+    {# outputs 42.5 #}
+
+The ``round`` filter takes two optional arguments; the first one specifies the
+precision (default is ``0``) and the second the rounding method (default is
+``common``):
+
+* ``common`` rounds either up or down (rounds the value up to precision decimal
+  places away from zero, when it is half way there -- making 1.5 into 2 and
+  -1.5 into -2);
+
+* ``ceil`` always rounds up;
+
+* ``floor`` always rounds down.
+
+.. note::
+
+    The ``//`` operator is equivalent to ``|round(0, 'floor')``.
+
+Arguments
+---------
+
+* ``precision``: The rounding precision
+* ``method``: The rounding method

Twig/doc/filters/slice.rst

+``slice``
+===========
+
+.. versionadded:: 1.6
+    The ``slice`` filter was added in Twig 1.6.
+
+The ``slice`` filter extracts a slice of a sequence, a mapping, or a string:
+
+.. code-block:: jinja
+
+    {% for i in [1, 2, 3, 4, 5]|slice(1, 2) %}
+        {# will iterate over 2 and 3 #}
+    {% endfor %}
+
+    {{ '12345'|slice(1, 2) }}
+
+    {# outputs 23 #}
+
+You can use any valid expression for both the start and the length:
+
+.. code-block:: jinja
+
+    {% for i in [1, 2, 3, 4, 5]|slice(start, length) %}
+        {# ... #}
+    {% endfor %}
+
+As syntactic sugar, you can also use the ``[]`` notation:
+
+.. code-block:: jinja
+
+    {% for i in [1, 2, 3, 4, 5][start:length] %}
+        {# ... #}
+    {% endfor %}
+
+    {{ '12345'[1:2] }} {# will display "23" #}
+
+    {# you can omit the first argument -- which is the same as 0 #}
+    {{ '12345'[:2] }} {# will display "12" #}
+
+    {# you can omit the last argument -- which will select everything till the end #}
+    {{ '12345'[2:] }} {# will display "345" #}
+
+The ``slice`` filter works as the `array_slice`_ PHP function for arrays and
+`mb_substr`_ for strings with a fallback to `substr`_.
+
+If the start is non-negative, the sequence will start at that start in the
+variable. If start is negative, the sequence will start that far from the end
+of the variable.
+
+If length is given and is positive, then the sequence will have up to that
+many elements in it. If the variable is shorter than the length, then only the
+available variable elements will be present. If length is given and is
+negative then the sequence will stop that many elements from the end of the
+variable. If it is omitted, then the sequence will have everything from offset
+up until the end of the variable.
+
+.. note::
+
+    It also works with objects implementing the `Traversable`_ interface.
+
+Arguments
+---------
+
+* ``start``:         The start of the slice
+* ``length``:        The size of the slice
+* ``preserve_keys``: Whether to preserve key or not (when the input is an array)
+
+.. _`Traversable`: https://secure.php.net/manual/en/class.traversable.php
+.. _`array_slice`: https://secure.php.net/array_slice
+.. _`mb_substr` :  https://secure.php.net/mb-substr
+.. _`substr`:      https://secure.php.net/substr

Twig/doc/filters/sort.rst

+``sort``
+========
+
+The ``sort`` filter sorts an array:
+
+.. code-block:: jinja
+
+    {% for user in users|sort %}
+        ...
+    {% endfor %}
+
+.. note::
+
+    Internally, Twig uses the PHP `asort`_ function to maintain index
+    association. It supports Traversable objects by transforming
+    those to arrays.
+
+.. _`asort`: https://secure.php.net/asort

Twig/doc/filters/spaceless.rst

+``spaceless``
+=============
+
+.. versionadded:: 1.38
+
+    The ``spaceless`` filter was added in Twig 1.38.
+
+Use the ``spaceless`` filter to remove whitespace *between HTML tags*, not
+whitespace within HTML tags or whitespace in plain text:
+
+.. code-block:: jinja
+
+    {{
+        "<div>
+            <strong>foo</strong>
+        </div>
+        "|spaceless }}
+
+    {# output will be <div><strong>foo</strong></div> #}
+
+You can combine ``spaceless`` with the ``filter`` tag to apply the
+transformation on large amounts of HTML:
+
+.. code-block:: jinja
+
+    {% filter spaceless %}
+        <div>
+            <strong>foo</strong>
+        </div>
+    {% endfilter %}
+
+    {# output will be <div><strong>foo</strong></div> #}
+
+This tag is not meant to "optimize" the size of the generated HTML content but
+merely to avoid extra whitespace between HTML tags to avoid browser rendering
+quirks under some circumstances.
+
+.. caution::
+
+    As the filter uses a regular expression behind the scenes, its performance
+    is directly related to the text size you are working on (remember that
+    filters are executed at runtime).
+
+.. tip::
+
+    If you want to optimize the size of the generated HTML content, gzip
+    compress the output instead.
+
+.. tip::
+
+    If you want to create a tag that actually removes all extra whitespace in
+    an HTML string, be warned that this is not as easy as it seems to be
+    (think of ``textarea`` or ``pre`` tags for instance). Using a third-party
+    library like Tidy is probably a better idea.
+
+.. tip::
+
+    For more information on whitespace control, read the
+    :ref:`dedicated section <templates-whitespace-control>` of the documentation and learn how
+    you can also use the whitespace control modifier on your tags.

Twig/doc/filters/split.rst

+``split``
+=========
+
+.. versionadded:: 1.10.3
+    The ``split`` filter was added in Twig 1.10.3.
+
+The ``split`` filter splits a string by the given delimiter and returns a list
+of strings:
+
+.. code-block:: jinja
+
+    {% set foo = "one,two,three"|split(',') %}
+    {# foo contains ['one', 'two', 'three'] #}
+
+You can also pass a ``limit`` argument:
+
+* If ``limit`` is positive, the returned array will contain a maximum of
+  limit elements with the last element containing the rest of string;
+
+* If ``limit`` is negative, all components except the last -limit are
+  returned;
+
+* If ``limit`` is zero, then this is treated as 1.
+
+.. code-block:: jinja
+
+    {% set foo = "one,two,three,four,five"|split(',', 3) %}
+    {# foo contains ['one', 'two', 'three,four,five'] #}
+
+If the ``delimiter`` is an empty string, then value will be split by equal
+chunks. Length is set by the ``limit`` argument (one character by default).
+
+.. code-block:: jinja
+
+    {% set foo = "123"|split('') %}
+    {# foo contains ['1', '2', '3'] #}
+
+    {% set bar = "aabbcc"|split('', 2) %}
+    {# bar contains ['aa', 'bb', 'cc'] #}
+
+.. note::
+
+    Internally, Twig uses the PHP `explode`_ or `str_split`_ (if delimiter is
+    empty) functions for string splitting.
+
+Arguments
+---------
+
+* ``delimiter``: The delimiter
+* ``limit``:     The limit argument
+
+.. _`explode`:   https://secure.php.net/explode
+.. _`str_split`: https://secure.php.net/str_split

Twig/doc/filters/striptags.rst

+``striptags``
+=============
+
+The ``striptags`` filter strips SGML/XML tags and replace adjacent whitespace
+by one space:
+
+.. code-block:: jinja
+
+    {{ some_html|striptags }}
+
+You can also provide tags which should not be stripped:
+
+.. code-block:: jinja
+
+    {{ some_html|striptags('<br><p>') }}
+
+In this example, the ``<br/>``, ``<br>``, ``<p>``, and ``</p>`` tags won't be
+removed from the string.
+
+.. note::
+
+    Internally, Twig uses the PHP `strip_tags`_ function.
+
+Arguments
+---------
+
+* ``allowable_tags``: Tags which should not be stripped
+
+.. _`strip_tags`: https://secure.php.net/strip_tags

Twig/doc/filters/title.rst

+``title``
+=========
+
+The ``title`` filter returns a titlecased version of the value. Words will
+start with uppercase letters, all remaining characters are lowercase:
+
+.. code-block:: jinja
+
+    {{ 'my first car'|title }}
+
+    {# outputs 'My First Car' #}

Twig/doc/filters/trim.rst

+``trim``
+========
+
+.. versionadded:: 1.32
+    The ``side`` argument was added in Twig 1.32.
+
+.. versionadded:: 1.6.2
+    The ``trim`` filter was added in Twig 1.6.2.
+
+The ``trim`` filter strips whitespace (or other characters) from the beginning
+and end of a string:
+
+.. code-block:: jinja
+
+    {{ '  I like Twig.  '|trim }}
+
+    {# outputs 'I like Twig.' #}
+
+    {{ '  I like Twig.'|trim('.') }}
+
+    {# outputs '  I like Twig' #}
+
+    {{ '  I like Twig.  '|trim(side='left') }}
+
+    {# outputs 'I like Twig.  ' #}
+
+    {{ '  I like Twig.  '|trim(' ', 'right') }}
+
+    {# outputs '  I like Twig.' #}
+
+.. note::
+
+    Internally, Twig uses the PHP `trim`_, `ltrim`_, and `rtrim`_ functions.
+
+Arguments
+---------
+
+* ``character_mask``: The characters to strip
+
+* ``side``: The default is to strip from the left and the right (`both`) sides, but `left`
+  and `right` will strip from either the left side or right side only
+
+.. _`trim`: https://secure.php.net/trim
+.. _`ltrim`: https://secure.php.net/ltrim
+.. _`rtrim`: https://secure.php.net/rtrim

Twig/doc/filters/upper.rst

+``upper``
+=========
+
+The ``upper`` filter converts a value to uppercase:
+
+.. code-block:: jinja
+
+    {{ 'welcome'|upper }}
+
+    {# outputs 'WELCOME' #}

Twig/doc/filters/url_encode.rst

+``url_encode``
+==============
+
+.. versionadded:: 1.12.3
+    Support for encoding an array as query string was added in Twig 1.12.3.
+
+.. versionadded:: 1.16.0
+    The ``raw`` argument was removed in Twig 1.16.0. Twig now always encodes
+    according to RFC 3986.
+
+The ``url_encode`` filter percent encodes a given string as URL segment
+or an array as query string:
+
+.. code-block:: jinja
+
+    {{ "path-seg*ment"|url_encode }}
+    {# outputs "path-seg%2Ament" #}
+
+    {{ "string with spaces"|url_encode }}
+    {# outputs "string%20with%20spaces" #}
+
+    {{ {'param': 'value', 'foo': 'bar'}|url_encode }}
+    {# outputs "param=value&foo=bar" #}
+
+.. note::
+
+    Internally, Twig uses the PHP `urlencode`_ (or `rawurlencode`_ if you pass
+    ``true`` as the first parameter) or the `http_build_query`_ function. Note
+    that as of Twig 1.16.0, ``urlencode`` **always** uses ``rawurlencode`` (the
+    ``raw`` argument was removed.)
+
+.. _`urlencode`:        https://secure.php.net/urlencode
+.. _`rawurlencode`:     https://secure.php.net/rawurlencode
+.. _`http_build_query`: https://secure.php.net/http_build_query

Twig/doc/functions/attribute.rst

+``attribute``
+=============
+
+.. versionadded:: 1.2
+    The ``attribute`` function was added in Twig 1.2.
+
+The ``attribute`` function can be used to access a "dynamic" attribute of a
+variable:
+
+.. code-block:: jinja
+
+    {{ attribute(object, method) }}
+    {{ attribute(object, method, arguments) }}
+    {{ attribute(array, item) }}
+
+In addition, the ``defined`` test can check for the existence of a dynamic
+attribute:
+
+.. code-block:: jinja
+
+    {{ attribute(object, method) is defined ? 'Method exists' : 'Method does not exist' }}
+
+.. note::
+
+    The resolution algorithm is the same as the one used for the ``.``
+    notation, except that the item can be any valid expression.

Twig/doc/functions/block.rst

+``block``
+=========
+
+.. versionadded: 1.28
+    Using ``block`` with the ``defined`` test was added in Twig 1.28.
+
+.. versionadded: 1.28
+    Support for the template argument was added in Twig 1.28.
+
+When a template uses inheritance and if you want to print a block multiple
+times, use the ``block`` function:
+
+.. code-block:: jinja
+
+    <title>{% block title %}{% endblock %}</title>
+
+    <h1>{{ block('title') }}</h1>
+
+    {% block body %}{% endblock %}
+
+The ``block`` function can also be used to display one block from another
+template:
+
+.. code-block:: jinja
+
+    {{ block("title", "common_blocks.twig") }}
+
+Use the ``defined`` test to check if a block exists in the context of the
+current template:
+
+.. code-block:: jinja
+
+    {% if block("footer") is defined %}
+        ...
+    {% endif %}
+
+    {% if block("footer", "common_blocks.twig") is defined %}
+        ...
+    {% endif %}
+
+.. seealso:: :doc:`extends<../tags/extends>`, :doc:`parent<../functions/parent>`

Twig/doc/functions/constant.rst

+``constant``
+============
+
+.. versionadded: 1.12.1
+    constant now accepts object instances as the second argument.
+
+.. versionadded: 1.28
+    Using ``constant`` with the ``defined`` test was added in Twig 1.28.
+
+``constant`` returns the constant value for a given string:
+
+.. code-block:: jinja
+
+    {{ some_date|date(constant('DATE_W3C')) }}
+    {{ constant('Namespace\\Classname::CONSTANT_NAME') }}
+
+As of 1.12.1 you can read constants from object instances as well:
+
+.. code-block:: jinja
+
+    {{ constant('RSS', date) }}
+
+Use the ``defined`` test to check if a constant is defined:
+
+.. code-block:: jinja
+
+    {% if constant('SOME_CONST') is defined %}
+        ...
+    {% endif %}

Twig/doc/functions/cycle.rst

+``cycle``
+=========
+
+The ``cycle`` function cycles on an array of values:
+
+.. code-block:: jinja
+
+    {% set start_year = date() | date('Y') %}
+    {% set end_year = start_year + 5 %}
+
+    {% for year in start_year..end_year %}
+        {{ cycle(['odd', 'even'], loop.index0) }}
+    {% endfor %}
+
+The array can contain any number of values:
+
+.. code-block:: jinja
+
+    {% set fruits = ['apple', 'orange', 'citrus'] %}
+
+    {% for i in 0..10 %}
+        {{ cycle(fruits, i) }}
+    {% endfor %}
+
+Arguments
+---------
+
+* ``position``: The cycle position

Twig/doc/functions/date.rst

+``date``
+========
+
+.. versionadded:: 1.6
+    The date function has been added in Twig 1.6.
+
+.. versionadded:: 1.6.1
+    The default timezone support has been added in Twig 1.6.1.
+
+Converts an argument to a date to allow date comparison:
+
+.. code-block:: jinja
+
+    {% if date(user.created_at) < date('-2days') %}
+        {# do something #}
+    {% endif %}
+
+The argument must be in one of PHP’s supported `date and time formats`_.
+
+You can pass a timezone as the second argument:
+
+.. code-block:: jinja
+
+    {% if date(user.created_at) < date('-2days', 'Europe/Paris') %}
+        {# do something #}
+    {% endif %}
+
+If no argument is passed, the function returns the current date:
+
+.. code-block:: jinja
+
+    {% if date(user.created_at) < date() %}
+        {# always! #}
+    {% endif %}
+
+.. note::
+
+    You can set the default timezone globally by calling ``setTimezone()`` on
+    the ``core`` extension instance:
+
+    .. code-block:: php
+
+        $twig = new \Twig\Environment($loader);
+        $twig->getExtension('\Twig\Extension\CoreExtension')->setTimezone('Europe/Paris');
+
+        // before Twig 1.26
+        $twig->getExtension('core')->setTimezone('Europe/Paris');
+
+Arguments
+---------
+
+* ``date``:     The date
+* ``timezone``: The timezone
+
+.. _`date and time formats`: https://secure.php.net/manual/en/datetime.formats.php

Twig/doc/functions/dump.rst

+``dump``
+========
+
+.. versionadded:: 1.5
+    The ``dump`` function was added in Twig 1.5.
+
+The ``dump`` function dumps information about a template variable. This is
+mostly useful to debug a template that does not behave as expected by
+introspecting its variables:
+
+.. code-block:: jinja
+
+    {{ dump(user) }}
+
+.. note::
+
+    The ``dump`` function is not available by default. You must add the
+    ``\Twig\Extension\DebugExtension`` extension explicitly when creating your Twig
+    environment::
+
+        $twig = new \Twig\Environment($loader, [
+            'debug' => true,
+            // ...
+        ]);
+        $twig->addExtension(new \Twig\Extension\DebugExtension());
+
+    Even when enabled, the ``dump`` function won't display anything if the
+    ``debug`` option on the environment is not enabled (to avoid leaking debug
+    information on a production server).
+
+In an HTML context, wrap the output with a ``pre`` tag to make it easier to
+read:
+
+.. code-block:: jinja
+
+    <pre>
+        {{ dump(user) }}
+    </pre>
+
+.. tip::
+
+    Using a ``pre`` tag is not needed when `XDebug`_ is enabled and
+    ``html_errors`` is ``on``; as a bonus, the output is also nicer with
+    XDebug enabled.
+
+You can debug several variables by passing them as additional arguments:
+
+.. code-block:: jinja
+
+    {{ dump(user, categories) }}
+
+If you don't pass any value, all variables from the current context are
+dumped:
+
+.. code-block:: jinja
+
+    {{ dump() }}
+
+.. note::
+
+    Internally, Twig uses the PHP `var_dump`_ function.
+
+Arguments
+---------
+
+* ``context``: The context to dump
+
+.. _`XDebug`:   https://xdebug.org/docs/display
+.. _`var_dump`: https://secure.php.net/var_dump

Twig/doc/functions/include.rst

+``include``
+===========
+
+.. versionadded:: 1.12
+    The ``include`` function was added in Twig 1.12.
+
+The ``include`` function returns the rendered content of a template:
+
+.. code-block:: jinja
+
+    {{ include('template.html') }}
+    {{ include(some_var) }}
+
+Included templates have access to the variables of the active context.
+
+If you are using the filesystem loader, the templates are looked for in the
+paths defined by it.
+
+The context is passed by default to the template but you can also pass
+additional variables:
+
+.. code-block:: jinja
+
+    {# template.html will have access to the variables from the current context and the additional ones provided #}
+    {{ include('template.html', {foo: 'bar'}) }}
+
+You can disable access to the context by setting ``with_context`` to
+``false``:
+
+.. code-block:: jinja
+
+    {# only the foo variable will be accessible #}
+    {{ include('template.html', {foo: 'bar'}, with_context = false) }}
+
+.. code-block:: jinja
+
+    {# no variables will be accessible #}
+    {{ include('template.html', with_context = false) }}
+
+And if the expression evaluates to a ``\Twig\Template`` or a
+``\Twig\TemplateWrapper`` instance, Twig will use it directly::
+
+    // {{ include(template) }}
+
+    // deprecated as of Twig 1.28
+    $template = $twig->loadTemplate('some_template.twig');
+
+    // as of Twig 1.28
+    $template = $twig->load('some_template.twig');
+
+    $twig->display('template.twig', ['template' => $template]);
+
+When you set the ``ignore_missing`` flag, Twig will return an empty string if
+the template does not exist:
+
+.. code-block:: jinja
+
+    {{ include('sidebar.html', ignore_missing = true) }}
+
+You can also provide a list of templates that are checked for existence before
+inclusion. The first template that exists will be rendered:
+
+.. code-block:: jinja
+
+    {{ include(['page_detailed.html', 'page.html']) }}
+
+If ``ignore_missing`` is set, it will fall back to rendering nothing if none
+of the templates exist, otherwise it will throw an exception.
+
+When including a template created by an end user, you should consider
+sandboxing it:
+
+.. code-block:: jinja
+
+    {{ include('page.html', sandboxed = true) }}
+
+Arguments
+---------
+
+* ``template``:       The template to render
+* ``variables``:      The variables to pass to the template
+* ``with_context``:   Whether to pass the current context variables or not
+* ``ignore_missing``: Whether to ignore missing templates or not
+* ``sandboxed``:      Whether to sandbox the template or not

Twig/doc/functions/index.rst

+Functions
+=========
+
+.. toctree::
+    :maxdepth: 1
+
+    attribute
+    block
+    constant
+    cycle
+    date
+    dump
+    include
+    max
+    min
+    parent
+    random
+    range
+    source
+    template_from_string

Twig/doc/functions/max.rst

+``max``
+=======
+
+.. versionadded:: 1.15
+    The ``max`` function was added in Twig 1.15.
+
+``max`` returns the biggest value of a sequence or a set of values:
+
+.. code-block:: jinja
+
+    {{ max(1, 3, 2) }}
+    {{ max([1, 3, 2]) }}
+
+When called with a mapping, max ignores keys and only compares values:
+
+.. code-block:: jinja
+
+    {{ max({2: "e", 1: "a", 3: "b", 5: "d", 4: "c"}) }}
+    {# returns "e" #}
+

Twig/doc/functions/min.rst

+``min``
+=======
+
+.. versionadded:: 1.15
+    The ``min`` function was added in Twig 1.15.
+
+``min`` returns the lowest value of a sequence or a set of values:
+
+.. code-block:: jinja
+
+    {{ min(1, 3, 2) }}
+    {{ min([1, 3, 2]) }}
+
+When called with a mapping, min ignores keys and only compares values:
+
+.. code-block:: jinja
+
+    {{ min({2: "e", 3: "a", 1: "b", 5: "d", 4: "c"}) }}
+    {# returns "a" #}
+

Twig/doc/functions/parent.rst

+``parent``
+==========
+
+When a template uses inheritance, it's possible to render the contents of the
+parent block when overriding a block by using the ``parent`` function:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% block sidebar %}
+        <h3>Table Of Contents</h3>
+        ...
+        {{ parent() }}
+    {% endblock %}
+
+The ``parent()`` call will return the content of the ``sidebar`` block as
+defined in the ``base.html`` template.
+
+.. seealso:: :doc:`extends<../tags/extends>`, :doc:`block<../functions/block>`, :doc:`block<../tags/block>`

Twig/doc/functions/random.rst

+``random``
+==========
+
+.. versionadded:: 1.5
+    The ``random`` function was added in Twig 1.5.
+
+.. versionadded:: 1.6
+    String and integer handling was added in Twig 1.6.
+
+.. versionadded:: 1.38
+    The "max" argument was added in Twig 1.38.
+
+The ``random`` function returns a random value depending on the supplied
+parameter type:
+
+* a random item from a sequence;
+* a random character from a string;
+* a random integer between 0 and the integer parameter (inclusive).
+* a random integer between the integer parameter (when negative) and 0 (inclusive).
+* a random integer between the first integer and the second integer parameter (inclusive).
+
+.. code-block:: jinja
+
+    {{ random(['apple', 'orange', 'citrus']) }} {# example output: orange #}
+    {{ random('ABC') }}                         {# example output: C #}
+    {{ random() }}                              {# example output: 15386094 (works as the native PHP mt_rand function) #}
+    {{ random(5) }}                             {# example output: 3 #}
+    {{ random(50, 100) }}                       {# example output: 63 #}
+
+Arguments
+---------
+
+* ``values``: The values
+* ``max``: The max value when values is an integer
+
+.. _`mt_rand`: https://secure.php.net/mt_rand

Twig/doc/functions/range.rst

+``range``
+=========
+
+Returns a list containing an arithmetic progression of integers:
+
+.. code-block:: jinja
+
+    {% for i in range(0, 3) %}
+        {{ i }},
+    {% endfor %}
+
+    {# outputs 0, 1, 2, 3, #}
+
+When step is given (as the third parameter), it specifies the increment (or
+decrement for negative values):
+
+.. code-block:: jinja
+
+    {% for i in range(0, 6, 2) %}
+        {{ i }},
+    {% endfor %}
+
+    {# outputs 0, 2, 4, 6, #}
+
+.. note::
+
+    Note that if the start is greater than the end, ``range`` assumes a step of
+    ``-1``:
+
+    .. code-block:: jinja
+
+        {% for i in range(3, 0) %}
+            {{ i }},
+        {% endfor %}
+
+        {# outputs 3, 2, 1, 0, #}
+
+The Twig built-in ``..`` operator is just syntactic sugar for the ``range``
+function (with a step of ``1``, or ``-1`` if the start is greater than the end):
+
+.. code-block:: jinja
+
+    {% for i in 0..3 %}
+        {{ i }},
+    {% endfor %}
+
+.. tip::
+
+    The ``range`` function works as the native PHP `range`_ function.
+
+Arguments
+---------
+
+* ``low``:  The first value of the sequence.
+* ``high``: The highest possible value of the sequence.
+* ``step``: The increment between elements of the sequence.
+
+.. _`range`: https://secure.php.net/range

Twig/doc/functions/source.rst

+``source``
+==========
+
+.. versionadded:: 1.15
+    The ``source`` function was added in Twig 1.15.
+
+.. versionadded:: 1.18.3
+    The ``ignore_missing`` flag was added in Twig 1.18.3.
+
+The ``source`` function returns the content of a template without rendering it:
+
+.. code-block:: jinja
+
+    {{ source('template.html') }}
+    {{ source(some_var) }}
+
+When you set the ``ignore_missing`` flag, Twig will return an empty string if
+the template does not exist:
+
+.. code-block:: jinja
+
+    {{ source('template.html', ignore_missing = true) }}
+
+The function uses the same template loaders as the ones used to include
+templates. So, if you are using the filesystem loader, the templates are looked
+for in the paths defined by it.
+
+Arguments
+---------
+
+* ``name``: The name of the template to read
+* ``ignore_missing``: Whether to ignore missing templates or not

Twig/doc/functions/template_from_string.rst

+``template_from_string``
+========================
+
+.. versionadded:: 1.11
+    The ``template_from_string`` function was added in Twig 1.11.
+
+.. versionadded:: 1.39
+    The name argument was added in Twig 1.39.
+
+The ``template_from_string`` function loads a template from a string:
+
+.. code-block:: jinja
+
+    {{ include(template_from_string("Hello {{ name }}")) }}
+    {{ include(template_from_string(page.template)) }}
+
+To ease debugging, you can also give the template a name that will be part of
+any related error message:
+
+.. code-block:: jinja
+
+    {{ include(template_from_string(page.template, "template for page " ~ page.name)) }}
+
+.. note::
+
+    The ``template_from_string`` function is not available by default. You
+    must add the ``\Twig\Extension\StringLoaderExtension`` extension explicitly when
+    creating your Twig environment::
+
+        $twig = new \Twig\Environment(...);
+        $twig->addExtension(new \Twig\Extension\StringLoaderExtension());
+
+.. note::
+
+    Even if you will probably always use the ``template_from_string`` function
+    with the ``include`` function, you can use it with any tag or function that
+    takes a template as an argument (like the ``embed`` or ``extends`` tags).
+
+Arguments
+---------
+
+* ``template``: The template
+* ``name``: A name for the template

Twig/doc/index.rst

+Twig
+====
+
+.. toctree::
+    :maxdepth: 2
+
+    intro
+    installation
+    templates
+    api
+    advanced
+    internals
+    deprecated
+    recipes
+    coding_standards
+    tags/index
+    filters/index
+    functions/index
+    tests/index

Twig/doc/installation.rst

+Installation
+============
+
+You have multiple ways to install Twig.
+
+Installing the Twig PHP package
+-------------------------------
+
+Installing via Composer (recommended)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Install `Composer`_ and run the following command to get the latest version:
+
+.. code-block:: bash
+
+    composer require twig/twig:~1.0
+
+Installing from the tarball release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. Download the most recent tarball from the `download page`_
+2. Verify the integrity of the tarball http://fabien.potencier.org/article/73/signing-project-releases
+3. Unpack the tarball
+4. Move the files somewhere in your project
+
+Installing the development version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: bash
+
+    git clone git://github.com/twigphp/Twig.git
+
+Installing the PEAR package
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note::
+
+    Using PEAR for installing Twig is deprecated and Twig 1.15.1 was the last
+    version published on the PEAR channel; use Composer instead.
+
+.. code-block:: bash
+
+    pear channel-discover pear.twig-project.org
+    pear install twig/Twig
+
+Installing the C extension
+--------------------------
+
+.. versionadded:: 1.4
+    The C extension was added in Twig 1.4.
+
+.. note::
+
+    The C extension is **optional** but it brings some nice performance
+    improvements. Note that the extension is not a replacement for the PHP
+    code; it only implements a small part of the PHP code to improve the
+    performance at runtime; you must still install the regular PHP code.
+    The C extension is only compatible and useful for **PHP5**.
+
+Twig comes with a C extension that enhances the performance of the Twig
+runtime engine; install it like any other PHP extensions:
+
+.. code-block:: bash
+
+    cd ext/twig
+    phpize
+    ./configure
+    make
+    make install
+
+.. note::
+
+    You can also install the C extension via PEAR (note that this method is
+    deprecated and newer versions of Twig are not available on the PEAR
+    channel):
+
+    .. code-block:: bash
+
+        pear channel-discover pear.twig-project.org
+        pear install twig/CTwig
+
+For Windows:
+
+1. Setup the build environment following the `PHP documentation`_
+2. Put Twig's C extension source code into ``C:\php-sdk\phpdev\vcXX\x86\php-source-directory\ext\twig``
+3. Use the ``configure --disable-all --enable-cli --enable-twig=shared`` command instead of step 14
+4. ``nmake``
+5. Copy the ``C:\php-sdk\phpdev\vcXX\x86\php-source-directory\Release_TS\php_twig.dll`` file to your PHP setup.
+
+.. tip::
+
+    For Windows ZendServer, ZTS is not enabled as mentioned in `Zend Server
+    FAQ`_.
+
+    You have to use ``configure --disable-all --disable-zts --enable-cli
+    --enable-twig=shared`` to be able to build the twig C extension for
+    ZendServer.
+
+    The built DLL will be available in
+    ``C:\\php-sdk\\phpdev\\vcXX\\x86\\php-source-directory\\Release``
+
+Finally, enable the extension in your ``php.ini`` configuration file:
+
+.. code-block:: ini
+
+    extension=twig.so #For Unix systems
+    extension=php_twig.dll #For Windows systems
+
+And from now on, Twig will automatically compile your templates to take
+advantage of the C extension. Note that this extension does not replace the
+PHP code but only provides an optimized version of the
+``\Twig\Template::getAttribute()`` method.
+
+.. _`download page`:     https://github.com/twigphp/Twig/tags
+.. _`Composer`:          https://getcomposer.org/download/
+.. _`PHP documentation`: https://wiki.php.net/internals/windows/stepbystepbuild
+.. _`Zend Server FAQ`:   https://www.zend.com/en/products/server/faq#faqD6

Twig/doc/internals.rst

+Twig Internals
+==============
+
+Twig is very extensible and you can easily hack it. Keep in mind that you
+should probably try to create an extension before hacking the core, as most
+features and enhancements can be handled with extensions. This chapter is also
+useful for people who want to understand how Twig works under the hood.
+
+How does Twig work?
+-------------------
+
+The rendering of a Twig template can be summarized into four key steps:
+
+* **Load** the template: If the template is already compiled, load it and go
+  to the *evaluation* step, otherwise:
+
+  * First, the **lexer** tokenizes the template source code into small pieces
+    for easier processing;
+  * Then, the **parser** converts the token stream into a meaningful tree
+    of nodes (the Abstract Syntax Tree);
+  * Eventually, the *compiler* transforms the AST into PHP code.
+
+* **Evaluate** the template: It basically means calling the ``display()``
+  method of the compiled template and passing it the context.
+
+The Lexer
+---------
+
+The lexer tokenizes a template source code into a token stream (each token is
+an instance of ``\Twig\Token``, and the stream is an instance of
+``\Twig\TokenStream``). The default lexer recognizes 13 different token types:
+
+* ``\Twig\Token::BLOCK_START_TYPE``, ``\Twig\Token::BLOCK_END_TYPE``: Delimiters for blocks (``{% %}``)
+* ``\Twig\Token::VAR_START_TYPE``, ``\Twig\Token::VAR_END_TYPE``: Delimiters for variables (``{{ }}``)
+* ``\Twig\Token::TEXT_TYPE``: A text outside an expression;
+* ``\Twig\Token::NAME_TYPE``: A name in an expression;
+* ``\Twig\Token::NUMBER_TYPE``: A number in an expression;
+* ``\Twig\Token::STRING_TYPE``: A string in an expression;
+* ``\Twig\Token::OPERATOR_TYPE``: An operator;
+* ``\Twig\Token::PUNCTUATION_TYPE``: A punctuation sign;
+* ``\Twig\Token::INTERPOLATION_START_TYPE``, ``\Twig\Token::INTERPOLATION_END_TYPE`` (as of Twig 1.5): Delimiters for string interpolation;
+* ``\Twig\Token::EOF_TYPE``: Ends of template.
+
+You can manually convert a source code into a token stream by calling the
+``tokenize()`` method of an environment::
+
+    $stream = $twig->tokenize(new \Twig\Source($source, $identifier));
+
+.. versionadded:: 1.27
+    ``\Twig\Source`` was introduced in version 1.27, pass the source and the
+    identifier directly on previous versions.
+
+As the stream has a ``__toString()`` method, you can have a textual
+representation of it by echoing the object::
+
+    echo $stream."\n";
+
+Here is the output for the ``Hello {{ name }}`` template:
+
+.. code-block:: text
+
+    TEXT_TYPE(Hello )
+    VAR_START_TYPE()
+    NAME_TYPE(name)
+    VAR_END_TYPE()
+    EOF_TYPE()
+
+.. note::
+
+    The default lexer (``\Twig\Lexer``) can be changed by calling
+    the ``setLexer()`` method::
+
+        $twig->setLexer($lexer);
+
+The Parser
+----------
+
+The parser converts the token stream into an AST (Abstract Syntax Tree), or a
+node tree (an instance of ``\Twig\Node\ModuleNode``). The core extension defines
+the basic nodes like: ``for``, ``if``, ... and the expression nodes.
+
+You can manually convert a token stream into a node tree by calling the
+``parse()`` method of an environment::
+
+    $nodes = $twig->parse($stream);
+
+Echoing the node object gives you a nice representation of the tree::
+
+    echo $nodes."\n";
+
+Here is the output for the ``Hello {{ name }}`` template:
+
+.. code-block:: text
+
+    \Twig\Node\ModuleNode(
+      \Twig\Node\TextNode(Hello )
+      \Twig\Node\PrintNode(
+        \Twig\Node\Expression\NameExpression(name)
+      )
+    )
+
+.. note::
+
+    The default parser (``\Twig\TokenParser\AbstractTokenParser``) can be changed by calling the
+    ``setParser()`` method::
+
+        $twig->setParser($parser);
+
+The Compiler
+------------
+
+The last step is done by the compiler. It takes a node tree as an input and
+generates PHP code usable for runtime execution of the template.
+
+You can manually compile a node tree to PHP code with the ``compile()`` method
+of an environment::
+
+    $php = $twig->compile($nodes);
+
+The generated template for a ``Hello {{ name }}`` template reads as follows
+(the actual output can differ depending on the version of Twig you are
+using)::
+
+    /* Hello {{ name }} */
+    class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends \Twig\Template
+    {
+        protected function doDisplay(array $context, array $blocks = [])
+        {
+            // line 1
+            echo "Hello ";
+            echo twig_escape_filter($this->env, (isset($context["name"]) ? $context["name"] : null), "html", null, true);
+        }
+
+        // some more code
+    }
+
+.. note::
+
+    The default compiler (``\Twig\Compiler``) can be changed by calling the
+    ``setCompiler()`` method::
+
+        $twig->setCompiler($compiler);

Twig/doc/intro.rst

+Introduction
+============
+
+This is the documentation for Twig, the flexible, fast, and secure template
+engine for PHP.
+
+If you have any exposure to other text-based template languages, such as
+Smarty, Django, or Jinja, you should feel right at home with Twig. It's both
+designer and developer friendly by sticking to PHP's principles and adding
+functionality useful for templating environments.
+
+The key-features are...
+
+* *Fast*: Twig compiles templates down to plain optimized PHP code. The
+  overhead compared to regular PHP code was reduced to the very minimum.
+
+* *Secure*: Twig has a sandbox mode to evaluate untrusted template code. This
+  allows Twig to be used as a template language for applications where users
+  may modify the template design.
+
+* *Flexible*: Twig is powered by a flexible lexer and parser. This allows the
+  developer to define their own custom tags and filters, and to create their own DSL.
+
+Twig is used by many Open-Source projects like Symfony, Drupal8, eZPublish,
+phpBB, Piwik, OroCRM; and many frameworks have support for it as well like
+Slim, Yii, Laravel, Codeigniter and Kohana — just to name a few.
+
+Prerequisites
+-------------
+
+Twig needs at least **PHP 5.2.7** to run. As of 1.34, the minimum requirement
+was bumped to **PHP 5.3.3**.
+
+Installation
+------------
+
+The recommended way to install Twig is via Composer:
+
+.. code-block:: bash
+
+    composer require "twig/twig:~1.0"
+
+.. note::
+
+    To learn more about the other installation methods, read the
+    :doc:`installation<installation>` chapter; it also explains how to install
+    the Twig C extension.
+
+Basic API Usage
+---------------
+
+This section gives you a brief introduction to the PHP API for Twig.
+
+.. code-block:: php
+
+    require_once '/path/to/vendor/autoload.php';
+
+    $loader = new \Twig\Loader\ArrayLoader([
+        'index' => 'Hello {{ name }}!',
+    ]);
+    $twig = new \Twig\Environment($loader);
+
+    echo $twig->render('index', ['name' => 'Fabien']);
+
+Twig uses a loader (``\Twig\Loader\ArrayLoader``) to locate templates, and an
+environment (``\Twig\Environment``) to store the configuration.
+
+The ``render()`` method loads the template passed as a first argument and
+renders it with the variables passed as a second argument.
+
+As templates are generally stored on the filesystem, Twig also comes with a
+filesystem loader::
+
+    $loader = new \Twig\Loader\FilesystemLoader('/path/to/templates');
+    $twig = new \Twig\Environment($loader, [
+        'cache' => '/path/to/compilation_cache',
+    ]);
+
+    echo $twig->render('index.html', ['name' => 'Fabien']);
+
+.. tip::
+
+    If you are not using Composer, use the Twig built-in autoloader::
+
+        require_once '/path/to/lib/Twig/Autoloader.php';
+        Twig_Autoloader::register();

Twig/doc/tags/autoescape.rst

+``autoescape``
+==============
+
+Whether automatic escaping is enabled or not, you can mark a section of a
+template to be escaped or not by using the ``autoescape`` tag:
+
+.. code-block:: jinja
+
+    {% autoescape %}
+        Everything will be automatically escaped in this block
+        using the HTML strategy
+    {% endautoescape %}
+
+    {% autoescape 'html' %}
+        Everything will be automatically escaped in this block
+        using the HTML strategy
+    {% endautoescape %}
+
+    {% autoescape 'js' %}
+        Everything will be automatically escaped in this block
+        using the js escaping strategy
+    {% endautoescape %}
+
+    {% autoescape false %}
+        Everything will be outputted as is in this block
+    {% endautoescape %}
+
+.. note::
+
+    Before Twig 1.8, the syntax was different:
+
+    .. code-block:: jinja
+
+        {% autoescape true %}
+            Everything will be automatically escaped in this block
+            using the HTML strategy
+        {% endautoescape %}
+
+        {% autoescape false %}
+            Everything will be outputted as is in this block
+        {% endautoescape %}
+
+        {% autoescape true js %}
+            Everything will be automatically escaped in this block
+            using the js escaping strategy
+        {% endautoescape %}
+
+When automatic escaping is enabled everything is escaped by default except for
+values explicitly marked as safe. Those can be marked in the template by using
+the :doc:`raw<../filters/raw>` filter:
+
+.. code-block:: jinja
+
+    {% autoescape %}
+        {{ safe_value|raw }}
+    {% endautoescape %}
+
+Functions returning template data (like :doc:`macros<macro>` and
+:doc:`parent<../functions/parent>`) always return safe markup.
+
+.. note::
+
+    Twig is smart enough to not escape an already escaped value by the
+    :doc:`escape<../filters/escape>` filter.
+
+.. note::
+
+    Twig does not escape static expressions:
+
+    .. code-block:: jinja
+
+        {% set hello = "<strong>Hello</strong>" %}
+        {{ hello }}
+        {{ "<strong>world</strong>" }}
+
+    Will be rendered "<strong>Hello</strong> **world**".
+
+.. note::
+
+    The chapter :doc:`Twig for Developers<../api>` gives more information
+    about when and how automatic escaping is applied.

Twig/doc/tags/block.rst

+``block``
+=========
+
+Blocks are used for inheritance and act as placeholders and replacements at
+the same time. They are documented in detail in the documentation for the
+:doc:`extends<../tags/extends>` tag.
+
+Block names should consist of alphanumeric characters, and underscores. Dashes
+are not permitted.
+
+.. seealso:: :doc:`block<../functions/block>`, :doc:`parent<../functions/parent>`, :doc:`use<../tags/use>`, :doc:`extends<../tags/extends>`

Twig/doc/tags/deprecated.rst

+``deprecated``
+==============
+
+.. versionadded:: 1.36 and 2.6
+    The ``deprecated`` tag was added in Twig 1.36 and 2.6.
+
+Twig generates a deprecation notice (via a call to the ``trigger_error()``
+PHP function) where the ``deprecated`` tag is used in a template:
+
+.. code-block:: jinja
+
+    {# base.twig #}
+    {% deprecated 'The "base.twig" template is deprecated, use "layout.twig" instead.' %}
+    {% extends 'layout.twig' %}
+
+Also you can deprecate a block in the following way:
+
+.. code-block:: jinja
+
+    {% block hey %}
+        {% deprecated 'The "hey" block is deprecated, use "greet" instead.' %}
+        {{ block('greet') }}
+    {% endblock %}
+
+    {% block greet %}
+        Hey you!
+    {% endblock %}
+
+Note that by default, the deprecation notices are silenced and never displayed nor logged.
+See :ref:`deprecation-notices` to learn how to handle them.

Twig/doc/tags/do.rst

+``do``
+======
+
+.. versionadded:: 1.5
+    The ``do`` tag was added in Twig 1.5.
+
+The ``do`` tag works exactly like the regular variable expression (``{{ ...
+}}``) just that it doesn't print anything:
+
+.. code-block:: jinja
+
+    {% do 1 + 2 %}

Twig/doc/tags/embed.rst

+``embed``
+=========
+
+.. versionadded:: 1.8
+    The ``embed`` tag was added in Twig 1.8.
+
+The ``embed`` tag combines the behaviour of :doc:`include<include>` and
+:doc:`extends<extends>`.
+It allows you to include another template's contents, just like ``include``
+does. But it also allows you to override any block defined inside the
+included template, like when extending a template.
+
+Think of an embedded template as a "micro layout skeleton".
+
+.. code-block:: jinja
+
+    {% embed "teasers_skeleton.twig" %}
+        {# These blocks are defined in "teasers_skeleton.twig" #}
+        {# and we override them right here:                    #}
+        {% block left_teaser %}
+            Some content for the left teaser box
+        {% endblock %}
+        {% block right_teaser %}
+            Some content for the right teaser box
+        {% endblock %}
+    {% endembed %}
+
+The ``embed`` tag takes the idea of template inheritance to the level of
+content fragments. While template inheritance allows for "document skeletons",
+which are filled with life by child templates, the ``embed`` tag allows you to
+create "skeletons" for smaller units of content and re-use and fill them
+anywhere you like.
+
+Since the use case may not be obvious, let's look at a simplified example.
+Imagine a base template shared by multiple HTML pages, defining a single block
+named "content":
+
+.. code-block:: text
+
+    ┌─── page layout ─────────────────────┐
+    │                                     │
+    │           ┌── block "content" ──┐   │
+    │           │                     │   │
+    │           │                     │   │
+    │           │ (child template to  │   │
+    │           │  put content here)  │   │
+    │           │                     │   │
+    │           │                     │   │
+    │           └─────────────────────┘   │
+    │                                     │
+    └─────────────────────────────────────┘
+
+Some pages ("foo" and "bar") share the same content structure -
+two vertically stacked boxes:
+
+.. code-block:: text
+
+    ┌─── page layout ─────────────────────┐
+    │                                     │
+    │           ┌── block "content" ──┐   │
+    │           │ ┌─ block "top" ───┐ │   │
+    │           │ │                 │ │   │
+    │           │ └─────────────────┘ │   │
+    │           │ ┌─ block "bottom" ┐ │   │
+    │           │ │                 │ │   │
+    │           │ └─────────────────┘ │   │
+    │           └─────────────────────┘   │
+    │                                     │
+    └─────────────────────────────────────┘
+
+While other pages ("boom" and "baz") share a different content structure -
+two boxes side by side:
+
+.. code-block:: text
+
+    ┌─── page layout ─────────────────────┐
+    │                                     │
+    │           ┌── block "content" ──┐   │
+    │           │                     │   │    
+    │           │ ┌ block ┐ ┌ block ┐ │   │
+    │           │ │"left" │ │"right"│ │   │
+    │           │ │       │ │       │ │   │
+    │           │ │       │ │       │ │   │
+    │           │ └───────┘ └───────┘ │   │
+    │           └─────────────────────┘   │
+    │                                     │
+    └─────────────────────────────────────┘
+
+Without the ``embed`` tag, you have two ways to design your templates:
+
+* Create two "intermediate" base templates that extend the master layout
+  template: one with vertically stacked boxes to be used by the "foo" and
+  "bar" pages and another one with side-by-side boxes for the "boom" and
+  "baz" pages.
+
+* Embed the markup for the top/bottom and left/right boxes into each page
+  template directly.
+
+These two solutions do not scale well because they each have a major drawback:
+
+* The first solution may indeed work for this simplified example. But imagine
+  we add a sidebar, which may again contain different, recurring structures
+  of content. Now we would need to create intermediate base templates for
+  all occurring combinations of content structure and sidebar structure...
+  and so on.
+
+* The second solution involves duplication of common code with all its negative
+  consequences: any change involves finding and editing all affected copies
+  of the structure, correctness has to be verified for each copy, copies may
+  go out of sync by careless modifications etc.
+
+In such a situation, the ``embed`` tag comes in handy. The common layout
+code can live in a single base template, and the two different content structures,
+let's call them "micro layouts" go into separate templates which are embedded
+as necessary:
+
+Page template ``foo.twig``:
+
+.. code-block:: jinja
+
+    {% extends "layout_skeleton.twig" %}
+
+    {% block content %}
+        {% embed "vertical_boxes_skeleton.twig" %}
+            {% block top %}
+                Some content for the top box
+            {% endblock %}
+
+            {% block bottom %}
+                Some content for the bottom box
+            {% endblock %}
+        {% endembed %}
+    {% endblock %}
+
+And here is the code for ``vertical_boxes_skeleton.twig``:
+
+.. code-block:: html+jinja
+
+    <div class="top_box">
+        {% block top %}
+            Top box default content
+        {% endblock %}
+    </div>
+
+    <div class="bottom_box">
+        {% block bottom %}
+            Bottom box default content
+        {% endblock %}
+    </div>
+
+The goal of the ``vertical_boxes_skeleton.twig`` template being to factor
+out the HTML markup for the boxes.
+
+The ``embed`` tag takes the exact same arguments as the ``include`` tag:
+
+.. code-block:: jinja
+
+    {% embed "base" with {'foo': 'bar'} %}
+        ...
+    {% endembed %}
+
+    {% embed "base" with {'foo': 'bar'} only %}
+        ...
+    {% endembed %}
+
+    {% embed "base" ignore missing %}
+        ...
+    {% endembed %}
+
+.. warning::
+
+    As embedded templates do not have "names", auto-escaping strategies based
+    on the template name won't work as expected if you change the context (for
+    instance, if you embed a CSS/JavaScript template into an HTML one). In that
+    case, explicitly set the default auto-escaping strategy with the
+    ``autoescape`` tag.
+
+.. seealso:: :doc:`include<../tags/include>`

Twig/doc/tags/extends.rst

+``extends``
+===========
+
+The ``extends`` tag can be used to extend a template from another one.
+
+.. note::
+
+    Like PHP, Twig does not support multiple inheritance. So you can only have
+    one extends tag called per rendering. However, Twig supports horizontal
+    :doc:`reuse<use>`.
+
+Let's define a base template, ``base.html``, which defines a simple HTML
+skeleton document:
+
+.. code-block:: html+jinja
+
+    <!DOCTYPE html>
+    <html>
+        <head>
+            {% block head %}
+                <link rel="stylesheet" href="style.css" />
+                <title>{% block title %}{% endblock %} - My Webpage</title>
+            {% endblock %}
+        </head>
+        <body>
+            <div id="content">{% block content %}{% endblock %}</div>
+            <div id="footer">
+                {% block footer %}
+                    &copy; Copyright 2011 by <a href="http://domain.invalid/">you</a>.
+                {% endblock %}
+            </div>
+        </body>
+    </html>
+
+In this example, the :doc:`block<block>` tags define four blocks that child
+templates can fill in.
+
+All the ``block`` tag does is to tell the template engine that a child
+template may override those portions of the template.
+
+Child Template
+--------------
+
+A child template might look like this:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% block title %}Index{% endblock %}
+    {% block head %}
+        {{ parent() }}
+        <style type="text/css">
+            .important { color: #336699; }
+        </style>
+    {% endblock %}
+    {% block content %}
+        <h1>Index</h1>
+        <p class="important">
+            Welcome on my awesome homepage.
+        </p>
+    {% endblock %}
+
+The ``extends`` tag is the key here. It tells the template engine that this
+template "extends" another template. When the template system evaluates this
+template, first it locates the parent. The extends tag should be the first tag
+in the template.
+
+Note that since the child template doesn't define the ``footer`` block, the
+value from the parent template is used instead.
+
+You can't define multiple ``block`` tags with the same name in the same
+template. This limitation exists because a block tag works in "both"
+directions. That is, a block tag doesn't just provide a hole to fill - it also
+defines the content that fills the hole in the *parent*. If there were two
+similarly-named ``block`` tags in a template, that template's parent wouldn't
+know which one of the blocks' content to use.
+
+If you want to print a block multiple times you can however use the
+``block`` function:
+
+.. code-block:: jinja
+
+    <title>{% block title %}{% endblock %}</title>
+    <h1>{{ block('title') }}</h1>
+    {% block body %}{% endblock %}
+
+Parent Blocks
+-------------
+
+It's possible to render the contents of the parent block by using the
+:doc:`parent<../functions/parent>` function. This gives back the results of
+the parent block:
+
+.. code-block:: jinja
+
+    {% block sidebar %}
+        <h3>Table Of Contents</h3>
+        ...
+        {{ parent() }}
+    {% endblock %}
+
+Named Block End-Tags
+--------------------
+
+Twig allows you to put the name of the block after the end tag for better
+readability:
+
+.. code-block:: jinja
+
+    {% block sidebar %}
+        {% block inner_sidebar %}
+            ...
+        {% endblock inner_sidebar %}
+    {% endblock sidebar %}
+
+Of course, the name after the ``endblock`` word must match the block name.
+
+Block Nesting and Scope
+-----------------------
+
+Blocks can be nested for more complex layouts. Per default, blocks have access
+to variables from outer scopes:
+
+.. code-block:: jinja
+
+    {% for item in seq %}
+        <li>{% block loop_item %}{{ item }}{% endblock %}</li>
+    {% endfor %}
+
+Block Shortcuts
+---------------
+
+For blocks with little content, it's possible to use a shortcut syntax. The
+following constructs do the same thing:
+
+.. code-block:: jinja
+
+    {% block title %}
+        {{ page_title|title }}
+    {% endblock %}
+
+.. code-block:: jinja
+
+    {% block title page_title|title %}
+
+Dynamic Inheritance
+-------------------
+
+Twig supports dynamic inheritance by using a variable as the base template:
+
+.. code-block:: jinja
+
+    {% extends some_var %}
+
+If the variable evaluates to a ``\Twig\Template`` or a ``\Twig\TemplateWrapper``
+instance, Twig will use it as the parent template::
+
+    // {% extends layout %}
+
+    // deprecated as of Twig 1.28
+    $layout = $twig->loadTemplate('some_layout_template.twig');
+
+    // as of Twig 1.28
+    $layout = $twig->load('some_layout_template.twig');
+
+    $twig->display('template.twig', ['layout' => $layout]);
+
+.. versionadded:: 1.2
+    The possibility to pass an array of templates has been added in Twig 1.2.
+
+You can also provide a list of templates that are checked for existence. The
+first template that exists will be used as a parent:
+
+.. code-block:: jinja
+
+    {% extends ['layout.html', 'base_layout.html'] %}
+
+Conditional Inheritance
+-----------------------
+
+As the template name for the parent can be any valid Twig expression, it's
+possible to make the inheritance mechanism conditional:
+
+.. code-block:: jinja
+
+    {% extends standalone ? "minimum.html" : "base.html" %}
+
+In this example, the template will extend the "minimum.html" layout template
+if the ``standalone`` variable evaluates to ``true``, and "base.html"
+otherwise.
+
+How do blocks work?
+-------------------
+
+A block provides a way to change how a certain part of a template is rendered
+but it does not interfere in any way with the logic around it.
+
+Let's take the following example to illustrate how a block works and more
+importantly, how it does not work:
+
+.. code-block:: jinja
+
+    {# base.twig #}
+
+    {% for post in posts %}
+        {% block post %}
+            <h1>{{ post.title }}</h1>
+            <p>{{ post.body }}</p>
+        {% endblock %}
+    {% endfor %}
+
+If you render this template, the result would be exactly the same with or
+without the ``block`` tag. The ``block`` inside the ``for`` loop is just a way
+to make it overridable by a child template:
+
+.. code-block:: jinja
+
+    {# child.twig #}
+
+    {% extends "base.twig" %}
+
+    {% block post %}
+        <article>
+            <header>{{ post.title }}</header>
+            <section>{{ post.text }}</section>
+        </article>
+    {% endblock %}
+
+Now, when rendering the child template, the loop is going to use the block
+defined in the child template instead of the one defined in the base one; the
+executed template is then equivalent to the following one:
+
+.. code-block:: jinja
+
+    {% for post in posts %}
+        <article>
+            <header>{{ post.title }}</header>
+            <section>{{ post.text }}</section>
+        </article>
+    {% endfor %}
+
+Let's take another example: a block included within an ``if`` statement:
+
+.. code-block:: jinja
+
+    {% if posts is empty %}
+        {% block head %}
+            {{ parent() }}
+
+            <meta name="robots" content="noindex, follow">
+        {% endblock head %}
+    {% endif %}
+
+Contrary to what you might think, this template does not define a block
+conditionally; it just makes overridable by a child template the output of
+what will be rendered when the condition is ``true``.
+
+If you want the output to be displayed conditionally, use the following
+instead:
+
+.. code-block:: jinja
+
+    {% block head %}
+        {{ parent() }}
+
+        {% if posts is empty %}
+            <meta name="robots" content="noindex, follow">
+        {% endif %}
+    {% endblock head %}
+
+.. seealso:: :doc:`block<../functions/block>`, :doc:`block<../tags/block>`, :doc:`parent<../functions/parent>`, :doc:`use<../tags/use>`

Twig/doc/tags/filter.rst

+``filter``
+==========
+
+Filter sections allow you to apply regular Twig filters on a block of template
+data. Just wrap the code in the special ``filter`` section:
+
+.. code-block:: jinja
+
+    {% filter upper %}
+        This text becomes uppercase
+    {% endfilter %}
+
+You can also chain filters and pass arguments to them:
+
+.. code-block:: jinja
+
+    {% filter lower|escape('html') %}
+        <strong>SOME TEXT</strong>
+    {% endfilter %}
+
+    {# outputs "&lt;strong&gt;some text&lt;/strong&gt;" #}

Twig/doc/tags/flush.rst

+``flush``
+=========
+
+.. versionadded:: 1.5
+    The flush tag was added in Twig 1.5.
+
+The ``flush`` tag tells Twig to flush the output buffer:
+
+.. code-block:: jinja
+
+    {% flush %}
+
+.. note::
+
+    Internally, Twig uses the PHP `flush`_ function.
+
+.. _`flush`: https://secure.php.net/flush

Twig/doc/tags/for.rst

+``for``
+=======
+
+Loop over each item in a sequence. For example, to display a list of users
+provided in a variable called ``users``:
+
+.. code-block:: jinja
+
+    <h1>Members</h1>
+    <ul>
+        {% for user in users %}
+            <li>{{ user.username|e }}</li>
+        {% endfor %}
+    </ul>
+
+.. note::
+
+    A sequence can be either an array or an object implementing the
+    ``Traversable`` interface.
+
+If you do need to iterate over a sequence of numbers, you can use the ``..``
+operator:
+
+.. code-block:: jinja
+
+    {% for i in 0..10 %}
+        * {{ i }}
+    {% endfor %}
+
+The above snippet of code would print all numbers from 0 to 10.
+
+It can be also useful with letters:
+
+.. code-block:: jinja
+
+    {% for letter in 'a'..'z' %}
+        * {{ letter }}
+    {% endfor %}
+
+The ``..`` operator can take any expression at both sides:
+
+.. code-block:: jinja
+
+    {% for letter in 'a'|upper..'z'|upper %}
+        * {{ letter }}
+    {% endfor %}
+
+.. tip:
+
+    If you need a step different from 1, you can use the ``range`` function
+    instead.
+
+The `loop` variable
+-------------------
+
+Inside of a ``for`` loop block you can access some special variables:
+
+===================== =============================================================
+Variable              Description
+===================== =============================================================
+``loop.index``        The current iteration of the loop. (1 indexed)
+``loop.index0``       The current iteration of the loop. (0 indexed)
+``loop.revindex``     The number of iterations from the end of the loop (1 indexed)
+``loop.revindex0``    The number of iterations from the end of the loop (0 indexed)
+``loop.first``        True if first iteration
+``loop.last``         True if last iteration
+``loop.length``       The number of items in the sequence
+``loop.parent``       The parent context
+===================== =============================================================
+
+.. code-block:: jinja
+
+    {% for user in users %}
+        {{ loop.index }} - {{ user.username }}
+    {% endfor %}
+
+.. note::
+
+    The ``loop.length``, ``loop.revindex``, ``loop.revindex0``, and
+    ``loop.last`` variables are only available for PHP arrays, or objects that
+    implement the ``Countable`` interface. They are also not available when
+    looping with a condition.
+
+.. versionadded:: 1.2
+    The ``if`` modifier support has been added in Twig 1.2.
+
+Adding a condition
+------------------
+
+Unlike in PHP, it's not possible to ``break`` or ``continue`` in a loop. You
+can however filter the sequence during iteration which allows you to skip
+items. The following example skips all the users which are not active:
+
+.. code-block:: jinja
+
+    <ul>
+        {% for user in users if user.active %}
+            <li>{{ user.username|e }}</li>
+        {% endfor %}
+    </ul>
+
+The advantage is that the special loop variable will count correctly thus not
+counting the users not iterated over. Keep in mind that properties like
+``loop.last`` will not be defined when using loop conditions.
+
+.. note::
+
+    Using the ``loop`` variable within the condition is not recommended as it
+    will probably not be doing what you expect it to. For instance, adding a
+    condition like ``loop.index > 4`` won't work as the index is only
+    incremented when the condition is true (so the condition will never
+    match).
+
+The `else` Clause
+-----------------
+
+If no iteration took place because the sequence was empty, you can render a
+replacement block by using ``else``:
+
+.. code-block:: jinja
+
+    <ul>
+        {% for user in users %}
+            <li>{{ user.username|e }}</li>
+        {% else %}
+            <li><em>no user found</em></li>
+        {% endfor %}
+    </ul>
+
+Iterating over Keys
+-------------------
+
+By default, a loop iterates over the values of the sequence. You can iterate
+on keys by using the ``keys`` filter:
+
+.. code-block:: jinja
+
+    <h1>Members</h1>
+    <ul>
+        {% for key in users|keys %}
+            <li>{{ key }}</li>
+        {% endfor %}
+    </ul>
+
+Iterating over Keys and Values
+------------------------------
+
+You can also access both keys and values:
+
+.. code-block:: jinja
+
+    <h1>Members</h1>
+    <ul>
+        {% for key, user in users %}
+            <li>{{ key }}: {{ user.username|e }}</li>
+        {% endfor %}
+    </ul>
+
+Iterating over a Subset
+-----------------------
+
+You might want to iterate over a subset of values. This can be achieved using
+the :doc:`slice <../filters/slice>` filter:
+
+.. code-block:: jinja
+
+    <h1>Top Ten Members</h1>
+    <ul>
+        {% for user in users|slice(0, 10) %}
+            <li>{{ user.username|e }}</li>
+        {% endfor %}
+    </ul>

Twig/doc/tags/from.rst

+``from``
+========
+
+The ``from`` tag imports :doc:`macro<../tags/macro>` names into the current
+namespace. The tag is documented in detail in the documentation for the
+:doc:`import<../tags/import>` tag.
+
+.. seealso:: :doc:`macro<../tags/macro>`, :doc:`import<../tags/import>`

Twig/doc/tags/if.rst

+``if``
+======
+
+The ``if`` statement in Twig is comparable with the if statements of PHP.
+
+In the simplest form you can use it to test if an expression evaluates to
+``true``:
+
+.. code-block:: jinja
+
+    {% if online == false %}
+        <p>Our website is in maintenance mode. Please, come back later.</p>
+    {% endif %}
+
+You can also test if an array is not empty:
+
+.. code-block:: jinja
+
+    {% if users %}
+        <ul>
+            {% for user in users %}
+                <li>{{ user.username|e }}</li>
+            {% endfor %}
+        </ul>
+    {% endif %}
+
+.. note::
+
+    If you want to test if the variable is defined, use ``if users is
+    defined`` instead.
+
+You can also use ``not`` to check for values that evaluate to ``false``:
+
+.. code-block:: jinja
+
+    {% if not user.subscribed %}
+        <p>You are not subscribed to our mailing list.</p>
+    {% endif %}
+
+For multiple conditions, ``and`` and ``or`` can be used:
+
+.. code-block:: jinja
+
+    {% if temperature > 18 and temperature < 27 %}
+        <p>It's a nice day for a walk in the park.</p>
+    {% endif %}
+
+For multiple branches ``elseif`` and ``else`` can be used like in PHP. You can
+use more complex ``expressions`` there too:
+
+.. code-block:: jinja
+
+    {% if product.stock > 10 %}
+       Available
+    {% elseif product.stock > 0 %}
+       Only {{ product.stock }} left!
+    {% else %}
+       Sold-out!
+    {% endif %}
+
+.. note::
+
+    The rules to determine if an expression is ``true`` or ``false`` are the
+    same as in PHP; here are the edge cases rules:
+
+    ====================== ====================
+    Value                  Boolean evaluation
+    ====================== ====================
+    empty string           false
+    numeric zero           false
+    NAN (Not A Number)     true
+    INF (Infinity)         true
+    whitespace-only string true
+    string "0" or '0'      false
+    empty array            false
+    null                   false
+    non-empty array        true
+    object                 true
+    ====================== ====================

Twig/doc/tags/import.rst

+``import``
+==========
+
+Twig supports putting often used code into :doc:`macros<../tags/macro>`. These
+macros can go into different templates and get imported from there.
+
+There are two ways to import templates. You can import the complete template
+into a variable or request specific macros from it.
+
+Imagine we have a helper module that renders forms (called ``forms.html``):
+
+.. code-block:: jinja
+
+    {% macro input(name, value, type, size) %}
+        <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
+    {% endmacro %}
+
+    {% macro textarea(name, value, rows, cols) %}
+        <textarea name="{{ name }}" rows="{{ rows|default(10) }}" cols="{{ cols|default(40) }}">{{ value|e }}</textarea>
+    {% endmacro %}
+
+The easiest and most flexible is importing the whole module into a variable.
+That way you can access the attributes:
+
+.. code-block:: jinja
+
+    {% import 'forms.html' as forms %}
+
+    <dl>
+        <dt>Username</dt>
+        <dd>{{ forms.input('username') }}</dd>
+        <dt>Password</dt>
+        <dd>{{ forms.input('password', null, 'password') }}</dd>
+    </dl>
+    <p>{{ forms.textarea('comment') }}</p>
+
+Alternatively you can import names from the template into the current
+namespace:
+
+.. code-block:: jinja
+
+    {% from 'forms.html' import input as input_field, textarea %}
+
+    <dl>
+        <dt>Username</dt>
+        <dd>{{ input_field('username') }}</dd>
+        <dt>Password</dt>
+        <dd>{{ input_field('password', '', 'password') }}</dd>
+    </dl>
+    <p>{{ textarea('comment') }}</p>
+
+.. tip::
+
+    To import macros from the current file, use the special ``_self`` variable
+    for the source.
+
+.. seealso:: :doc:`macro<../tags/macro>`, :doc:`from<../tags/from>`

Twig/doc/tags/include.rst

+``include``
+===========
+
+The ``include`` statement includes a template and returns the rendered content
+of that file:
+
+.. code-block:: jinja
+
+    {% include 'header.html' %}
+        Body
+    {% include 'footer.html' %}
+
+.. note::
+
+    As of Twig 1.12, it is recommended to use the
+    :doc:`include<../functions/include>` function instead as it provides the
+    same features with a bit more flexibility:
+
+    * The ``include`` function is semantically more "correct" (including a
+      template outputs its rendered contents in the current scope; a tag should
+      not display anything);
+
+    * The rendered template can be more easily stored in a variable when using
+      the ``include`` function:
+
+      .. code-block:: jinja
+
+          {% set content %}{% include 'template.html' %}{% endset %}
+
+          {# vs #}
+
+          {% set content = include('template.html') %}
+
+    * The ``include`` function does not impose any specific order for
+      arguments thanks to :ref:`named arguments <named-arguments>`.
+
+Included templates have access to the variables of the active context.
+
+If you are using the filesystem loader, the templates are looked for in the
+paths defined by it.
+
+You can add additional variables by passing them after the ``with`` keyword:
+
+.. code-block:: jinja
+
+    {# template.html will have access to the variables from the current context and the additional ones provided #}
+    {% include 'template.html' with {'foo': 'bar'} %}
+
+    {% set vars = {'foo': 'bar'} %}
+    {% include 'template.html' with vars %}
+
+You can disable access to the context by appending the ``only`` keyword:
+
+.. code-block:: jinja
+
+    {# only the foo variable will be accessible #}
+    {% include 'template.html' with {'foo': 'bar'} only %}
+
+.. code-block:: jinja
+
+    {# no variables will be accessible #}
+    {% include 'template.html' only %}
+
+.. tip::
+
+    When including a template created by an end user, you should consider
+    sandboxing it. More information in the :doc:`Twig for Developers<../api>`
+    chapter and in the :doc:`sandbox<../tags/sandbox>` tag documentation.
+
+The template name can be any valid Twig expression:
+
+.. code-block:: jinja
+
+    {% include some_var %}
+    {% include ajax ? 'ajax.html' : 'not_ajax.html' %}
+
+And if the expression evaluates to a ``\Twig\Template`` or a
+``\Twig\TemplateWrapper`` instance, Twig will use it directly::
+
+    // {% include template %}
+
+    // deprecated as of Twig 1.28
+    $template = $twig->loadTemplate('some_template.twig');
+
+    // as of Twig 1.28
+    $template = $twig->load('some_template.twig');
+
+    $twig->display('template.twig', ['template' => $template]);
+
+.. versionadded:: 1.2
+    The ``ignore missing`` feature has been added in Twig 1.2.
+
+You can mark an include with ``ignore missing`` in which case Twig will ignore
+the statement if the template to be included does not exist. It has to be
+placed just after the template name. Here some valid examples:
+
+.. code-block:: jinja
+
+    {% include 'sidebar.html' ignore missing %}
+    {% include 'sidebar.html' ignore missing with {'foo': 'bar'} %}
+    {% include 'sidebar.html' ignore missing only %}
+
+.. versionadded:: 1.2
+    The possibility to pass an array of templates has been added in Twig 1.2.
+
+You can also provide a list of templates that are checked for existence before
+inclusion. The first template that exists will be included:
+
+.. code-block:: jinja
+
+    {% include ['page_detailed.html', 'page.html'] %}
+
+If ``ignore missing`` is given, it will fall back to rendering nothing if none
+of the templates exist, otherwise it will throw an exception.

Twig/doc/tags/index.rst

+Tags
+====
+
+.. toctree::
+    :maxdepth: 1
+
+    autoescape
+    block
+    do
+    embed
+    extends
+    filter
+    flush
+    for
+    from
+    if
+    import
+    include
+    macro
+    sandbox
+    set
+    spaceless
+    use
+    verbatim
+    with
+    deprecated

Twig/doc/tags/macro.rst

+``macro``
+=========
+
+.. versionadded:: 1.12
+
+    The possibility to define default values for arguments in the macro
+    signature was added in Twig 1.12.
+
+Macros are comparable with functions in regular programming languages. They
+are useful to put often used HTML idioms into reusable elements to not repeat
+yourself.
+
+Here is a small example of a macro that renders a form element:
+
+.. code-block:: jinja
+
+    {% macro input(name, value, type = "text", size = 20) %}
+        <input type="{{ type }}" name="{{ name }}" value="{{ value|e }}" size="{{ size }}" />
+    {% endmacro %}
+
+Each argument can have a default value (here ``text`` is the default value for
+``type`` if not provided in the call).
+
+.. note::
+
+    Before Twig 1.12, defining default argument values was done via the
+    ``default`` filter in the macro body:
+
+    .. code-block:: jinja
+
+        {% macro input(name, value, type, size) %}
+            <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
+        {% endmacro %}
+
+Macros differ from native PHP functions in a few ways:
+
+* Arguments of a macro are always optional.
+
+* If extra positional arguments are passed to a macro, they end up in the
+  special ``varargs`` variable as a list of values.
+
+But as with PHP functions, macros don't have access to the current template
+variables.
+
+.. tip::
+
+    You can pass the whole context as an argument by using the special
+    ``_context`` variable.
+
+Import
+------
+
+Macros can be defined in any template, and need to be "imported" before being
+used (see the documentation for the :doc:`import<../tags/import>` tag for more
+information):
+
+.. code-block:: jinja
+
+    {% import "forms.html" as forms %}
+
+The above ``import`` call imports the "forms.html" file (which can contain only
+macros, or a template and some macros), and import the functions as items of
+the ``forms`` variable.
+
+The macro can then be called at will:
+
+.. code-block:: jinja
+
+    <p>{{ forms.input('username') }}</p>
+    <p>{{ forms.input('password', null, 'password') }}</p>
+
+If macros are defined and used in the same template, you can use the
+special ``_self`` variable to import them:
+
+.. code-block:: jinja
+
+    {% import _self as forms %}
+
+    <p>{{ forms.input('username') }}</p>
+
+.. warning::
+
+    When you define a macro in the template where you are going to use it, you
+    might be tempted to call the macro directly via ``_self.input()`` instead
+    of importing it; even if seems to work, this is just a side-effect of the
+    current implementation and it won't work anymore in Twig 2.x.
+
+When you want to use a macro in another macro from the same file, you need to
+import it locally:
+
+.. code-block:: jinja
+
+    {% macro input(name, value, type, size) %}
+        <input type="{{ type|default('text') }}" name="{{ name }}" value="{{ value|e }}" size="{{ size|default(20) }}" />
+    {% endmacro %}
+
+    {% macro wrapped_input(name, value, type, size) %}
+        {% import _self as forms %}
+
+        <div class="field">
+            {{ forms.input(name, value, type, size) }}
+        </div>
+    {% endmacro %}
+
+Named Macro End-Tags
+--------------------
+
+Twig allows you to put the name of the macro after the end tag for better
+readability:
+
+.. code-block:: jinja
+
+    {% macro input() %}
+        ...
+    {% endmacro input %}
+
+Of course, the name after the ``endmacro`` word must match the macro name.
+
+.. seealso:: :doc:`from<../tags/from>`, :doc:`import<../tags/import>`

Twig/doc/tags/sandbox.rst

+``sandbox``
+===========
+
+The ``sandbox`` tag can be used to enable the sandboxing mode for an included
+template, when sandboxing is not enabled globally for the Twig environment:
+
+.. code-block:: jinja
+
+    {% sandbox %}
+        {% include 'user.html' %}
+    {% endsandbox %}
+
+.. warning::
+
+    The ``sandbox`` tag is only available when the sandbox extension is
+    enabled (see the :doc:`Twig for Developers<../api>` chapter).
+
+.. note::
+
+    The ``sandbox`` tag can only be used to sandbox an include tag and it
+    cannot be used to sandbox a section of a template. The following example
+    won't work:
+
+    .. code-block:: jinja
+
+        {% sandbox %}
+            {% for i in 1..2 %}
+                {{ i }}
+            {% endfor %}
+        {% endsandbox %}

Twig/doc/tags/set.rst

+``set``
+=======
+
+Inside code blocks you can also assign values to variables. Assignments use
+the ``set`` tag and can have multiple targets.
+
+Here is how you can assign the ``bar`` value to the ``foo`` variable:
+
+.. code-block:: jinja
+
+    {% set foo = 'bar' %}
+
+After the ``set`` call, the ``foo`` variable is available in the template like
+any other ones:
+
+.. code-block:: jinja
+
+    {# displays bar #}
+    {{ foo }}
+
+The assigned value can be any valid :ref:`Twig expression
+<twig-expressions>`:
+
+.. code-block:: jinja
+
+    {% set foo = [1, 2] %}
+    {% set foo = {'foo': 'bar'} %}
+    {% set foo = 'foo' ~ 'bar' %}
+
+Several variables can be assigned in one block:
+
+.. code-block:: jinja
+
+    {% set foo, bar = 'foo', 'bar' %}
+
+    {# is equivalent to #}
+
+    {% set foo = 'foo' %}
+    {% set bar = 'bar' %}
+
+The ``set`` tag can also be used to 'capture' chunks of text:
+
+.. code-block:: jinja
+
+    {% set foo %}
+        <div id="pagination">
+            ...
+        </div>
+    {% endset %}
+
+.. caution::
+
+    If you enable automatic output escaping, Twig will only consider the
+    content to be safe when capturing chunks of text.
+
+.. note::
+
+    Note that loops are scoped in Twig; therefore a variable declared inside a
+    ``for`` loop is not accessible outside the loop itself:
+
+    .. code-block:: jinja
+
+        {% for item in list %}
+            {% set foo = item %}
+        {% endfor %}
+
+        {# foo is NOT available #}
+
+    If you want to access the variable, just declare it before the loop:
+
+    .. code-block:: jinja
+
+        {% set foo = "" %}
+        {% for item in list %}
+            {% set foo = item %}
+        {% endfor %}
+
+        {# foo is available #}

Twig/doc/tags/spaceless.rst

+``spaceless``
+=============
+
+.. tip::
+
+    As of Twig 1.38, use the :doc:`spaceless <../filters/spaceless>` filter instead.
+
+Use the ``spaceless`` tag to remove whitespace *between HTML tags*, not
+whitespace within HTML tags or whitespace in plain text:
+
+.. code-block:: jinja
+
+    {% spaceless %}
+        <div>
+            <strong>foo</strong>
+        </div>
+    {% endspaceless %}
+
+    {# output will be <div><strong>foo</strong></div> #}
+
+This tag is not meant to "optimize" the size of the generated HTML content but
+merely to avoid extra whitespace between HTML tags to avoid browser rendering
+quirks under some circumstances.
+
+.. tip::
+
+    If you want to optimize the size of the generated HTML content, gzip
+    compress the output instead.
+
+.. tip::
+
+    If you want to create a tag that actually removes all extra whitespace in
+    an HTML string, be warned that this is not as easy as it seems to be
+    (think of ``textarea`` or ``pre`` tags for instance). Using a third-party
+    library like Tidy is probably a better idea.
+
+.. tip::
+
+    For more information on whitespace control, read the
+    :ref:`dedicated section <templates-whitespace-control>` of the documentation and learn how
+    you can also use the whitespace control modifier on your tags.

Twig/doc/tags/use.rst

+``use``
+=======
+
+.. versionadded:: 1.1
+    Horizontal reuse was added in Twig 1.1.
+
+.. note::
+
+    Horizontal reuse is an advanced Twig feature that is hardly ever needed in
+    regular templates. It is mainly used by projects that need to make
+    template blocks reusable without using inheritance.
+
+Template inheritance is one of the most powerful features of Twig but it is
+limited to single inheritance; a template can only extend one other template.
+This limitation makes template inheritance simple to understand and easy to
+debug:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% block title %}{% endblock %}
+    {% block content %}{% endblock %}
+
+Horizontal reuse is a way to achieve the same goal as multiple inheritance,
+but without the associated complexity:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% use "blocks.html" %}
+
+    {% block title %}{% endblock %}
+    {% block content %}{% endblock %}
+
+The ``use`` statement tells Twig to import the blocks defined in
+``blocks.html`` into the current template (it's like macros, but for blocks):
+
+.. code-block:: jinja
+
+    {# blocks.html #}
+    
+    {% block sidebar %}{% endblock %}
+
+In this example, the ``use`` statement imports the ``sidebar`` block into the
+main template. The code is mostly equivalent to the following one (the
+imported blocks are not outputted automatically):
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% block sidebar %}{% endblock %}
+    {% block title %}{% endblock %}
+    {% block content %}{% endblock %}
+
+.. note::
+
+    The ``use`` tag only imports a template if it does not extend another
+    template, if it does not define macros, and if the body is empty. But it
+    can *use* other templates.
+
+.. note::
+
+    Because ``use`` statements are resolved independently of the context
+    passed to the template, the template reference cannot be an expression.
+
+The main template can also override any imported block. If the template
+already defines the ``sidebar`` block, then the one defined in ``blocks.html``
+is ignored. To avoid name conflicts, you can rename imported blocks:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% use "blocks.html" with sidebar as base_sidebar, title as base_title %}
+
+    {% block sidebar %}{% endblock %}
+    {% block title %}{% endblock %}
+    {% block content %}{% endblock %}
+
+.. versionadded:: 1.3
+    The ``parent()`` support was added in Twig 1.3.
+
+The ``parent()`` function automatically determines the correct inheritance
+tree, so it can be used when overriding a block defined in an imported
+template:
+
+.. code-block:: jinja
+
+    {% extends "base.html" %}
+
+    {% use "blocks.html" %}
+
+    {% block sidebar %}
+        {{ parent() }}
+    {% endblock %}
+
+    {% block title %}{% endblock %}
+    {% block content %}{% endblock %}
+
+In this example, ``parent()`` will correctly call the ``sidebar`` block from
+the ``blocks.html`` template.
+
+.. tip::
+
+    In Twig 1.2, renaming allows you to simulate inheritance by calling the
+    "parent" block:
+
+    .. code-block:: jinja
+
+        {% extends "base.html" %}
+
+        {% use "blocks.html" with sidebar as parent_sidebar %}
+
+        {% block sidebar %}
+            {{ block('parent_sidebar') }}
+        {% endblock %}
+
+.. note::
+
+    You can use as many ``use`` statements as you want in any given template.
+    If two imported templates define the same block, the latest one wins.

Twig/doc/tags/verbatim.rst

+``verbatim``
+============
+
+.. versionadded:: 1.12
+    The ``verbatim`` tag was added in Twig 1.12 (it was named ``raw`` before).
+
+The ``verbatim`` tag marks sections as being raw text that should not be
+parsed. For example to put Twig syntax as example into a template you can use
+this snippet:
+
+.. code-block:: jinja
+
+    {% verbatim %}
+        <ul>
+        {% for item in seq %}
+            <li>{{ item }}</li>
+        {% endfor %}
+        </ul>
+    {% endverbatim %}
+
+.. note::
+
+    The ``verbatim`` tag works in the exact same way as the old ``raw`` tag,
+    but was renamed to avoid confusion with the ``raw`` filter.
\ No newline at end of file

Twig/doc/tags/with.rst

+``with``
+========
+
+.. versionadded:: 1.28
+    The ``with`` tag was added in Twig 1.28.
+
+Use the ``with`` tag to create a new inner scope. Variables set within this
+scope are not visible outside of the scope:
+
+.. code-block:: jinja
+
+    {% with %}
+        {% set foo = 42 %}
+        {{ foo }}           foo is 42 here
+    {% endwith %}
+    foo is not visible here any longer
+
+Instead of defining variables at the beginning of the scope, you can pass a
+hash of variables you want to define in the ``with`` tag; the previous example
+is equivalent to the following one:
+
+.. code-block:: jinja
+
+    {% with { foo: 42 } %}
+        {{ foo }}           foo is 42 here
+    {% endwith %}
+    foo is not visible here any longer
+
+    {# it works with any expression that resolves to a hash #}
+    {% set vars = { foo: 42 } %}
+    {% with vars %}
+        ...
+    {% endwith %}
+
+By default, the inner scope has access to the outer scope context; you can
+disable this behavior by appending the ``only`` keyword:
+
+.. code-block:: jinja
+
+    {% set bar = 'bar' %}
+    {% with { foo: 42 } only %}
+        {# only foo is defined #}
+        {# bar is not defined #}
+    {% endwith %}

Twig/doc/tests/constant.rst

+``constant``
+============
+
+.. versionadded: 1.13.1
+    constant now accepts object instances as the second argument.
+
+``constant`` checks if a variable has the exact same value as a constant. You
+can use either global constants or class constants:
+
+.. code-block:: jinja
+
+    {% if post.status is constant('Post::PUBLISHED') %}
+        the status attribute is exactly the same as Post::PUBLISHED
+    {% endif %}
+
+You can test constants from object instances as well:
+
+.. code-block:: jinja
+
+    {% if post.status is constant('PUBLISHED', post) %}
+        the status attribute is exactly the same as Post::PUBLISHED
+    {% endif %}

Twig/doc/tests/defined.rst

+``defined``
+===========
+
+``defined`` checks if a variable is defined in the current context. This is very
+useful if you use the ``strict_variables`` option:
+
+.. code-block:: jinja
+
+    {# defined works with variable names #}
+    {% if foo is defined %}
+        ...
+    {% endif %}
+
+    {# and attributes on variables names #}
+    {% if foo.bar is defined %}
+        ...
+    {% endif %}
+
+    {% if foo['bar'] is defined %}
+        ...
+    {% endif %}
+
+When using the ``defined`` test on an expression that uses variables in some
+method calls, be sure that they are all defined first:
+
+.. code-block:: jinja
+
+    {% if var is defined and foo.method(var) is defined %}
+        ...
+    {% endif %}

Twig/doc/tests/divisibleby.rst

+``divisible by``
+================
+
+.. versionadded:: 1.14.2
+    The ``divisible by`` test was added in Twig 1.14.2 as an alias for
+    ``divisibleby``.
+
+``divisible by`` checks if a variable is divisible by a number:
+
+.. code-block:: jinja
+
+    {% if loop.index is divisible by(3) %}
+        ...
+    {% endif %}

Twig/doc/tests/empty.rst

+``empty``
+=========
+
+.. versionadded:: 1.33
+
+    Support for the ``__toString()`` magic method has been added in Twig 1.33.
+
+``empty`` checks if a variable is an empty string, an empty array, an empty
+hash, exactly ``false``, or exactly ``null``.
+
+For objects that implement the ``Countable`` interface, ``empty`` will check the
+return value of the ``count()`` method.
+
+For objects that implement the ``__toString()`` magic method (and not ``Countable``),
+it will check if an empty string is returned.
+
+.. code-block:: jinja
+
+    {% if foo is empty %}
+        ...
+    {% endif %}
+

Twig/doc/tests/even.rst

+``even``
+========
+
+``even`` returns ``true`` if the given number is even:
+
+.. code-block:: jinja
+
+    {{ var is even }}
+
+.. seealso:: :doc:`odd<../tests/odd>`

Twig/doc/tests/index.rst

+Tests
+=====
+
+.. toctree::
+    :maxdepth: 1
+
+    constant
+    defined
+    divisibleby
+    empty
+    even
+    iterable
+    null
+    odd
+    sameas

Twig/doc/tests/iterable.rst

+``iterable``
+============
+
+.. versionadded:: 1.7
+    The iterable test was added in Twig 1.7.
+
+``iterable`` checks if a variable is an array or a traversable object:
+
+.. code-block:: jinja
+
+    {# evaluates to true if the foo variable is iterable #}
+    {% if users is iterable %}
+        {% for user in users %}
+            Hello {{ user }}!
+        {% endfor %}
+    {% else %}
+        {# users is probably a string #}
+        Hello {{ users }}!
+    {% endif %}

Twig/doc/tests/null.rst

+``null``
+========
+
+``null`` returns ``true`` if the variable is ``null``:
+
+.. code-block:: jinja
+
+    {{ var is null }}
+
+.. note::
+
+    ``none`` is an alias for ``null``.

Twig/doc/tests/odd.rst

+``odd``
+=======
+
+``odd`` returns ``true`` if the given number is odd:
+
+.. code-block:: jinja
+
+    {{ var is odd }}
+
+.. seealso:: :doc:`even<../tests/even>`

Twig/doc/tests/sameas.rst

+``same as``
+===========
+
+.. versionadded:: 1.14.2
+    The ``same as`` test was added in Twig 1.14.2 as an alias for ``sameas``.
+
+``same as`` checks if a variable is the same as another variable.
+This is the equivalent to ``===`` in PHP:
+
+.. code-block:: jinja
+
+    {% if foo.attribute is same as(false) %}
+        the foo attribute really is the 'false' PHP value
+    {% endif %}

Twig/ext/twig/.gitignore

+*.sw*
+.deps
+Makefile
+Makefile.fragments
+Makefile.global
+Makefile.objects
+acinclude.m4
+aclocal.m4
+build/
+config.cache
+config.guess
+config.h
+config.h.in
+config.log
+config.nice
+config.status
+config.sub
+configure
+configure.in
+install-sh
+libtool
+ltmain.sh
+missing
+mkinstalldirs
+run-tests.php
+twig.loT
+.libs/
+modules/
+twig.la
+twig.lo

Twig/ext/twig/config.m4

+dnl config.m4 for extension twig
+
+PHP_ARG_ENABLE(twig, whether to enable twig support,
+[  --enable-twig           Enable twig support])
+
+if test "$PHP_TWIG" != "no"; then
+  PHP_NEW_EXTENSION(twig, twig.c, $ext_shared)
+fi