- How do I install brian2694/laravel-toastr in a Laravel app?
- Install it with Composer using composer require brian2694/laravel-toastr. The service provider is auto-discovered, so no manual registration is needed in modern Laravel versions. Then publish the config and the Blade view with the package's vendor:publish tags, and include the toast partial in your main layout. Because the package relies on session flash data, make sure your layout renders the partial on the page you redirect to after an action.
- Which Laravel and PHP versions does laravel-toastr support?
- The package is a thin wrapper around Laravel's session flash and Blade APIs, but the declared support window is what matters. Check the require block in the package's composer.json for the exact illuminate/support and php constraints, and confirm the latest Laravel major is covered before adopting. Release date alone is a poor signal, since Laravel's session, Blade, and auto-discovery APIs have churned across majors. If your target version is not declared, test it on a branch rather than assuming compatibility.
- How do I show a toastr notification from a controller before redirecting?
- Call the Toastr facade, or the toastr() helper, before returning your redirect, for example flashing a success message and then redirecting back. The package writes the payload into the session as flash data, and the Blade partial reads it on the next full page render and emits the matching toastr.*() JavaScript calls. The toast therefore appears after the redirect completes, not on the current response. Typical use cases are form submissions, CRUD actions, and auth events in a server-rendered Blade app.
- Does laravel-toastr require jQuery?
- Yes, indirectly: the underlying toastr.js library depends on jQuery, and the package's default assets are delivered with toastr.js. That is a real constraint if your front end has standardized on Alpine, Vue, React, or vanilla ES modules. If jQuery is already present in your layouts, adding this package is close to free. If it is not, weigh whether introducing jQuery for toasts is worth it, or use a dependency-free toast library instead.
- How do I publish and customize the laravel-toastr config and Blade view?
- Use the package's publish command to copy the config file and the Blade partial into your application, then edit them. The config typically controls the session key, the view namespace, and the CDN or asset paths used for toastr.js and its CSS. Publishing the view lets you override markup and behavior without forking the package. Keep your published copy under version control so upgrades do not silently overwrite your changes.
- Is laravel-toastr safe from XSS when flash messages contain user input?
- That depends entirely on how the published Blade view emits the messages, so read the view rather than the README. The package's core job is injecting session data into JavaScript, which means any interpolation of user-controlled input (names, search terms, validation text) must be JSON-encoded and context-escaped. If the view emits raw output with unescaped braces or string concatenation into a script block, you have a stored-XSS vector on every page that renders the partial. Audit and harden that view during integration, and prefer json_encode with the appropriate flags.
- Can I self-host the toastr.js assets instead of loading them from a CDN?
- The default asset delivery is CDN-oriented, but the config exposes asset paths, so you can point it at locally hosted copies of toastr.js and its CSS. Self-hosting is the safer posture under a strict Content-Security-Policy, since it avoids a third-party script-src exception. Pair local hosting with Subresource Integrity hashes where applicable and pin the toastr.js version. Verify the config keys for asset swapping in the published config file before relying on them.
- Does laravel-toastr work with Livewire, Inertia, or AJAX requests without a page reload?
- Generally no, because the package uses a session-flash plus full-page-render pattern: the toast only fires when the Blade partial is re-evaluated in a fresh HTML response. Livewire component re-renders, Inertia visits, and JSON API responses do not reload the document, so flash data may never surface as a toast. For those stacks, use a shared flash prop in Inertia, a browser event dispatched from the component, or a small in-house Blade component wrapping a modern toast library. This package is the wrong primitive for stateless or SPA-style surfaces.
- How do I test that toast messages are flashed in Laravel feature tests?
- Because the package writes notifications into the session as flash data, assert on the session after the request rather than trying to inspect JavaScript. A feature test can post to a controller and then assertSessionHas the configured session key with the expected payload. That keeps your tests fast and independent of the front-end assets. If you publish the view, add a render test that confirms the partial outputs correctly escaped JSON for a message containing quotes or angle brackets.
- Is brian2694/laravel-toastr actively maintained, and what are the alternatives?
- The project has a small community and a single-maintainer release history, which is a modest but real bus-factor risk for a package this small. Mitigation is straightforward: it is a thin wrapper with low lock-in, so you can pin a tagged release, fork it, or vendor the code if maintenance stalls. Check issue and pull request responsiveness plus the tagged release cadence before committing. Alternatives include wiring toastr.js into your layout yourself, or using a dependency-free toast library behind a small in-house Blade component if you want to drop jQuery.