Weave Code
Messages Laravel Package
orchestra/messages
A lightweight messaging component for Laravel that manages session-based notifications, alerts, and flash messages. Integrates smoothly with Orchestra Platform to provide consistent, reusable user feedback across your applications and admin panels.
Orchestra Messages provides a simple, extensible messaging layer for Laravel and the Orchestra Platform, letting applications send and manage notifications, alerts, and user-to-user messages through a consistent API. It integrates cleanly with Laravel's service container and Orchestra extensions, so messages can be queued, templated, and delivered without boilerplate.
- Pluggable message templates and content rendering
- Queue-ready delivery for async notifications
- User-to-user and system message support
- Native Orchestra Platform extension integration
- Simple, fluent API for sending and managing messages
Frequently asked questions about Messages
- What is orchestra/messages used for in a Laravel application?
- It is a lightweight messaging component that manages session-based notifications, alerts, and flash messages, giving you a fluent, severity-typed API (success, error, warning, info) instead of raw session()->flash() calls. It also integrates with the Orchestra Platform so the same feedback layer works across your applications and admin panels. It is deliberately narrow: it is a thin ergonomic layer over Laravel's MessageBag plus session flashing, not a full notification system.
- How do I install orchestra/messages?
- Install it with Composer using orchestra/messages, then rely on Laravel's package auto-discovery to register the service provider. If the package ships configuration, publish it with the vendor publish command and re-run config:cache afterwards, because a published config file is not visible to a cached config until you re-cache. The whole integration surface is small: flash a message in a controller, redirect, and render it in your layout.
- Does orchestra/messages send email, SMS, or push notifications?
- No. Despite the name, it does not provide email, SMS, push, database-persisted per-user notices, digests, retries, or templating, so it is not a replacement for Laravel's notification system. It handles messages that live in the session for the next request and are rendered in your Blade views. If you need real notification delivery, pair it with Laravel notifications and keep this package for user feedback only.
- Which Laravel and PHP versions does orchestra/messages support?
- There is no published compatibility matrix, so the package's own composer.json is the only source of truth for its illuminate/* and PHP constraints. Pin the ^6.1 line deliberately, since that is the release that claims Octane support and you do not want Composer floating down to 6.0.x. Verify the resolved versions against your Laravel and PHP matrix before rolling it out beyond a pilot module.
- Does orchestra/messages work with Laravel Octane and queue workers?
- The ^6.1 line claims Octane support, but you should confirm it with your own smoke test rather than trusting a changelog line. The key thing to check in the source is whether the service provider binds the message bag as a singleton or with scoped(), because a singleton can leak messages across requests under octane:start or between queue jobs. A simple two-request test under Octane tells you whether state persists when it should not.
- How do I render orchestra/messages output in my Blade layout?
- Render once in your layout through a single wrapper component that carries your design-system markup, rather than sprinkling partial includes across views. Before you do, read the shipped Blade partial to confirm whether it escapes output by default, since any message path that can carry markup would otherwise be a stored XSS risk. Keeping your own wrapper also means a future swap away from the package touches one file instead of dozens.
- Do multiple success() or error() calls stack up, or does the last one win?
- That behavior is not documented, so verify it from the source before designing around it. Check whether repeated calls per severity append to a collection or overwrite the previous entry, and whether the session key is namespaced to avoid collisions with other flashes. If your UX depends on showing several messages at once, add a test that asserts the exact flash payload after two calls.
- How do I test flash messages with orchestra/messages?
- Assert on the session flash key directly for unit-level checks, and use withSession for round-trip tests that actually render the layout. Be aware that the array session driver drops flashes between test requests, which is the most common reason a message appears not to render in tests. Also write one test that runs under Octane to confirm the container binding does not carry messages across requests.
- Is orchestra/messages a good fit for an Inertia, Livewire, or headless API project?
- Generally no. It fits server-rendered Laravel with Blade layouts and session state well, but on headless API, Inertia, or Livewire-only front ends only the collection half applies, and that half is roughly a hundred lines you could own yourself. Adopting it there risks locking your feedback UX to server-rendered pages. If you do use it, keep the seam in front of the package so the rendering strategy can change independently.
- Should I depend on orchestra/messages long term, or write my own flash message class?
- The dependency signal is thin, with few external dependents, so treat this as adopting a small utility rather than an ecosystem. Before committing, put an App\Support\Feedback style class with four methods in front of it, bind it in a service provider, and type-hint that in controllers, so the vendor bag is an implementation detail. Then migrate one CRUD module at a time and delete the old session()->flash('status', ...) convention as you go, because two coexisting conventions are worse than the one you started with.
Weaver
How can I help you explore Laravel packages today?