- What is qferr/mjml-php used for?
- qferr/mjml-php compiles MJML markup into responsive HTML emails from PHP, so you can build transactional templates with reusable components instead of hand-written table layouts. It is a thin rendering wrapper, not a replacement for Laravel Mailables, transports, or template management. Typical use is a build step or queued renderer that feeds compiled HTML into your existing Laravel mail flow.
- How do I install qferr/mjml-php with Composer?
- Install it with Composer using composer require qferr/mjml-php, then confirm the package constraints match your PHP version. You also need a working MJML runtime and a configured path to the MJML binary because the PHP package does not bundle a Node runtime. Before production, verify the canonical repository, license, and release history because the supplied metadata is incomplete.
- Does qferr/mjml-php require Node.js or an MJML binary?
- Yes, qferr/mjml-php is a PHP wrapper around MJML, which is Node-based, so production needs access to a compatible MJML executable or local binary. The package exposes configurable MJML binary path and execution options, but you must confirm the exact invocation and packaging for your environment. Test in the same container image you deploy, not on a developer workstation.
- How do I integrate qferr/mjml-php with Laravel?
- Bind the renderer behind your own internal MjmlRenderer interface, configure the binary path and execution options in Laravel config, and wrap package exceptions with application-level errors. Expose a narrow API to Mailables or a template compiler rather than calling the package directly from controllers. Prefer compiling templates during deploy or in a queued job, then pass the resulting HTML into Laravel Mail.
- Which Laravel and PHP versions does qferr/mjml-php support?
- The package is not a native Laravel mail package, so Laravel support depends on your integration and on Composer constraints. The last release noted is from 2022, so verify PHP 8.2, 8.3, and 8.4 plus Laravel 10, 11, and 12 in a production-like container before adopting it. Pin both the PHP package and MJML/Node versions to avoid drift.
- Can I render MJML at runtime on every mail send?
- It is technically possible, but runtime rendering adds subprocess overhead, latency, and failure modes to your mail path. For high-volume or latency-sensitive applications, compile MJML in CI or at deploy time and cache the generated HTML. If runtime rendering is unavoidable, queue it, set timeouts, log failures, and keep an HTML fallback.
- How should I test MJML rendering before production?
- Run a compatibility spike in the same container image used in production with pinned PHP, Node, and MJML versions. Start with one low-risk transactional template, compile it through qferr/mjml-php, and compare the HTML and client rendering against your current template. Also test invalid MJML exceptions, subprocess timeouts, missing binary behavior, and fallback paths.
- Is qferr/mjml-php actively maintained and safe to depend on?
- Maintenance signals are weak in the supplied context: 71 stars, a last release in April 2022, low opportunity score, and unknown repository metadata. Treat it as a pinned dependency with an internal owner and a fork or patch plan rather than assuming upstream will track PHP, Laravel, or MJML releases. Review license, issue activity, and maintainer responsiveness before production use.
- Is it safe to pass user or tenant input into the MJML renderer?
- No, treat MJML templates as trusted build artifacts and do not let untrusted user or tenant input reach the renderer or subprocess. If dynamic content is required, validate and sanitize it, allowlist supported components, and keep the binary execution environment restricted. This reduces injection, resource abuse, and unexpected template behavior risk.
- What alternatives or migration path should I use instead of runtime qferr/mjml-php?
- A safer alternative is to run the MJML CLI in CI or a deploy pipeline, store versioned HTML, and let Laravel Mailables consume that HTML without a Node dependency at request time. Migrate one template at a time, compare deliverability and client compatibility, and keep an HTML fallback until parity is proven. If you must use the package, wrap it behind your own interface and be ready to fork or replace it.