- What is ongr/ssi-bundle?
- ongr/ssi-bundle is an archived Symfony2 bundle that adds Server Side Includes support for marking page fragments for asynchronous, cache-friendly rendering by the web server. It integrates with Twig and Symfony's fragment rendering so dynamic blocks can stay out of the main response. It is not a Laravel package.
- Can I use ongr/ssi-bundle in a Laravel application?
- Not as a drop-in dependency. The package is built around Symfony's bundle registration, DI container, configuration tree, and fragment conventions, while Laravel uses service providers and Blade. You would need to port the small directive builder and renderer logic into Laravel idioms rather than composer require the bundle.
- Does ongr/ssi-bundle support Laravel 10 or Laravel 11?
- No. The bundle targets Symfony 2.x and PHP 5.x from around 2014, so it has no Laravel 10 or 11 support and will likely conflict with modern Symfony components used by current Laravel versions. Treat it as a reference implementation, not a supported Laravel dependency.
- How does ongr/ssi-bundle render SSI fragments?
- It emits Server Side Include directives such as include virtual comments so an upstream web server can assemble a cached page shell with dynamic holes. The actual fragment rendering is handled by Symfony's fragment conventions and the web server's SSI processing. The package's real logic is mostly directive generation and configuration for fragment paths and attributes.
- Why is an archived 2014 package a risk for production?
- The repository is read-only and abandoned, with the last release in October 2014 targeting PHP 5.x and Symfony 2.x. Both PHP 5.6 and Symfony 2 reached end of life in 2018, so there are no security patches, maintained transitive dependencies, or CI signal. Low stars and zero dependents also mean little evidence of production hardening.
- Can Composer install ongr/ssi-bundle alongside modern Laravel dependencies?
- It is unlikely to install cleanly. The bundle's pinned Symfony 2.x constraints can conflict with the modern symfony/http-foundation and symfony/http-kernel versions pulled by current Laravel applications. Even if installation succeeds through dependency overrides, the abandoned code is not a safe production dependency.
- How would I implement SSI fragment rendering in Laravel without this bundle?
- Build the minimal pieces directly: a config file for fragment routes and attributes, a singleton renderer that builds the SSI directive string, a Blade directive such as @ssi, a fragment controller or invokable route, and middleware for Cache-Control and Vary headers. Validate and escape any values that reach the directive. This keeps the SSI contract as plain HTTP and avoids Symfony 2.x baggage.
- Is SSI injection a security concern when using this package?
- Yes. If user-controlled values reach an SSI directive path or attributes, the application is exposed to SSI injection and path traversal. The abandoned bundle offers no modern mitigations or maintenance. In a Laravel port, use a strict allowlist of fragment names and never interpolate raw request input into directives.
- Does ongr/ssi-bundle work with nginx, Apache, or Varnish?
- It emits SSI directives that nginx can process with ssi on and Apache can process with mod_include. Varnish commonly uses ESI syntax instead, so it is not a direct equivalent. SSI is inert without the correct web server or cache-tier configuration in every environment.
- Is there a maintained Laravel alternative to ongr/ssi-bundle?
- There is no maintained Laravel equivalent that should be adopted from this package. For template composition, use Blade partials, view composers, or fragment endpoints. For edge-assembled cached shells, implement a small custom SSI or ESI layer that fits your nginx, Varnish, or CDN setup.