- Can I use slim/php-view as the view engine in a Laravel application?
- Not natively. slim/php-view is a PSR-7 response renderer for Slim, while Laravel's view layer expects an Illuminate\Contracts\View\Engine behind the View Factory and FileViewFinder. Making it work would require a PSR-7 bridge (symfony/psr-http-message-bridge plus nyholm/psr7 or slim/psr7), a singleton PhpRenderer bound with a template path, and conversion of the returned PSR-7 response back into a Laravel response. The cleaner pattern is to keep the renderer inside a bounded Slim module and delegate or mount it from Laravel rather than replacing Blade.
- How do I install and configure slim/php-view in a Slim 4 application?
- Install it with composer require slim/php-view, then instantiate PhpRenderer with the absolute path to your templates directory. From a route handler you call render($response, 'template.php', $data), which returns a new PSR-7 response with the rendered output as the body. You can set a layout with setLayout() and register shared values with setAttributes() or addAttribute(). No service provider, config file, or compilation step is involved.
- Does slim/php-view support layouts, sections, and partials like Blade?
- It supports layouts through setLayout() and partials through ordinary PHP include statements inside your templates. It does not provide Blade-style sections, stacks, components, directives, or automatic escaping, because templates are plain PHP files rendered with extracted data. Shared attributes let you pass common values such as a site name or current user to every template. If you need richer template inheritance, a real template engine is a better fit.
- Which Laravel versions does slim/php-view support?
- The package does not declare Laravel support at all; it targets Slim 3 and 4 and any PSR-7 middleware stack. Laravel 10 and Symfony 6 era applications are typically pinned to psr/http-message 2.x, and release 3.4.0 widened the constraint to accept ^2.0, which removes the Composer conflict workaround that used to be necessary. That change is about coexistence in a shared lockfile, not about Laravel integration, so there is still no service provider, facade, or config publishing.
- Is slim/php-view safe from XSS and path traversal?
- There is no auto-escaping, so every output site in your templates must call htmlspecialchars() with the correct flags and encoding, and that is an ongoing code-review obligation rather than a one-time setting. Templates are resolved from a configured base path and then included, so if any part of the template name is user-influenced you should validate it against an allowlist to prevent path traversal. Neither concern is addressed by the 3.4.0 release.
- Does slim/php-view work with Laravel Octane or other long-running workers?
- It can, but state leakage is the main risk. Shared attributes set through setAttributes() and addAttribute() live on the renderer instance, so a singleton renderer reused across requests under Octane or RoadRunner can bleed data from one request into the next. Bind the renderer as a scoped or transient service, or reset its attributes at the start of each request. This is the item most likely to cause problems in a Laravel-style deployment.
- How do I test views rendered with slim/php-view?
- Because render() returns a PSR-7 response, you can assert against the response body in PHPUnit using a concrete implementation such as nyholm/psr7 or slim/psr7. Point the renderer at a fixture template directory and test the rendered output and the data extraction directly. Keep in mind there is no compiled-template cache or compile-time validation, so missing templates and syntax errors only surface when the template is actually rendered, and your tests should cover those paths.
- What are the alternatives to slim/php-view for server-side rendering?
- Inside Laravel, Blade is the default and needs no bridging, while Twig via twig/twig with a Laravel bridge or Plates (league/plates) are common PHP-template alternatives. Inside Slim, Slim-Twig-View or a plates integration gives you inheritance, escaping, and caching that plain PHP templates lack. Choose slim/php-view when you specifically want zero custom syntax and native PHP includes, and keep it in a Slim or PSR-7 boundary rather than forcing it into Laravel's view layer.
- Is slim/php-view actively maintained, and is version 3.4.0 a breaking change?
- It is a small, low-velocity package with roughly 273 stars and no reported dependents, though the 3.4.0 release came from a merged external contribution, which is a modest positive signal. Version 3.4.0 is only a composer.json constraint widening to allow psr/http-message 2.0, with no API changes and no runtime code path altered, so upgrade risk is low. The residual risk is transitive: accepting psr/http-message 2.x can change what Composer resolves for neighbouring packages, so verify with a dry run and a full test suite pass.
- Why does slim/php-view still require a PSR-7 response factory from the host?
- The renderer consumes and returns a ResponseInterface, but the package does not declare a PSR-17 response factory dependency. That means your application must supply a PSR-7 and PSR-17 implementation such as nyholm/psr7 or slim/psr7, plus a way to create responses. In a Laravel context this is another reason the integration needs a bridge layer to convert PSR-7 responses back into Laravel responses.