- How do I install realrashid/sweet-alert in a Laravel app?
- Install it with composer require realrashid/sweet-alert, then optionally publish the config and front-end assets with php artisan vendor:publish. Add the @sweetAlert Blade directive to your main layout so the SweetAlert2 script is rendered on every page. In v8 that directive replaces the older @include('sweetalert::alert') call.
- Which Laravel and PHP versions does realrashid/sweet-alert support?
- Version 8 targets Laravel 11, 12 and 13 and requires PHP 8.3 or newer because it uses PHP 8.3 enums internally. If any of your apps are still on Laravel 10 or PHP 8.1/8.2, v8 is unavailable and you must stay on the v7 line. Check your fleet's PHP and Laravel versions before standardising on v8.
- How do I flash a success message after a redirect with the Alert facade?
- Call Alert::success('Saved', 'Record updated')->flash() in your controller before returning the redirect. The payload is stored in the session and rendered automatically on the next page load. The error(), info() and warning() helpers follow the same pattern. Using flash() makes the alert one-time, while a non-flashed alert stays in the session until it is displayed or flushed.
- How do I create a SweetAlert delete confirmation with CSRF protection in Laravel?
- Use Alert::confirmDelete() or add a data-confirm-delete attribute to your delete button. The package builds a form containing the CSRF token and the correct HTTP verb, so the confirmation actually submits a DELETE request instead of silently degrading to GET. The submitTo() method lets you post the dialog answer back to a specific route when you need extra handling.
- What is the difference between a toast and a modal alert in sweet-alert?
- Calling toast() returns a ToastBuilder that renders a small, timed notification in a corner of the screen, which suits background feedback that should not interrupt the user. The success, error, info and warning helpers render modal dialogs that block the page until dismissed, which suits outcomes the user must acknowledge. Both are session-backed, so the controller code pattern is the same.
- Do I need a CDN to load the SweetAlert2 assets?
- No. SweetAlert2 ships bundled with the package and you can publish the assets with vendor:publish. A CDN path is available, but it introduces a third-party runtime dependency and a Content-Security-Policy question. If you keep a strict CSP, standardise on the published local asset to remove that external failure domain.
- Does realrashid/sweet-alert work with Livewire components?
- Yes. Alerts are stored in the session and rendered on the next page load, so you can call Alert::success() or toast() from a Livewire component action exactly as you would from a controller. For dialogs that must appear without a full page reload, dispatch a browser event after the component re-renders. The package also works with standard Blade views and redirects.
- How do I customize the theme, position, timer and button text?
- Publish the config file with vendor:publish and set your defaults there, including theme, position, timer, button labels and animation options. Fluent builders let you override values per call, for example ->toast()->position('top-end')->timer(3000). Keeping shared defaults in config avoids repeating the same options in every controller.
- How do I test that an alert was flashed in PHPUnit?
- Because alerts are session-backed, the simplest check is to call the controller action and assert that the configured alert session key is present on the redirect response. Then follow with a request to the target page and assertSee the alert title to confirm the Blade directive renders it. Keep these as feature tests, since the session and view middleware are involved.
- Is realrashid/sweet-alert actively maintained, and what are the alternatives?
- The package has a single maintainer and historically ships a release for each new Laravel major, so confirm the version you need exists before upgrading your framework. Alternatives include calling SweetAlert2 directly from your Blade templates, using a generic flash-message package, or wrapping this package behind your own Notifier interface. Given its small surface area, wrapping it is a cheap way to stay portable if maintenance ever stalls.