<commit_before>Crunch\SSIBundle [![Build Status](https://secure.travis-ci.org/CrunchPHP/SSIBundle.png)](http://travis-ci.org/CrunchPHP/SSIBundle)
============
SSI support for Symfony2 applications designed for use with nginx, but should work for others
as well. It includes a kernel proxy class for substituting the SSI-tags during development, or as fallback.

* [List of available packages at packagist.org](http://packagist.org/packages/crunch/ssi-bundle)
  (See also [Composer: Declaring dependencies](http://getcomposer.org/doc/00-intro.md#declaring-dependencies))

Installation
============

* Add the corresponding package to your `composer.json`. See the list linked above for available packages
* Register `Crunch\Bundle\SSIBundle\CrunchSSIBundle` within your `AppKernel`-class

Usage
=====
Within twig

    {{ render('/path/to/interal', {strategy: 'ssi'}) }}

To avoid problems because of an "unknown fragment renderer" it is always enabled.

The kernel proxy
----------------
Usually it should be sufficient to set `inline` to `true` during development. However, there is a
kernel proxy you can use, that will act as SSI-capable server. In your `app_dev.php`:

    $kernel = new AppKernel($env, $debug);
    // prepare kernel
    $kernel = new \Crunch\Bundle\SSIBundle\KernelProxy\SSIProxy($kernel);
    $kernel->run();
    $kernel->terminate();



Configuration
=============

    crunch_ssi:
        inline: false
        use_header: true

| Option       | default | Description
| ------------ | ------- | -----------
| `inline`     | `false` | Whether, or not the fragment renderer should always fallback
                           to the inline-fragment renderer. Technically this disables
                           the rendering of the SSI-tags
| `use_header` | `false` | Whether, or not the bundle should respect both request and
                           response headers. If set to `true` it will fallback to the
                           inline-fragment-renderer, when there is no `Surrogate-Capability`-
                           request-header set, and it will add a `Surrogate-Control`-
                           header to the response
<commit_msg>Trying to fix broken multiline table<commit_after>Crunch\SSIBundle [![Build Status](https://secure.travis-ci.org/CrunchPHP/SSIBundle.png)](http://travis-ci.org/CrunchPHP/SSIBundle)
============
SSI support for Symfony2 applications designed for use with nginx, but should work for others
as well. It includes a kernel proxy class for substituting the SSI-tags during development, or as fallback.

* [List of available packages at packagist.org](http://packagist.org/packages/crunch/ssi-bundle)
  (See also [Composer: Declaring dependencies](http://getcomposer.org/doc/00-intro.md#declaring-dependencies))

Installation
============

* Add the corresponding package to your `composer.json`. See the list linked above for available packages
* Register `Crunch\Bundle\SSIBundle\CrunchSSIBundle` within your `AppKernel`-class

Usage
=====
Within twig

    {{ render('/path/to/interal', {strategy: 'ssi'}) }}

The kernel proxy
----------------
Usually it should be sufficient to set `inline` to `true` during development. However, there is a
kernel proxy you can use, that will act as SSI-capable server. In your `app_dev.php`:

    $kernel = new AppKernel($env, $debug);
    // prepare kernel
    $kernel = new \Crunch\Bundle\SSIBundle\KernelProxy\SSIProxy($kernel);
    $kernel->run();
    $kernel->terminate();

Configuration
=============

    crunch_ssi:
        inline:     false
        use_header: false

| Option       | Description
|--------------| -------------------------------------
| `inline`     | Whether, or not to _always_ use the inline-fragment renderer.
| `use_header` | Whether, or not respect request and create response headers.

`inline` technically disables the rendering of the SSI-tags completely. This is useful,
if you don't want to use SSI anymore, but have several calls to the SSI fragment-renderer
within your templates, which else will lead to a "unknown renderer 'ssi'". Also it is
useful for development.

If `use_header` is set to `true` it will fallback to the inline-fragment-renderer, but only
when there is no `Surrogate-Capability`-request-header set. Additional and it will add a
`Surrogate-Control`-header to the response.

Note, that the default inline-fragment-renderer does not respect any cache headers. So if you
have short-living partials, that you want to render within other templates, they may be served
within a page even if they are theoretically outdated.

{'fraction_non_alphanumeric': 0.12846237731733914, 'fraction_numerical': 0.0013086150490730644, 'mean_word_length': 3.2462962962962965, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '32519', 'n_tokens_mistral': 1276, 'n_tokens_neox': 1238, 'n_words': 467}