Download the PHP package ruvelo/laravel-inbox without Composer
On this page you can find all versions of the php package ruvelo/laravel-inbox. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download ruvelo/laravel-inbox
More information about ruvelo/laravel-inbox
Files in ruvelo/laravel-inbox
Package laravel-inbox
Short Description The in-app notification inbox Laravel never shipped: a header bell, an inbox page and per-type preferences, on top of the database notification channel.
License MIT
Homepage https://ruvelo.github.io/laravel-inbox/
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-inbox
Live demo Configuration Developer guide Changelog
Laravel Inbox
The in-app notification inbox Laravel never shipped. A bell for your header, an inbox page, and per-type preferences, built on Laravel's own database notification channel. The notifications you already send show up as they are: no new table for them, no changes to your classes, no frontend build step.
Then put <x-inbox::bell /> in your header. Or click around the live demo first.
A quick tour
A bell for your header. One Blade tag. It shows the unread count, and opens on the latest notifications. Opening one marks it read in the background and takes you straight to it. The count keeps itself up to date while the tab is open, and updates instantly if your app uses Laravel Echo.
An inbox page for everything else. All and Unread tabs, notifications grouped by day, a filter by type, and mark read, mark unread and delete on every item.
Preferences people can set themselves. Each notification type, each channel, one switch. Your notifications' via() respects them with one line.
Light and dark, following each person's system setting (or your app's data-theme / .dark). |
Made for phones too, with the actions always in reach. |
Features
- Zero changes to existing notifications. Anything you send through the
databasechannel appears. By convention,toArray()/toDatabase()returnstitle,body,url, and optionallyicon(an emoji or a short string) andactor(a name). Other shapes still show, titled after the class:InvoicePaidNotificationbecomes "Invoice paid". <x-inbox::bell />: unread badge (capped at 99+), a dropdown with the latest notifications, "Mark all as read", "View all" and "Preferences". Without JavaScript it's a link to the inbox. With it: an accessible dropdown (aria-expanded, Esc to close, focus moves in and back), read marks sent in the background, a polled unread count that pauses while the tab is hidden, and live updates over Laravel Echo whenwindow.Echoexists.- The inbox page at
/inbox: All and Unread tabs, grouped by Today, Yesterday and dates in your app's timezone, filter by type, mark read or unread, delete, mark all as read, pagination and helpful empty states. Clicking an item marks it read and follows its link, through a plain redirect that works without JavaScript. - Preferences at
/inbox/preferences: per notification type, people switch channels on and off. Types have labels, descriptions, groups, per-channel defaults, and can be required (shown, but always on). RespectsInboxPreferences: one trait, one line invia().- A JSON API for React, Vue and Inertia, over the session: only ever the signed-in user's own notifications.
- Safe by default: everything is escaped, links are only ever
http(s)or paths (javascript:URLs in stored data are dropped), and someone else's notification is a 404 on every route. - Cheap: the unread count is one indexed
COUNTquery, and the bell runs two queries however many notifications there are. - Fits in: the bell's styles are scoped and included once, so they can't touch your CSS. The pages can use your app's layout.
Requirements
- PHP 8.3+
- Laravel 12 or 13
- The
notificationstable:php artisan make:notifications-tableif you don't have it yet - A notifiable model that uses Laravel's
Notifiabletrait (usuallyUser)
Using it
Put the bell in your layout, wherever your header is:
It renders nothing for guests. Options: <x-inbox::bell :limit="8" :poll="60" label="Updates" class="ms-auto" />, and :user="$someone" to show another notifiable than the signed-in user.
Send notifications as you already do, with a title, body and url:
That's all. subject, message and action_url work too, if that's what your notifications already use.
Describing a notification in code
Implement InboxNotification and the inbox stores your message with the notification; you don't need toArray():
Or decide how a type looks without touching it (handy for notifications from other packages, or ones already in the database):
Preferences
Register the types people can switch, in config/inbox.php or a service provider:
Then let the notification respect them:
Channels that aren't listed for a type, unregistered types, required types and on-demand notifiables (Notification::route(...)) always get through. To share one switch between several notifications, override inboxType() to return the same key. Choices live in their own table, one row per explicit choice; everything else follows the type's default.
Who sees what
Every route needs a signed-in user and only ever shows or changes that user's own notifications. Anyone else's notification is a 404, never a 403, so ids can't be probed. Guests are sent to your login route, or get a 403 in an app that doesn't have one yet (a fresh install before a starter kit), so you don't need auth in the middleware, though it's fine to add it.
Configuration
Publish the config file if you want to change the defaults:
| Key | Default | |
|---|---|---|
path |
inbox (INBOX_PATH) |
URL prefix for the inbox and preferences pages |
domain |
null |
Serve them on their own (sub)domain |
middleware |
['web'] |
Applied to every page; signing in is always required |
routes |
true |
Set to false to register routes yourself (copy routes/web.php) |
api.enabled |
true (INBOX_API) |
The JSON API |
api.prefix |
api/inbox |
Where the JSON API lives |
api.middleware |
['web'] |
Session authentication: keep web, or use your own guard |
layout |
null |
Your layout view for the pages; null uses the package's own |
section |
content |
The section of your layout the pages fill |
bell.limit |
6 |
How many notifications the dropdown shows |
bell.poll |
30 |
Seconds between unread-count checks; 0 turns polling off |
bell.echo |
true |
Listen on the user's private channel when Laravel Echo is on the page |
per_page |
25 |
Notifications per page on the inbox |
timezone |
your app's | Timezone for "Today", "Yesterday" and dates |
preferences |
[] |
Notification types people can switch on and off |
channels |
database → In app, mail → Email… |
How channels are labelled on the preferences page |
notifications_table |
notifications |
Laravel's notifications table |
table_prefix |
inbox_ |
The preferences table is {prefix}preferences |
run_migrations |
true |
Set to false if you publish the migration and run it yourself (--tag=inbox-migrations) |
Making it look like your app
The colours are CSS variables, scoped to the bell and the pages, using the Ruvelo house style. Override any of them in your own CSS:
To put the inbox and preferences pages inside your app's chrome, point layout at your layout. The pages fill the section you name (and a title section), and bring their own scoped styles:
For full control, publish the views. They land in resources/views/vendor/inbox:
For developers
PHP API
The write methods accept Laravel's own DatabaseNotification (what $user->notifications returns) as well as the package's Ruvelo\Inbox\Models\Notification, which reads the same table and adds message(), isUnread() and the ownedBy($user) scope.
InboxMessage is a small immutable value object: make($title, $body, $url, $icon, $actor), with…() methods that return copies, initials(), excerpt() and toArray().
JSON API
For React, Vue and Inertia front ends. It runs on the session (web middleware), so send the CSRF token on writes as you would for any form, and only ever touches the signed-in user's own notifications. Paths are relative to /api/inbox.
| Request | Does |
|---|---|
GET /notifications |
List, newest first. ?filter=unread, ?type=<class>, ?per_page= up to 100. meta.unread and meta.types included |
GET /notifications/count |
{"unread": 3}: cheap enough to poll |
GET /notifications/{id} |
One notification |
POST /notifications/{id}/read |
Mark read; returns the notification |
POST /notifications/{id}/unread |
Mark unread; returns the notification |
POST /notifications/read-all |
{"marked": 3, "unread": 0} |
DELETE /notifications/{id} |
Delete. 204 |
GET /preferences |
Every registered type with its label, description, group, required and channels: {mail: true, …} |
PUT /preferences |
{"preferences": {"App\\Notifications\\InvoicePaid": {"mail": false}}}; only the pairs sent change. 422 for unknown types or channels, or for turning off a required type |
A notification looks like this:
Someone else's notification is a 404; a guest gets a 401.
Web routes
GET /inbox |
The inbox (?filter=unread, ?type=) |
GET /inbox/preferences, PUT /inbox/preferences |
Preferences |
GET /inbox/{id}/open |
Mark read and follow the link |
POST /inbox/{id}/read, /unread, DELETE /inbox/{id} |
One notification; answers JSON when asked for it |
POST /inbox/read-all |
Mark everything read |
GET /inbox/count, GET /inbox/bell |
What the bell polls, and its list as HTML |
Events
| Event | When |
|---|---|
NotificationRead |
A notification was marked read, one at a time or by opening it |
NotificationUnread |
A read notification was marked unread |
AllNotificationsRead |
Someone marked everything read; has notifiable and count |
NotificationDeleted |
A notification was deleted |
PreferencesUpdated |
Someone changed their preferences; has notifiable and the changes |
All in Ruvelo\Inbox\Events, and only fired when something actually changed.
Exceptions
UnknownPreference (a type or channel that isn't registered), RequiredPreference (turning off a required type) and InvalidPreferenceType (a malformed registration), all extending Ruvelo\Inbox\Exceptions\InboxException.
In your tests
Using an AI coding agent?
The package ships Laravel Boost guidelines in resources/boost/guidelines/core.blade.php. With Boost installed (composer require laravel/boost --dev), run php artisan boost:install and pick ruvelo/laravel-inbox from the third-party packages (or php artisan boost:update --discover if Boost is already set up). Your agent then knows how to put the bell in your layout, make notifications show nicely, respect preferences, and use the JSON API, and what not to do.
Contributing
Pull requests are welcome. Clone, composer install, then composer check runs code style (Pint), static analysis (PHPStan level 8) and the tests, exactly as CI does. See changelog.
The demo and screenshots are built from the package itself: composer demo writes the static demo into build/, and demo/screenshots.sh regenerates art/.
Credits
Built by François Bultez at Ruvelo, and everyone who contributes.
License
MIT. See LICENSE.
