crunch/ssi-bundle

This package is abandoned and no longer maintained. No replacement package was suggested.

Server Side Includes (SSI) fragment renderer for Symfony2 applications

Installs: 616

Dependents: 0

Suggesters: 0

Security: 0

Type:symfony-bundle

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

This package is auto-updated.

Last update: 2023-01-10 21:48:33 UTC


README

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.

Installation

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
    

Usage

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);
$kernel->run();
$kernel->terminate();

Configuration

crunch_ssi:
    inline:     false
    use_header: false
OptionDescription
inlineWhether, or not to always use the inline-fragment renderer.
use_headerWhether, 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.

Requirements

  • PHP => 5.3

Contributors

See CONTRIBUTING.md for details on how to contribute.

License

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