Weave Code
Flasher Symfony Laravel Package
php-flasher/flasher-symfony
Symfony integration for PHPFlasher that lets you show flash messages and toast notifications through a simple, framework-native API. Publish notifications from controllers or services and render them in your Twig templates with minimal setup.
PHPFlasher - A powerful & easy-to-use package for adding flash messages to Laravel or Symfony projects. Provides feedback to users, improves engagement & enhances user experience. Intuitive design for beginners & experienced developers. A reliable, flexible solution.
Frequently asked questions about Flasher Symfony
- Is php-flasher/flasher-symfony a Laravel package I can install in my Laravel app?
- No. This package is a thin Symfony bundle that wires the php-flasher/flasher core into Symfony's service container, Twig runtime, and session-based notification storage. It is not a Laravel package and pulling it into a Laravel service is an architectural mismatch. For Laravel, use php-flasher/flasher-laravel, which provides the service provider, Blade directives, and Laravel session integration. The realistic use case for this bundle is a hybrid estate where you want one notification vocabulary across Symfony and Laravel services.
- How do I install and register php-flasher/flasher-symfony?
- Run composer require php-flasher/flasher-symfony. With Symfony Flex the bundle is registered automatically in config/bundles.php; otherwise add it to the bundles array manually. Then configure the adapter you want (Toastr, Notyf, SweetAlert, PNotify, and others) and confirm the transitive php-flasher/flasher core constraint resolves against your pinned Symfony versions. Installation effort is low; the real work is asset delivery and session behavior.
- Which Symfony and PHP versions does this bundle support?
- It targets Symfony 5.4 through 7.x with Twig and assumes a PHP 8.x floor. Because this repository is a read-only subtree split, the actual version you require resolves from upstream Packagist releases, so check that split tags track upstream tags before pinning. Also verify the DI extension and Twig extension against your Symfony minor and patch pins to catch deprecations early.
- How do I show a flash message from a Symfony controller or service?
- Use the Flasher trait in your controller or inject the flasher service, then call the success, error, info, or warning methods with your message. Notifications are queued in the session and rendered on the next page load, which matches Symfony's native flash behavior. A good migration pattern is to wrap your existing addFlash calls and inline SweetAlert2 code behind a single application-level notifier interface, implement that interface with Flasher in one service, and leave existing call sites untouched.
- How do I render PHPFlasher notifications in my Twig templates?
- Add the bundle's Twig helper, typically flasher_render(), to your base layout so queued notifications are output on the next request. Replace your bespoke toast JavaScript includes with that single call, then retire the legacy markup once visual parity is confirmed. Keeping the render call in one base template makes the vendor choice reversible if you later swap the implementation behind your notifier interface.
- Does this work for a stateless JSON API or a decoupled SPA?
- Not without an extra bridge. Notifications are stored in the session and rendered on the next full page load, so the model does not translate to stateless API responses or SPA clients that only consume JSON. If your consuming surfaces are SPA or API-first, session flash is the wrong transport and you should return notification payloads in your API contract instead. This bundle is aimed at server-rendered Twig pages.
- Why are my toast notifications missing or inconsistent across servers?
- The session dependency is the usual culprit. In a multi-node deployment without shared session storage, the request that queues the notification and the request that renders it can land on different nodes, making notifications nondeterministic. Configure a shared session backend such as Redis or a database session handler before rolling this out beyond a single server.
- Can I self-host the JavaScript and CSS assets instead of relying on a CDN?
- The value of this bundle depends on third-party JavaScript toast libraries, which can be delivered via CDN or through your own asset pipeline. If you have a strict Content Security Policy, air-gapped environments, or no-CDN requirements, publish and serve those assets yourself and verify the adapter config supports that cleanly. Treat the front-end assets as a supply-chain and CSP surface you own, and document the pinned versions.
- The repository says READ-ONLY — is this project still maintained?
- READ-ONLY here means the repository is a subtree split of the php-flasher monorepo, not that development stopped. Issues, pull requests, and releases originate upstream, so all diligence should target the monorepo's health rather than this distribution surface. Be aware that star counts on a split repo understate real usage and that this is effectively a small-maintainer dependency in a user-visible UX path. The MIT license limits lock-in because you can fork, but it does not guarantee ongoing security or deprecation response.
- How do I test that notifications are queued correctly in Symfony?
- Use Symfony's WebTestCase or KernelTestCase to exercise the action that triggers a notification, then assert against the session flash bag or the flasher storage rather than the rendered JavaScript. Asserting on server-side state keeps tests fast and independent of the front-end toast library. Add one functional test that confirms the Twig helper is rendered in your base layout, so a broken include fails CI.
Weaver
How can I help you explore Laravel packages today?