Weave Code
Gif Exception Bundle Laravel Package
jolicode/gif-exception-bundle
Symfony bundle that turns exceptions into animated GIFs. Instead of a plain error page, it displays a random GIF alongside the exception message and stack trace, making debugging and error pages more fun. Quick to install and configure in any Symfony application.
😝 The GhostBuster of your exception page!
Frequently asked questions about Gif Exception Bundle
- Can I use jolicode/gif-exception-bundle in a Laravel application?
- No. GifExceptionBundle is a Symfony bundle, not a Laravel package: it relies on Symfony's bundle registration in config/bundles.php, a kernel.exception listener, and an override of the framework's Twig HTML exception renderer. Laravel has no bundle manifest, no tagged exception listener in the same sense, and no supported way to swap the framework error page, so the package is effectively uninstallable there. The nearest Laravel analogue is a small custom renderer built with Handler::renderable() or an Ignition solution, which is a build-not-buy decision. If your stack is Laravel, treat this as inspiration rather than a dependency.
- How do I install GifExceptionBundle in a Symfony application?
- Install it as a dev dependency with composer require --dev jolicode/gif-exception-bundle. Symfony Flex registers the bundle automatically in config/bundles.php, and in the default setup it works out of the box with no configuration required. Keep it in the dev environment only and confirm the bundle is not enabled in your production config.
- Which Symfony, PHP and Twig versions does version 1.12.0 support?
- Release 1.12.0 ships Symfony 8.2 support in the same release cycle, alongside the existing Symfony 6 and 7 lines. The test matrix uses PHPUnit 11, which suggests the PHP minimum may have moved, so check the composer.json require block for the exact PHP floor and Twig constraint before upgrading. Verify the constraint against the Symfony major and Twig version already in your fleet rather than assuming.
- Is GifExceptionBundle safe to enable in production?
- It is designed for the development environment, where it replaces the standard exception page with one containing a random GIF. Enabled outside dev it masks stack traces and replaces the framework error page, which is a high-severity exposure. Version 1.12.0 adds tests covering disabled debug mode, which improves confidence that the gating holds, but you should still verify the bundle is registered only in dev config.
- How do I use my own GIFs and organize them by HTTP status code?
- The bundle supports custom GifSets, which let you supply your own images and categories instead of the bundled defaults. You can organize GIFs by status code so a 404 shows a different reaction than a 500, and restrict which codes trigger an animation at all. The default install needs no configuration, so custom GifSets are opt-in for teams that want their own imagery.
- Why are my exception GIFs not loading in Docker or behind a CDN?
- The GIFs ship inside the bundle and are served through Symfony's public bundle asset path. That path breaks on read-only container filesystems, some CDN configurations, and hardened production-style images unless you publish the assets or serve them deliberately. If images 404 after a deploy, map or publish the bundle assets to a writable, web-accessible location.
- Does GifExceptionBundle conflict with Sentry, Whoops, or a custom exception controller?
- It can. All of these compete for the kernel.exception event, and listener priority determines which one renders the response, with last-registered winning silently. If your GIF page stopped appearing or your error tracking stopped capturing, check listener order in the debug container. There is no warning when another listener takes over, so verify behavior explicitly after adding an error-handling package.
- How do I add fun GIFs to Laravel exception pages instead?
- There is no drop-in equivalent, because Laravel's error rendering goes through the exception handler rather than a configurable bundle template. The practical approach is roughly fifty lines in your handler: match the exception or status code in renderable(), pick a random image, and return a custom view. Ignition-based solutions can also be extended for local debugging. Scope it to the local environment so production error pages stay plain and do not leak stack traces.
- What changed in v1.12.0 and what should I check when upgrading from v1.11.x?
- The main consumer-facing change is a move to the standard bundle directory structure, which relocates template and asset paths. If you overrode the bundle's Twig template, published its assets to a custom location, or hard-coded a bundle asset path in a deploy script, re-verify those after upgrading. Net-new installs are unaffected. The GIF optimizer console command was also replaced by a Castor task, which only matters if internal automation shelled out to the old command.
- Is GifExceptionBundle still maintained and safe to depend on long term?
- It remains under the same maintainer with an active pull request flow, and Symfony 8.2 support landed promptly in the 1.12.0 release. That combination lowers the upstream longevity and framework-drift risk compared with earlier assessments. Because it is a dev-only convenience, the blast radius if maintenance slows is limited to a missing GIF on your local error page, not a broken application.
Weaver
How can I help you explore Laravel packages today?