- How do I install and configure danielboendergaard/phantom-pdf in a Laravel app?
- Install it with composer require danielboendergaard/phantom-pdf, then publish the config file with php artisan vendor:publish. Set the binary_path option to the location of the PhantomJS executable on your host, and use the provided PDF facade in your controllers or services. Laravel's package auto-discovery registers the service provider and facade, so no manual wiring is usually needed. The main setup work is installing and validating the PhantomJS binary itself, not the Composer package.
- Which Laravel and PHP versions does phantom-pdf support?
- The package is a thin wrapper around jonnnnyw/php-phantomjs, so its Laravel and PHP constraints come from that dependency and from the package's composer.json. Check the composer.json and Packagist metadata for your target Laravel version before committing, because small single-maintainer packages often lag behind the latest framework releases. Do not assume Laravel 10, 11 or 12 support without verifying it, and run a proof of concept on your exact PHP version first.
- How do I generate a PDF from a Blade view with PhantomJS in Laravel?
- Use the PDF facade to load a Blade view, for example PDF::loadView('invoices.show', $data), then call save() to write a file or stream() and download() to return a response. Laravel renders the Blade template to an HTML string with its normal view engine, and that HTML is then handed to the PhantomJS binary. Because the rendering engine is roughly 2016-era WebKit, keep the template self-contained and inline your CSS rather than relying on modern layout features. Always validate the output visually for each template you ship.
- Can I render a PDF from a URL instead of an HTML string?
- Yes. The package supports both HTML strings or Blade views and remote pages referenced by URL, which PhantomJS fetches itself before rendering. That means the machine running the binary needs network access to that URL, including any internal hostnames or authentication. Treat user-supplied URLs with care, since this becomes an outbound request primitive and can expose internal services if unrestricted.
- How do I set paper size, orientation, margins, headers and footers?
- These are exposed as PhantomJS paper and page options, configured either in the published config file for defaults or per render call in the options array. You can set formats such as A4 or Letter, switch between portrait and landscape, and adjust margins. Headers and footers typically point at separate HTML templates, matching how PhantomJS itself handles them. Verify each option against the underlying php-phantomjs documentation, since not every PhantomJS setting is proxied by the wrapper.
- Does phantom-pdf work on Apple Silicon, ARM64 servers or in Docker containers?
- PhantomJS only ships legacy x86_64 builds for Linux and macOS, with no official ARM64 release, so Apple Silicon, Graviton and ARM containers need emulation or a community build. In containers you must bake the binary into the image along with font packages and the shared libraries it expects. Modern glibc versions and minimal base images can break it with no upstream fix. Validate the exact base image and CPU architecture you plan to run in production before designing around this package.
- Is PhantomJS still safe to use in production?
- PhantomJS was discontinued in 2016 and receives no security patches or engine updates. Any HTML it renders that contains untrusted content is executed by an unpatched WebKit engine, which is a genuine sandboxing and security concern. Rendering fidelity is also frozen, so CSS Grid, modern Flexbox and newer JavaScript will not behave as they do in Chrome. Restrict it to trusted internal templates on infrastructure you control, and plan an exit path.
- How does phantom-pdf perform at high volume or under tight latency budgets?
- Rendering is process-per-document: each PDF spawns a PhantomJS browser process, which costs seconds of CPU time and a meaningful chunk of memory. That makes it a poor fit for synchronous, latency-sensitive endpoints or large batch jobs. Push generation onto Laravel queues and cache or store the resulting files where you can. If throughput becomes a hard requirement, a different renderer is usually cheaper than optimizing around PhantomJS.
- How do I test PDF generation without installing PhantomJS in CI?
- Because rendering shells out to an external binary, unit tests should mock the PDF facade or your own renderer interface so they never spawn a process. Add a separate integration test that runs against a real PhantomJS binary in a dedicated CI job to catch template and binary regressions. Assert on file existence, page count and extracted text rather than byte-identical output, which is fragile across environments. Keep templated views covered by ordinary Blade snapshot tests where possible.
- What are the alternatives to phantom-pdf, and how do I migrate later?
- The common replacements are headless Chrome via Browsershot or Puppeteer, a self-hosted service such as Gotenberg, or a managed API like DocRaptor or PDFShift. To keep the swap cheap, wrap generation behind your own interface, for example a PdfRenderer contract with a render method, and bind a PhantomPdfRenderer implementation in a service provider so domain code never touches the PDF facade directly. The package's config-driven margins, header and footer options map cleanly onto Chrome print options, so migrating templates is the real work rather than the code.