Server Side Includes (SSI) fragment renderer for Symfony2 applications

v0.3.0 2016-02-04 20:57 UTC


Note: Since Symfony 2.6.0-beta1 SSI support is integrated into Symfony itself, thus bundle is "partially deprecated" and aims to primary support <2.6. This said when there are incompatibility issues with versions >=2.6 I'd suggest to use the builtin functionality instead of this bundle.

Build Status Total Downloads Latest Stable Version

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.


As usual

  • Add the corresponding package to your composer.json. See the list linked above for available packages or simply "crunch\ssi-bundle":"dev-master"

  • Register Crunch\Bundle\SSIBundle\CrunchSSIBundle within your AppKernel-class

      new Crunch\Bundle\SSIBundle\CrunchSSIBundle


Within twig

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

The kernel proxy

Usually it should be sufficient to set inline to true during development (see bewlow). 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);


    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-header.

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 it will add a Surrogate-Control-header to the response.

Note, that the default inline-fragment-renderer does not take care of any cache header. 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, because the page as a whole is only affected by the cache headers from the master request.

A Note about Nginx

Usually it should be fine to set ssi on within your nginx.conf (or included). However, there is a problem: The request uri.

  • When set to $request_uri it will always use the initial request to request the backend (php-fpm). This leads to an infinite recursion, that (in best case!) simply kills your browser
  • When set to $uri it will use the completely rewritten uri instead, which works, but the script filename (usually /app.php) is already prepended.

So at the end this works fine for me

fastcgi_split_path_info ^(.+\.php)(/.*)$;
fastcgi_param           PATH_INFO $fastcgi_path_info;
fastcgi_param           PATH_TRANSLATED $document_root$fastcgi_path_info;
fastcgi_param           REQUEST_URI $fastcgi_path_info;

As you can see I set the request uri the PATH_INFO. This works, because Symfony2 doesn't really take care about the real request uri. At least for now I didn't noticed any side effects.


  • PHP => 5.3


See for details on how to contribute.


This library is licensed under the MIT License. See the LICENSE file for details.