UX SweetAlert
GitHub
Browse documentation

Alerts

Alerts are the blocking SweetAlert2 modals created through AlertManagerInterface. They are queued server-side, stored in the bundle session storage key, then consumed by the frontend controller.

Built-in helper methods

The alert manager exposes one helper per icon:

  • success()
  • error()
  • warning()
  • info()
  • question()

Each helper returns the created Alert instance so you can continue to customize it fluently.

  $alert = $alertManager->warning(
    title: 'Danger zone',
    text: 'This action cannot be undone.'
);

$alert
    ->withCancelButton()
    ->withDenyButton()
    ->denyOutsideClick()
    ->denyEscapeKey();

Common customization methods

Method What it changes
withCancelButton() Displays the cancel action.
withDenyButton() Displays a secondary deny action.
withoutConfirmButton() Hides the default confirm button.
withoutAnimation() Disables SweetAlert animation.
withoutBackdrop() Removes the modal backdrop.
theme(Theme $theme) Sets the SweetAlert2 theme name.
position(Position $position) Changes where the modal is rendered.
confirmButtonColor(...) Overrides the confirm button color.
cancelButtonColor(...) Overrides the cancel button color.
denyButtonColor(...) Overrides the deny button color.
reverseButtons() Swaps the button order.

Creating a custom Alert instance

If you need direct control, build the object yourself and hand it to the manager:

  use Pentiminax\UX\SweetAlert\Enum\Icon;
use Pentiminax\UX\SweetAlert\Enum\Position;
use Pentiminax\UX\SweetAlert\Model\Alert;

$alert = Alert::new(
    title: 'Custom alert',
    text: 'Created manually.',
    icon: Icon::INFO,
    position: Position::TOP
)
    ->html('<strong>Rich content</strong>')
    ->setFooter('Need help? Contact support.');

$alertManager->addAlert($alert);

Multi-step wizards

steps() queues several alerts as one wizard. Each step shows SweetAlert2 progress steps (labelled 1..n unless the alert already sets its own with progressSteps()) with its own step highlighted.

  use Pentiminax\UX\SweetAlert\Model\Alert;

$alertManager->steps(
    Alert::new(title: 'Welcome')->withCancelButton(),
    Alert::new(title: 'Your profile')->withCancelButton(),
    Alert::new(title: 'All set!'),
);
  • The steps fire in order on every transport (Twig, HX-Trigger, JSON, Turbo streams).
  • Cancelling or dismissing a step (cancel button, Esc, backdrop click, close button, timer) stops the wizard: the remaining steps never open and send no callback or closed event.
  • A deny answer (withDenyButton()) is a real answer and moves on to the next step.
  • Each step’s Result goes to its own callback and ux-sweet-alert:<id>:closed event; there is no aggregated result for the whole wizard.

Alerts queued with addAlert() keep their old behavior: they all show, one after another, whatever the user answers.

Method What it changes
progressSteps(array $labels) Labels of the progress steps shown above the title.
currentProgressStep(int $index) Zero-based index of the highlighted step.

Server-side defaults still apply

Alerts built through AlertManagerInterface are created with Alert::withDefaults(...), so the bundle configuration can predefine button labels, colors, positioning, timers, and interaction rules.