- Can I install mkebza/wk-pdf-bundle in a Laravel app with Composer?
- Not in any useful way. The package is a Symfony bundle whose integration point is Kernel::registerBundles plus a services.yaml and Configuration tree, none of which exist in Laravel. Composer may resolve it, but nothing will wire up a service provider, config, or facade for you. Treat the repository as a reference implementation of a thin wkhtmltopdf wrapper and either fork it behind your own PdfRenderer contract or reimplement the invocation logic in app/Support.
- Which Laravel versions does this package support?
- None are declared, because it targets Symfony rather than Laravel. The bundle's Symfony constraints put it in the Symfony 4/5 era, which typically means PHP 7.4 through 8.1, so verify before assuming it runs on PHP 8.3. Since you would be adapting or reimplementing the wrapper anyway, Laravel version compatibility becomes your code's responsibility, not the package's.
- How do I render a Blade view to PDF with wkhtmltopdf in Laravel?
- The bundle does not render Blade templates, so you would call view('invoices.show', $data)->render() yourself and pass the resulting HTML string to the wkhtmltopdf binary via stdin or a temp file. Then wrap the process in your own service bound through a PdfServiceProvider so controllers depend on an interface rather than the binary. Keep the HTML self-contained and prefer absolute asset URLs, because wkhtmltopdf resolves relative paths from the working directory, not your Laravel public folder.
- How do I set page size, orientation, and margins for wkhtmltopdf?
- In the Symfony bundle these come from the Configuration tree exposed through services.yaml, which has no Laravel equivalent. In a Laravel port you would translate them into CLI flags such as --page-size A4, --orientation Landscape, --margin-top 10mm, and --margin-bottom 10mm. Store the defaults in config/pdf.php and allow-list the options a caller may override rather than letting arbitrary flags flow into the command line.
- Why do developers say wkhtmltopdf is a risky choice for PDF generation?
- It is built on Qt WebKit, which has been effectively abandoned upstream and has seen minimal maintenance for years. Modern CSS such as flexbox and grid gaps, web fonts, and JavaScript-heavy templates render inconsistently or not at all. Choosing this engine is a multi-year commitment to a legacy renderer, so only accept it when output parity with existing wkhtmltopdf documents is a hard requirement.
- Is shelling out to wkhtmltopdf a command injection risk?
- Yes, if any part of the command string is built from user input. Any wrapper that concatenates arguments is a candidate for injection in a multi-tenant application, and this bundle gives you no guarantees you can audit quickly. Escape every argument with escapeshellarg, allow-list options, pass HTML via stdin or a temp file rather than the command line, and ideally run the binary in an isolated container with no network access.
- What are the best alternatives to wkhtmltopdf for Laravel PDF generation?
- For simple, static documents like invoices, labels, and tickets, Dompdf via barryvdh/laravel-dompdf is usually enough and installs as a pure PHP dependency. For branded, CSS-heavy reports, use a real browser engine through spatie/browsershot or a managed rendering API, or a self-hosted Gotenberg container. Note that barryvdh/laravel-snappy is only a Laravel wrapper around wkhtmltopdf, so it inherits the same engine risk.
- How do I stop PDF generation from timing out my HTTP requests?
- Render in a queued job rather than in the request cycle, because launching a headless renderer per request will wreck response times under load. Generate the PDF to storage, then notify the user or expose a signed download route when the job completes. The Symfony bundle provides no queue integration, so this orchestration is entirely yours to build in the Laravel port.
- What has to be installed on the server or Docker image to run wkhtmltopdf?
- The wkhtmltopdf binary must exist on every host and container, together with the correct Qt WebKit shared libraries and fonts, and it must be executable by the PHP process. Use a patched-Qt build for headless environments, and pin the exact version in your image so an OS base-image upgrade cannot silently swap it. This runtime dependency, not the wrapper code, is the main operational cost of adopting this approach.
- Is mkebza/wk-pdf-bundle actively maintained?
- There is little evidence of it. The repository has roughly zero stars and dependents, a single author, and a last release in September 2023, with no visible issue triage, security review, or CVE watch. The bus factor is one, so if you fork the wrapper you also own patching it and need an internal SLA for when the binary breaks. That ownership question is worth answering before the package becomes load-bearing in production.