- How do I install goldnead/statamic-notifications in a Statamic site?
- Install it with Composer using composer require goldnead/statamic-notifications, then publish the addon configuration so the defaults and recipient settings land in your config directory. If you plan to use deferred delivery, run the migration that creates the notification_deliveries table and schedule the notifications:dispatch-pending command. The addon is designed to feel native to Statamic, so most defaults work without touching a service provider.
- Does this addon work with Laravel's built-in notification system?
- Yes, it integrates directly with Laravel notifications rather than replacing them. Notifications are standard Laravel notification classes, and the addon publishes sensible defaults you can extend in your own service providers. That means existing mail and other Laravel channels keep working, and custom notification logic can be added without modifying the package.
- Which Laravel, PHP, and Statamic versions are supported, and is statamic-brand-context required?
- Support targets current Laravel and Statamic releases, so check the composer.json constraints in the repository before upgrading a legacy app. The statamic-brand-context dependency only matters for Control Panel navigation placement: version 1.16 or higher is needed if you want the addon settings to appear beneath its own navigation entry. Older versions of statamic-brand-context ignore the new settingsNavParent hook and fall back to the previous layout, so the dependency behaves in a fail-soft way rather than breaking.
- How does deferred notification delivery work in this package?
- Deferred delivery follows an outbox-style pattern: the notification and its per-channel notification_deliveries rows are written atomically in one transaction, then dispatched later by a host-run notifications:dispatch-pending command with retry and exponential backoff. Only channels that implement the DeferredChannel contract take part, with in-app and mail supported out of the box. The command fits Laravel's scheduler conventions, so the host application is responsible for running it reliably.
- Do I need extra database tables to use the notifications addon?
- The core addon requires no additional database tables, which is why it can be adopted in an existing Statamic control panel with minimal setup. Deferred delivery is the exception: it adds a notification_deliveries migration that should be additive, so it is generally safe for a rolling deploy, though you should still verify it against your zero-downtime process. If you never enable deferred channels, you do not need that table.
- How do I make a custom notification channel support deferred delivery?
- Implement the DeferredChannel contract on your channel class so the dispatcher knows it can be queued through the outbox rather than sent inline. You will also need to provide and validate a DeferredRecipientResolver so recipients can be resolved at send time. Be aware that mixing deferred and non-deferred channels in a single notification requires an explicit policy decision, because the two paths behave differently.
- Can recipients be changed or cancelled after a deferred notification is queued?
- Recipients are resolved at send time rather than at write time, which keeps delivery fresh if roles or addresses change between queueing and dispatch. The trade-off is that a recipient may resolve differently than expected, or may no longer resolve at all, if the underlying data changed in the meantime. Cancellation semantics after the delivery row is written should be verified in your installed version before relying on them.
- Will retries cause duplicate notifications for recipients?
- Retries use backoff to reduce repeated failures, but idempotency is enforced at the channel boundary, not necessarily by the package itself. If a channel is not idempotent, a retry after a partially successful send can result in a duplicate reaching the recipient. Confirm your mail and custom channel behavior, and make sure the outcome states such as accepted, skipped, retry, cancelled, and failed are logged for troubleshooting.
- Why did the addon settings move under a different Control Panel navigation entry after upgrading to 1.12.0?
- Version 1.12.0 declares settingsNavParent so the settings appear beneath the addon's own Control Panel navigation entry when statamic-brand-context 1.16 or higher is installed. Addons without their own navigation entry share a single Addon-Suite page under Settings, which can look like a misconfiguration but is the intended fallback. If environments run different statamic-brand-context versions, expect the placement to differ until they are aligned; there is no migration or new config key in this release.
- How should I run and monitor the notifications:dispatch-pending command in production?
- Schedule the command through Laravel's scheduler and treat a reliable cron or worker setup as a prerequisite for deferred delivery, since nothing is sent without it. Watch for backlog growth in the deliveries table and alert on repeated command failures, because row claiming under a lock supports multi-node dispatch but stale-claim recovery, batch size, and lock timeout should be validated for your traffic. Exposing the per-delivery outcomes to logs or metrics makes support investigations much faster.