Weave Code
Php Weasyprint Laravel Package
pontedilana/php-weasyprint
PhpWeasyPrint is a PHP wrapper for WeasyPrint that generates PDFs from URLs or HTML. Inspired by Snappy and built as a drop-in replacement, it offers a strictly typed GeneratorInterface and requires PHP 8.3+ plus WeasyPrint 60 or greater.
PHP library allowing PDF generation or snapshot from an URL or an HTML page. Wrapper for Kozea/WeasyPrint
Frequently asked questions about Php Weasyprint
- How do I install php-weasyprint in a Laravel application?
- Run composer require pontedilana/php-weasyprint and make sure a WeasyPrint 60+ binary is available on the host. The package is framework-agnostic and ships no service provider or facade, so in Laravel you bind the Pdf class inside your own small service provider and inject it as a PdfRenderer-style interface. Symfony Process, which the package uses to shell out, is already present transitively in Laravel 10 and 11.
- What are the requirements for running PhpWeasyPrint?
- You need PHP 8.3, 8.4 or 8.5 and WeasyPrint version 60 or greater installed on the machine. WeasyPrint itself needs Python 3.9+ plus the native Pango, cairo, gdk-pixbuf and harfbuzz libraries and a populated font set. That runtime stack has to exist in every environment, including local dev, CI, staging and production containers.
- Which Laravel versions support pontedilana/php-weasyprint?
- Because the package requires PHP 8.3+, it effectively floors you at Laravel 10.48 or newer, or Laravel 11 and above. There is no Laravel-specific code in the package, so any framework version running PHP 8.3 or higher works. The practical constraint is not Laravel itself but the Python and Pango runtime you must keep in your base images.
- Is PhpWeasyPrint a drop-in replacement for KnpLabs/snappy?
- The GeneratorInterface mirrors Snappy's method contract, using the same method names and behaviour, so existing call sites look almost identical. The differences are that this library lives in its own namespace and is strictly typed, accepting string-only input and declaring return types. In practice you swap the use statements and constructor, then let static analysis flag any type mismatches.
- Does WeasyPrint execute JavaScript when rendering a page?
- No. WeasyPrint implements CSS Paged Media but runs no JavaScript, so client-side charting, JS-driven layout and fonts injected at runtime will not appear in the PDF. This is the most common cause of designs that looked perfect in the browser but break in the document. Pre-render charts server-side as inline SVG or generate static markup before handing HTML to the generator.
- How do I pass WeasyPrint options such as stylesheets or media type?
- Call setOption with the CLI option name, for example media-type set to screen, encoding set to utf8, or stylesheet and attachment passed as arrays of paths. Options whose values are a fixed set also accept a backed enum, which is converted to its scalar value automatically. Be aware these are stringly-typed passthroughs to the binary and nothing validates that the installed WeasyPrint supports a given flag, so pin the WeasyPrint version in your image and assert it at boot with the version flag.
- Is generateFromUrl safe to use in production, or does it create SSRF risks?
- Fetching URLs means the server makes outbound requests, which is an SSRF and local-file-disclosure surface if user input reaches it. Recent releases restrict output paths and URL schemes by default, and you should not widen those allow-lists. If HTML-string rendering covers your use case, disable URL generation entirely rather than exposing it through your own endpoints.
- Should I generate PDFs inside the request or dispatch a queued job?
- Generation runs as a synchronous CLI process, so heavy documents can blow past request time limits. Call setTimeout to bound the process and dispatch a queued job that writes the file and returns the path to the user. Keep controllers away from the Pdf class, calling your own service or job so the rendering backend stays swappable.
- How can I test PDF generation without installing WeasyPrint in CI?
- Depend on the GeneratorInterface rather than the concrete Pdf class, then bind a fake in your test container that returns fixture bytes. That keeps your unit and feature tests fast and free of the Python, Pango and font stack. Keep one small integration test that runs the real binary in a dedicated CI job so version drift and option changes still surface.
- How does PhpWeasyPrint compare to dompdf, Snappy or Browsershot, and is it maintained?
- Dompdf is pure PHP and simpler to deploy but weaker on modern CSS, Snappy needs wkhtmltopdf, and Browsershot drives headless Chrome for full JavaScript support at a much heavier cost. PhpWeasyPrint sits in between with correct CSS Paged Media output and good PDF/A-style features, but has a small community of roughly 80 stars and no dependents. The wrapper is a thin few-hundred-line layer over a healthy upstream project, so pinning versions and accepting that you can fork it if the maintainer stops is a reasonable stance.
Weaver
How can I help you explore Laravel packages today?