almirhodzic/nova-toggle-5
A Laravel Nova 5 field that adds a clean, customizable toggle switch for boolean values, making on/off settings easier to manage in admin panels with configurable labels and colors.
Architecture fit. almirhodzic/nova-toggle-5 is a Laravel Nova extension that adds a boolean toggle control backed by a package-owned HTTP endpoint rather than Nova's standard update flow. Architecturally it sits inside the Nova admin surface: it depends on Nova's routing, authorization layer, and field/attribute whitelisting to decide who can flip a flag and which columns are eligible. That makes it a good fit only for applications that already run Nova as their back-office; for any Laravel app without Nova, or one deliberately keeping admin mutations on standard resource update endpoints, it is out of scope. Because the toggle is a bespoke endpoint, it introduces a second mutation path alongside Nova's resource controllers — worth noting in any architecture review, since audit trails, model events, and observers must fire identically on both paths for the package to be a safe substitute.
Integration feasibility. The v1.3.1 change is a targeted bug fix: the toggle endpoint previously returned 404 when the target row was soft-deleted, which made the control unusable from With Trashed lenses and similar views that surface trashed rows. The fix conditionally applies withTrashed() to the lookup when the Nova resource uses soft deletes. Integration cost is effectively zero — the release notes describe a drop-in composer update, with no configuration, migration, or resource-class changes. Adoption requires the field to be declared on a Nova resource and the relevant columns added to the toggleable-attribute whitelist, both of which are standard Nova-side configuration rather than package work.
Technical risk. The blast radius of this release is small: behavior is explicitly unchanged for resources without soft deletes, and the authorization and whitelist checks are stated to still run against trashed records, so the fix does not open an authorization bypass on deleted rows. The residual risks are structural rather than release-specific: a single-maintainer package, a small contributor base, and a mutation endpoint whose exact HTTP semantics (verb, CSRF handling, response shape) are not described in the notes. There is also a latent policy question the fix surfaces — restoring or mutating a trashed record is a materially different action from toggling a live one, and teams should confirm that their Nova policies intentionally permit it rather than inheriting the behavior by default.
Key questions.
withTrashed() branch covered in CI?Stack fit. Assumes a Laravel application with Laravel Nova installed and at least one boolean-style attribute suitable for one-click toggling (publish flags, feature switches, moderation states). No additional infrastructure, queue, or storage dependency is implied. Confirm PHP and Nova constraints resolve against our composer.lock before adding to the dependency manifest.
Migration path. From any prior 1.x release this is a patch-level, non-breaking upgrade: bump the constraint, run composer update almirhodzic/nova-toggle-5, clear config and route caches, and smoke-test the toggle from a soft-delete-surfacing lens. No data migration, no republish of assets or config indicated. For a first-time adoption, the sequence is install, register the field on a single low-risk resource, whitelist exactly the attributes intended to be mutable, then verify authorization with a non-admin Nova user before widening.
Compatibility. Backward compatible by the release notes: resources without soft deletes see identical behavior, so existing integrations carry no functional change. The main compatibility surface to verify is the Nova major version — Nova's field and authorization APIs shift between majors, and the package name (-5) suggests a Nova-version-specific line. Validate against our exact Nova release rather than assuming.
Sequencing. (1) Confirm version constraints resolve in a scratch branch. (2) Upgrade in development and exercise the toggle on a soft-delete-enabled resource from a With Trashed lens — the specific case this release fixes. (3) Re-run authorization checks as a restricted Nova user, including against a trashed row. (4) Verify audit/observer side effects on both live and trashed toggles. (5) Promote to staging, then production, behind the normal release window. Treat it as a routine patch, not a change requiring a coordinated rollout.
Maintenance. Low ongoing maintenance burden — a single field plus endpoint, no scheduled jobs, no schema ownership, no external services. The offsetting consideration is bus factor: a one-maintainer package means we own the fork risk if upstream stalls. Worth pinning to a known-good patch version and tracking upstream activity rather than floating on a wide constraint.
Support. The v1.3.1 release is a positive support signal: a community-reported defect in a specific view mode was diagnosed, merged, and shipped with a clear changelog and upgrade instruction. That is the behavior we want from a small dependency, and it raises confidence in the package's stewardship relative to its contributor count.
Scaling. Negligible. Each toggle is a single request performing one scoped model lookup and one column update. Volume scales with admin/operator click volume, not with end-user traffic. The only scaling-adjacent concern is lock contention if the same row is toggled concurrently by multiple operators — a UX correctness issue, not a capacity one.
Failure modes. The regression being fixed is itself the canonical failure mode: a 404 on trashed rows that renders the control silently broken rather than loudly failing, which is easy to miss without explicit test coverage of trashed views. Other modes to watch: a silently inert toggle when an attribute is omitted from the whitelist; an authorization gap if Nova policies are permissive for trashed records and the team assumed otherwise; and divergence between toggle-path and update-path side effects (missing audit entries, un-fired observers). None of these are introduced by v1.3.1 — the release closes one and leaves the others as configuration and policy obligations on our side.
Ramp-up. Minimal. A Laravel/Nova-fluent engineer can install, configure, and validate the field in well under a day, most of which is spent on authorization verification rather than package mechanics. Documentation burden for the team is essentially a note in the admin tooling runbook covering the whitelist convention and the trashed-record policy decision.
How can I help you explore Laravel packages today?