- Can I use eschmar/css-inliner-bundle in a Laravel application?
- No, not directly. This is a Symfony bundle that registers a Twig token parser, so it ships no Laravel ServiceProvider, no config file to publish, and nothing Laravel can auto-discover. The {% cssinline %} tag it adds does not exist in Blade and cannot be registered there. If you want this behavior in Laravel, use the underlying tijsverkoyen/css-to-inline-styles library instead of the bundle.
- What does eschmar/css-inliner-bundle actually do?
- It adds a single Twig tag, {% cssinline %}...{% endcssinline %}, and wraps tijsverkoyen/css-to-inline-styles. Anything inside the tag is parsed, style blocks are converted into inline style attributes on the matching elements, and the original style tags are stripped out. The output is plain HTML suitable for email templates. There is no configuration, no facade, and no other feature surface.
- Is CssToInlineStyles already installed in my Laravel app?
- Very likely yes. laravel/framework pulls tijsverkoyen/css-to-inline-styles in transitively because Illuminate\Mail\Markdown depends on it. Check your composer.lock for the package before adding anything new. In many applications the inlining capability you want is already present with zero additional dependencies, which makes this bundle redundant for Laravel projects.
- How do I inline CSS in Laravel Blade email templates?
- Register a Blade directive such as @cssinline ... @endcssinline, or an inline_css() helper, backed by a CssToInlineStyles instance. Render the Mailable view to an HTML string, pass it through the inliner, and set the result as the message body. Wrapping that behind a small CssInliner contract keeps the engine swappable. This is roughly one to two engineering days of work including tests.
- Which Laravel and PHP versions does this package support?
- None officially, because it targets Symfony rather than Laravel. The 1.x line targets Symfony 4.1, 2.x targets Symfony 5.0, and 0.2.x targets Symfony 3.4; all of those Symfony lines are past or nearing end of life. PHP 8.2 and 8.3 compatibility of the bundle layer is unverified. The underlying CssToInlineStyles library is the part with modern PHP support.
- Is eschmar/css-inliner-bundle actively maintained?
- No. The last release was 2020-03-20, the repository has around 6 stars and zero dependents, and there is effectively no community signal around it. With no downstream users there is no canary for breaking changes and little reason to expect upstream responses to issues or CVEs. Treat the wrapper as disposable and the MIT-licensed inlining engine as the durable component.
- What are the alternatives to this bundle for inlining CSS in Laravel emails?
- Laravel's built-in Markdown mail already inlines CSS and covers many transactional email needs. Otherwise, use tijsverkoyen/css-to-inline-styles directly behind a Blade directive or helper, which removes the Twig dependency entirely. Hosted inlining APIs and premailer-style services exist but add an external dependency. For simple templates, hand-written inline styles are still an option.
- Does it support media queries, CSS custom properties, or external stylesheets?
- No, and those limitations belong to the underlying engine rather than the bundle. Media queries are not preserved for email clients, CSS custom properties are handled imperfectly, specificity resolution has edge cases, and external stylesheets are not fetched. Expect these to surface as rendering bugs in Gmail, Outlook, and Apple Mail. Test representative templates before committing to the approach.
- How should I test inlined email output in Laravel?
- Use golden-file tests against template fixtures: render the Blade view, run it through the inliner, and assert the resulting HTML matches a stored expectation. Diff rendered output across Gmail, Outlook, and Apple Mail for a representative template during a short spike. Also assert that no style blocks remain and that expected style attributes are present. This catches regressions when the engine or your templates change.
- What are the production risks of depending on this Symfony bundle?
- The wrapper is unmaintained, so you should assume you own any fork and any security response yourself. The security surface is small because templates are developer-authored rather than user input, but malformed markup can still produce unexpected DOM parsing behavior. The engine itself is mature and separable, so the main risk is carrying dead bundle code. Do not add it to composer.json in a Laravel project.