Weave Code
Subscribable Notifications Laravel Package
ylsideas/subscribable-notifications
Laravel package for subscribable notifications: users opt in or out of notification types, subscriptions are stored in the database, and notifications go only to subscribed users through customizable, queueable channels with per-user preferences and easy integration.
A Laravel package for adding unsubscribe links to notifications
Frequently asked questions about Subscribable Notifications
- How do I install ylsideas/subscribable-notifications in a Laravel app?
- Install it with composer require ylsideas/subscribable-notifications, then publish the config and migration files and run php artisan migrate. Next, apply the Subscribable trait to your User model (or any Notifiable model that needs preferences) and guard your notification classes with the subscription check. Adoption is additive and trait-based, so it typically takes hours rather than sprints and does not require rewriting existing Notification classes.
- Does this package support Laravel 11, 12, and newer releases?
- Support is driven by the illuminate/* and PHP constraints in the package's composer.json, and releases are infrequent, so version bumps tend to arrive reactively after a new Laravel major ships. Before adopting, read the composer.json diff for the release you plan to use and confirm your current Laravel major is still in the same release line. A raised PHP floor is the most likely hidden breaking change in a version that looks like a compatibility-only bump.
- How do I add an unsubscribe link to Laravel email notifications with this package?
- The package stores per-user, per-notification-type subscription state and gives your notification classes a resolver to consult before dispatching. You expose that state through a route or signed URL in your app and render it as the unsubscribe link in the mail template. Because the check happens before the notification is sent, users who opted out never receive the message in the first place.
- How are user notification preferences stored by the Subscribable trait?
- Subscriptions are persisted in a database table created by the package's published migration, holding opt-in or opt-out state per user and notification type. It is a thin domain layer over Laravel's native Notifiable trait rather than a replacement for it. Inspect the generated schema in staging after the first migration so you know exactly which columns and indexes you inherit.
- Can users opt out of specific notification types instead of all notifications?
- Yes. Subscriptions are keyed to named notification types, so a user can disable marketing or digest notifications while staying subscribed to account-related ones. The main product work is deciding which notification types should be user-controllable and wiring a preferences UI, settings screen, or API endpoint to manage them.
- Do subscription checks apply to queued and on-demand notifications?
- Guards placed in the notification's via() or channel methods run when the notification is handled, so queued notifications of the same class generally respect them. On-demand notifications sent with Notification::route(...) do not resolve through a Notifiable model, so verify that path explicitly in your test suite. Any coverage gap here becomes a production incident, so test mail, database, and broadcast channels separately.
- How do I force-send critical notifications like password resets regardless of subscription state?
- The safest approach is to simply not consult the subscription resolver in transactional or security notification classes such as password resets, email verification, and security alerts. Keep an explicit list of non-subscribable notification types in your codebase and review it whenever a new notification is added. Treating compliance-critical mail as always-on avoids the failure mode of suppressing mail a user genuinely needs.
- Is ylsideas/subscribable-notifications safe to use in production?
- Technical risk is low to moderate: the package is small and additive, but it is maintained by a single author with a sparse release cadence, so Laravel major-version support can lag. The more serious concern is correctness, because bugs are silent, meaning an unsubscribed user still gets mail or a critical notification is suppressed. Lock-in is low, since the surface area is just a trait, a table, and a resolver, so forking or inlining the behaviour is a credible exit ramp.
- What migration does the package publish and is it safe to run in production?
- The package owns a migration for its subscription state table, and that schema is something you inherit and must upgrade alongside the package. Publish the migrations, run them in staging first, and diff the database/migrations directory between versions before running php artisan migrate in production. Look for new columns, index changes, or table renames in any release you upgrade to.
- What are the alternatives to subscribable-notifications, or should I build it myself?
- Alternatives are rolling your own preferences table plus a trait and guards in via(), or handling opt-outs entirely with your own per-channel logic in each Notification class. Because this package's abstraction is thin, inlining equivalent behaviour into your app is realistic if you need full control or the maintainer stalls. Choose the package when you want the pattern in hours rather than days, and build in-house when notification policy is core to your product.
Weaver
How can I help you explore Laravel packages today?