crunch / ssi-bundle
Server Side Includes (SSI) fragment renderer for Symfony2 applications
Requires
- php: >=5.5.9
- symfony/config: ~2.3|~3.0
- symfony/dependency-injection: ~2.3|~3.0
- symfony/http-foundation: ~2.3|~3.0
- symfony/http-kernel: ~2.3|~3.0
Requires (Dev)
- phpunit/phpunit: 3.7.*
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.
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 yourAppKernel
-classnew 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
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.
Requirements
- PHP => 5.3
Contributors
See CONTRIBUTING.md for details on how to contribute.
- Sebastian "KingCrunch" Krebs krebs.seb@gmail.com -- http://www.kingcrunch.de/ (german)
License
This library is licensed under the MIT License. See the LICENSE file for details.