goldnead/statamic-notifications
A Statamic addon that brings a flexible notification system to your control panel, making it easy to send, manage, and display notifications for users and editors without custom code.
v1.12.0 scope: This release is a Control Panel presentation change, not a delivery-pipeline change. The addon now declares settingsNavParent() so its settings appear as "Einstellungen" beneath its own Control Panel navigation entry when statamic-brand-context 1.16+ is installed; addons without their own navigation share a single "Addon-Suite" page under Settings. There is no migration and no new config key. The v1.11.0 deferred-delivery assessment therefore remains substantively valid — the architectural picture is unchanged.
Architecture fit: Good for Laravel/Statamic services already using the package's notification abstraction. The deferred path remains close to a transactional outbox: notification and per-channel notification_deliveries rows are written atomically, then dispatched by a host-run notifications:dispatch-pending command with retry/backoff. Only channels implementing DeferredChannel participate; in-app and mail are supported. Recipient resolution at send time preserves freshness but changes delivery semantics and introduces stale-or-missing-recipient risk. v1.12.0 adds a second, softer integration surface: admin navigation, which is now coupled to the statamic-brand-context version.
Integration feasibility: Still moderate-to-low for a standard Laravel/Statamic app. Expected steps are composer update, run the notification_deliveries migration, publish/configure notifications.deferred.max_attempts and backoff_seconds, implement DeferredChannel for custom channels, provide/validate DeferredRecipientResolver, and schedule php artisan notifications:dispatch-pending. v1.12.0 adds no steps — only an upgrade of statamic-brand-context to 1.16+ if the new settings placement is wanted. Older versions ignore settingsNavParent() and retain the previous layout, so the change is fail-soft rather than breaking.
Technical risk: Medium, unchanged in substance. Transactional writes reduce loss risk, but delivery depends on an external command running reliably. Retry and exponential backoff are positive; idempotency at the channel boundary must be confirmed. Row claiming under lock supports multi-node dispatch, but stale-claim recovery, batch limits, and concurrent-command safety need verification. Deferred recipient resolution can fail or resolve differently than at write time. Mixed-channel notifications need an explicit policy when only some channels are deferred-capable. The v1.12.0 risk is low and cosmetic: inconsistent settings placement across environments if statamic-brand-context versions differ, and possible reviewer confusion if a single "Addon-Suite" page is mistaken for a misconfiguration.
Key questions:
DeferredChannel and non-deferred channels?dispatchPending?accepted, skipped, retry, cancelled, failed) exposed for logs, metrics, and support?statamic-brand-context a hard or suggested dependency?Stack fit: Strong for Laravel/Statamic apps using the package's notification facade and database-backed operations. The artisan command fits Laravel's scheduler conventions; settingsNavParent() fits Statamic's Control Panel navigation conventions. The design assumes the host has reliable cron/scheduler and database access. Teams without scheduler discipline must add it before adopting deferred delivery — that prerequisite is unaffected by v1.12.0.
Migration path: Treat v1.11.0 → v1.12.0 as a purely additive, non-functional upgrade for delivery purposes; no migration and no config change. Sequence: upgrade in a branch, confirm the Control Panel settings entry renders as expected (or degrades gracefully on older brand-context), then proceed with the deferred-delivery rollout already planned — run the notification_deliveries migration in staging, publish and review deferred config, implement/resolve DeferredRecipientResolver, schedule notifications:dispatch-pending in staging, and validate retry/backoff with induced failures. Existing immediate notification paths remain unchanged unless explicitly switched to notifyDeferred().
Compatibility: Main functional checks are custom notification channels and recipient resolution. Any custom channel intended for deferred delivery must implement DeferredChannel; otherwise keep it on immediate delivery. Confirm database support for the migration and that scheduler workers run in the correct environment. Add one packaging check for v1.12.0: pin or document the statamic-brand-context version so admin users see a consistent Settings layout across environments; mixed versions will produce different navigation presentations with no error, which is easy to misread as a defect during UAT.
Sequencing: Start with non-critical deferred notifications or in-app only, then mail. Avoid deferred delivery for high-stakes transactional mail until retry, duplicate handling, and recipient-resolution behavior are verified. Add scheduler and alerting before production rollout, and monitor notification_deliveries growth plus failed/retry counts. Because v1.12.0 touches only admin navigation, it can ship independently and ahead of the deferred-delivery rollout — ideally bundled into the same deployment window to limit the number of change events on the notification stack.
Maintenance: New ongoing responsibility remains scheduling and monitoring notifications:dispatch-pending. The package owns dispatch logic; the host owns cron/scheduler, overlap prevention, and environment configuration. Database maintenance increases because deferred rows accumulate until dispatched and may be retained for audit. Teams should define retention and cleanup for notification_deliveries. v1.12.0 adds negligible maintenance — at most, keeping statamic-brand-context current so the settings navigation stays as documented.
Support: Support burden stays oriented toward operational diagnostics: why a notification is pending, claimed, retrying, skipped, cancelled, or failed. TPM should require dashboards or at least queryable views for delivery status and retry counts. Documentation must state that the addon does not schedule itself and that recipients are resolved at send time. Add a short note that admin Settings placement varies by statamic-brand-context version, so first-line support does not file UI-layout tickets as bugs.
Scaling: The per-channel delivery row model scales reasonably with database capacity, but dispatch throughput depends on command batching and concurrency. Multi-node safety depends on lock-based claiming; confirm batch size and whether multiple command instances are supported. Backlog growth is the primary scaling failure mode if the scheduler stops or throughput lags notification volume. Admin navigation has no scaling implication.
Failure modes: Key risks are scheduler not configured, command failing silently, locked rows not recovering after worker crashes, retry storms from persistent channel errors, recipient resolution failures, unsupported channels receiving no deferred row, partial delivery across channels, duplicate sends on retry, and unbounded table growth. Mixed-channel notifications need explicit handling to avoid surprising immediate/deferred splits. v1.12.0 introduces only cosmetic failure modes: a settings entry appearing in an unexpected location, or two environments showing different Settings layouts due to brand-context version skew.
Ramp-up: Low for Laravel/Statamic developers already familiar with artisan commands and migrations; the v1.12.0 change requires no new skill. Moderate for operations teams, since the feature introduces a scheduled command, retry semantics, and delivery-state monitoring. A staged rollout — in-app first, then mail, with clear runbooks for backlog and failure handling — remains appropriate.
How can I help you explore Laravel packages today?