Weave Code
Widget Laravel Package
orchestra/widget
Orchestra Widget provides a lightweight widget manager for Laravel, letting you register, resolve, and render reusable UI components within the Orchestra Platform ecosystem. It integrates with the framework's container and view layer to keep dashboards and admin panels modular.
Widget Component for Orchestra Platform
Frequently asked questions about Widget
- What is orchestra/widget used for in Laravel?
- It is a lightweight widget manager that lets you register a widget by id, place it in a named area, resolve widgets in order, gate them by permission, and render a namespaced view. It is first-party plumbing for Orchestra Platform, a modular application and CMS layer built on top of Laravel. It deliberately ships no UI, no persistence, and no admin screens, so it is best understood as a small widget contract plus a registry bound in the container. If you are not running Orchestra, treat it as a pattern reference rather than a dependency.
- Does orchestra/widget work on vanilla Laravel or does it require Orchestra Platform?
- It technically installs on a plain Laravel app, but its design assumes Orchestra's extension manager, memory and config system, and ACL. Adopting it standalone usually means pulling in orchestra/support and related contracts, which is a heavy footprint for what is functionally a dashboard widget registry. The practical decision is binary: either your app already runs Orchestra and this is the native seam, or you should port the pattern into your own service provider and Blade components. There is no cheap middle ground.
- Which Laravel and PHP versions does orchestra/widget support?
- The latest documented release, v6.0.0, targets Laravel 8, which is a hard ceiling signal and is already out of support on most current roadmaps. You should check the composer.json constraints for php and illuminate/* before committing, because they must intersect your target framework version. Code of this vintage often relies on helpers such as array_get and str_* that have since been removed from Laravel, so expect friction on newer versions. Verify the actual tag and release date in the repository rather than assuming active maintenance.
- How do I install orchestra/widget via Composer?
- Install it with composer require orchestra/widget, then confirm the resolved version matches the major that aligns with your Laravel version. Because feasibility depends on your environment, read the package's composer.json first to see whether its php and illuminate/* constraints resolve against your app. If you are not on Orchestra Platform, treat the install as a spike or reference checkout rather than a production dependency. Freeze and vendor the source if you do adopt it.
- How do I register and render a widget with orchestra/widget?
- The abstraction is small: you register a widget with an id, attach it to a named area, give it an order, optionally supply a visibility predicate, and let it render a namespaced view. Resolution happens through the container, so widgets are assembled in order for a given area at render time. Because it is plumbing only, you supply the Blade views and any data each widget needs. Read the widget contract (base class or interface) and confirm it is stable across majors before building on it.
- Does orchestra/widget require other Orchestra packages such as orchestra/support or orchestra/extension?
- Very likely yes in practice, since the package is designed to be consumed by Orchestra's extension manager, memory and config system, and ACL. You should confirm whether it hard-requires orchestra/extension, orchestra/memory, or orchestra/authorization by reading its composer.json. That dependency chain is the main reason standalone adoption is expensive. If your app already runs Orchestra, these are already present and the cost is effectively zero.
- How does orchestra/widget handle widget ordering and named areas?
- Widgets are registered with an id, assigned to a named area, and resolved in a defined order when that area renders. That is the core of the contract: id, area, order, visibility predicate, render callable, and cache TTL. The package provides the plumbing for that resolution but not the rendering surface, so you build the Blade side yourself. This makes it a legible reference implementation if you plan to reimplement the pattern first-party.
- Is orchestra/widget actively maintained and safe for production?
- The signals are weak: zero stars, zero dependents, a low package score, and an unverified maintenance status, which means no downstream bug reports and no community patch stream. The risk is concentrated in ownership rather than security, but there is a modest attack surface in dynamic widget class resolution and view rendering that you would have to audit yourself. The realistic failure mode is not an incident, it is a silent internal fork you maintain indefinitely. Only adopt it if Orchestra Platform is already in play and you vendor the source.
- What are good alternatives to orchestra/widget for Laravel dashboards?
- For vanilla Laravel, mature options such as arrilot/laravel-widgets, Filament widgets, and Nova cards ship UI, permissions, and persistence out of the box, none of which this package provides. Benchmark those first if you need a working dashboard rather than a widget contract. If you only want the pattern, a first-party Widget interface plus a container-bound registry and a Blade renderer is roughly one to two days of work. That reframes the decision as build versus vendor, where build is cheap and vendor is expensive.
- Should I use orchestra/widget or build my own widget registry?
- If your application already runs Orchestra Platform, pin to the major matching your Laravel version, vendor the source, and add an upgrade gate to CI, treating it as internal code with a public upstream. On greenfield or vanilla Laravel, port the contract instead: define a Widget interface covering id, area, order, visibility predicate, render callable, and cache TTL, bind a registry in the container, and add a Blade renderer. That removes the dependency risk entirely for a couple of days of work. Either way, check the license and copyright holder first so you can fork internally without legal friction.
Weaver
How can I help you explore Laravel packages today?