- What is orchestra/html used for in Laravel?
- Orchestra/HTML is a lightweight convenience layer that gives Laravel a fluent, chainable builder for generating HTML markup and forms programmatically instead of scattering inline HTML through Blade templates and controllers. It wraps Laravel Collective's Form and Html builders and adds Orchestra-specific helpers such as control(), raw(), and macro support, plus Bootstrap-style component helpers for panels, buttons, and alerts. Its realistic sweet spot is repetitive server-rendered admin screens where model binding, CSRF tokens, method spoofing, and old-input repopulation can be absorbed by the builder. It is a scoped internal accelerator rather than a design-system foundation.
- How do I install orchestra/html with Composer?
- Install it with composer require orchestra/html in a Laravel application. The package binds form and html into the Laravel container and aliases the Form and Html facades, so no manual service provider registration is normally needed. If your application already runs Orchestra Platform, the package often arrives transitively through orchestra/foundation and adoption cost is close to zero. On a plain Laravel app, verify Composer resolves cleanly against your pinned Laravel version before committing.
- Is orchestra/html a replacement for Laravel Collective HTML?
- No, it is a thin wrapper on top of Laravel Collective's builders rather than a replacement. Because both packages alias the Form and Html facades, registration order determines which builder actually answers, and methods can appear to exist while behaving differently. That facade and binding collision is the main day-one debugging tax when adopting it. If you already use Laravel Collective directly, introducing Orchestra/HTML adds a second layer over the same underlying API.
- Which Laravel versions does orchestra/html support?
- Support is governed by the illuminate/* and collective/html constraints declared in the package's composer.json, so the supported Laravel range depends on the release you install. Check those constraints against your pinned framework version before adopting, since Composer resolution failure is a hard no-go rather than a fork-and-patch opportunity. The package has few dependents and a low package score, so there is little ecosystem signal to rely on. Widen constraints only with intent, and test the upgrade path yourself.
- How do I register custom HTML macros with orchestra/html?
- The package includes macro support that lets you register custom, reusable HTML generators once and call them from anywhere in your views or controllers. Macros are the recommended way to encapsulate repeated markup patterns so your Blade templates stay short and consistent. Keep macro definitions in a service provider or a dedicated bootstrap file so they are registered before any view renders. Because macros produce markup, treat any that accept user-supplied attributes as part of your escaping review surface.
- Is orchestra/html safe for production use, especially regarding XSS?
- Output is escaped consistently by default, but two helpers deliberately widen the surface: control() returns markup that must be echoed raw, and raw() bypasses escaping entirely. Every Form::raw() or Html::raw() call should be treated as a reviewed security decision, because an XSS regression there is low-probability but high-impact if it reaches anything customer-visible. Restrict the package to internal, non-revenue-critical admin surfaces and require escape verification whenever forms change. Assign an owner with budget to carry upgrades and security review.
- Can I use orchestra/html with Livewire, Inertia, or a Blade component library?
- You can, but you generally should not. Where a Blade component library, Livewire, Inertia, or a design system already owns form markup, adding Orchestra/HTML creates a second convention and exactly the fragmentation the package was meant to remove. Its markup is Bootstrap-3-era, so a Bootstrap 5 or Tailwind admin theme will need class overrides or wrappers. It fits poorly as a public-facing rendering layer or a design-system foundation.
- Why are my forms failing with 419 errors or stale state when using orchestra/html?
- Common failure modes include duplicate _token inputs causing 419 responses, Form::model() state bleeding across an unclosed form, and control() not wiring validation error state. These render fine and then fail on submit or fail quietly, which makes them expensive to discover in production admin workflows. They are cheap to catch with assertions in your test suite, so add coverage around every form you build with the package. Also confirm app('form') returns Orchestra\Html\FormBuilder so you know which builder is answering.
- Does orchestra/html require Orchestra Platform to be useful?
- It does not technically require Orchestra Platform, but that is where the value is clearest. On an Orchestra Platform application the package typically arrives transitively via orchestra/foundation, and the decision becomes reuse versus ignore. On a plain Laravel app, integration is a deliberate composer require with a thin independent value proposition, since a handful of helpers can be replicated with native Blade components in an afternoon. Frame it as a scoped internal accelerator, not a strategic dependency.
- Is orchestra/html actively maintained, and what are the alternatives?
- The package shows roughly zero dependents and a low package score, so there is little social proof to de-risk adoption. For new projects, native Blade components, Livewire, or a dedicated form package such as Laravel Collective used directly are usually better-supported alternatives. If you do standardize on Orchestra/HTML, bound the surface behind an adapter and avoid Orchestra\Html type hints in domain code so the exit cost stays low. Do not migrate existing views; introduce it opportunistically on new internal forms only.