Weave Code
Mail Template Bundle Laravel Package
it-blaster/mail-template-bundle
A PHP mail template bundle for managing and rendering reusable email templates. Organize layouts, substitute variables, and keep transactional messages consistent across your app. Simple to integrate and easy to extend.
Mailer + шаблонизатор писем
Frequently asked questions about Mail Template Bundle
- Is it-blaster/mail-template-bundle a Laravel package?
- No. It is a Symfony bundle and ships no service provider, facade, config stub, or publishable assets, which are the four things a Laravel integration normally expects. It assumes Symfony's DependencyInjection, Kernel, and Templating conventions rather than Laravel's container, config repository, and Mailables. Laravel's mail stack will not bind to it out of the box, so any integration is hand-wiring at best.
- Can I install it with Composer in a Laravel application?
- Installation is unlikely to resolve cleanly. The last release dates to 2016-01-26, which places it in the Symfony 2.x/3.x era, so its PHP and symfony/* constraints will very likely conflict with the symfony components Laravel already pulls in transitively. Treat Composer resolution failure as the default assumption until a time-boxed spike proves otherwise. If it does install, expect an old Symfony component set to be pinned alongside your current lock file.
- Does it support Laravel 10, 11, or 12 and PHP 8.2+?
- There is no evidence of support for any modern Laravel version or for PHP 8.2/8.3. The package predates Laravel 5.3 mailables, Blade components, and Markdown mail, and no maintenance has occurred since its 2016 release. A compatibility spike should verify PHP version support, symfony/* constraint overlap, and whether illuminate/mail and the bundle can coexist on the same autoloader before anything else is attempted. Any fork must add a PHP support matrix and a pinned dependency policy before it goes near production.
- What does this bundle add over Laravel Blade and Markdown mailables?
- Functionally very little. Laravel already gives you templated mail through Mailables, Notifications, Blade views, Blade components, and Markdown mailables, all wired into queues and transports. This bundle's value proposition is reusable centrally managed templates with variable substitution, which is what Blade views and mailables already do natively. Do the parity check first and enumerate unique features; if parity is already met, stop there.
- Is the package actively maintained?
- No. The last release was on 2016-01-26, roughly nine years ago, with two stars and zero dependents. There is no upstream maintenance and no security patching path, so any vulnerability in its template engine or dependencies would be unpatchable by you. An unmaintained dependency sitting in your mail path is a poor trade for functionality you already have.
- How would I integrate it into a Laravel app if I really had to?
- Only by hand-wiring. You would write a custom service provider that resolves the bundle's services manually, or fork the code and strip out the Symfony container coupling, then expose it through a thin Laravel provider. If you only need standalone rendering, use a manual adapter and pull your fork in through a Composer path or VCS repository rather than adopting it as your primary mail path. Never make it the main mail pipeline.
- Is the templating engine safe, and how does it handle escaping?
- Custom templating engines are a common injection vector, especially when template content is user-influenced. The bundle's escaping behaviour and variable substitution rules need explicit review before any user-facing use. Run an injection test against your fork and confirm how variables are escaped before templates are allowed anywhere near production mail.
- Is the documentation in English?
- No. The package description and upstream documentation are in Russian, which is a real onboarding cost for most teams. Budget for translation and for reading the source directly to understand configuration and template inheritance. That cost compounds when you are already patching the package to run on modern PHP.
- Can I use it as a standalone renderer outside Laravel's mail system?
- Yes, that is the only realistic use. You can vendor or fork the code, remove the Symfony container coupling, and call it as a plain renderer that returns HTML, then hand the result to Laravel's mailer yourself. Keep it out of the mailable and queue pipeline so a failure in an abandoned dependency cannot take down transactional mail.
- Should I adopt it or reimplement the templating in Laravel?
- The default recommendation is to drop it or reimplement natively. Given zero dependents and a nine-year-old codebase, the decision gate is adopt-fork, reimplement with Blade, or drop. Unless the spike reveals genuinely unique behaviour that Blade and Markdown mailables cannot express, port the templating logic to Blade and delete the dependency.
Weaver
How can I help you explore Laravel packages today?