Server Side Includes (SSI) fragment renderer for Symfony2 applications

Installs: 453

Dependents: 0

Stars: 15

Watchers: 6

Forks: 3

Open Issues: 1

Type: symfony-bundle

v0.2.1 2013-06-03 21:01 UTC


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.