norman-huth/nova-single-resource
A Laravel Nova package that turns a resource into a single-record resource, hiding index and create views so users manage just one entry. Ideal for settings, profiles, or singleton content pages in Nova.
Install the package alongside Nova (Nova 4 is the realistic target given the Dec 2022 release):
composer require norman-huth/nova-single-resource
No service provider registration is needed if the package uses Laravel auto-discovery; check composer.json for extra.laravel.providers if it doesn't appear.
Create a model and migration for the singleton — e.g. SiteSettings with a migration that creates the table, plus a seeder or firstOrCreate call so exactly one row exists. The package assumes a single record, so the data layer is your responsibility.
Create a Nova resource extending the package's single-resource base class (the package ships a resource class you subclass rather than plain Laravel\Nova\Resource). Point $model at your singleton model.
Register it in NovaServiceProvider::resources() like any other resource. The package's job is to skip the index/list view and send users straight to the edit form.
First use case: a "Site Settings" or "Homepage Content" screen — one editable record, no create/delete buttons, no index table. Open it, change values, save; that's the whole loop.
Singleton via firstOrCreate: seed the row in a migration, seeder, or a service provider boot() call. Allowing Nova to create the record is usually the wrong model — the package is designed around "the record already exists," so ensure it does before the resource is first visited.
Redirect-to-edit flow: the core pattern is that the resource's index route resolves to the edit form of the single record. Day-to-day, that means the resource behaves like a long form, and you spend your time on fields() rather than on table columns or filters.
Field organization: because there is one record and no list view, lean on Nova panels and Stack/Panel groupings to structure many settings fields. The package's fields (if you use them) are conveniences on top of standard Nova fields; you can generally mix in ordinary Nova fields freely.
Authorization: write a policy for the singleton model. Since the record is fixed, view/update on that record is all that matters; create/delete/restore can be denied outright. This is where you gate who can edit global content.
Navigation: hide or rename the resource's navigation label so it reads like a page ("Settings") rather than a CRUD resource, and set a sensible icon. Group it separately from your normal resources.
Reading the value elsewhere: treat the model like any Eloquent model in your app — SiteSettings::first() in a service provider or view composer, ideally behind a cached helper, since it's read on nearly every request.
The package is archived (Dec 2022). Treat it as frozen. It will not gain Nova 5 (or later) compatibility, and there are no dependents and very low adoption (5 stars), so you are effectively the maintainer if it breaks. Pin Nova to a compatible major version before committing.
Nothing enforces "single" at the DB level. A second row can appear via seeders, imports, or a stray create(). Consider a unique constraint or a guard in the model, and always resolve the record with first()/firstOrCreate() rather than find().
Index/edit assumptions leak. If a user bookmarks an index URL or a stale create URL, behavior depends on the package's redirects. Test the routes you don't normally visit (create, index, 404s) rather than only the happy-path edit form.
Caching after save: if you cache the singleton for front-end reads, invalidate on save. Nova saving the model won't automatically clear your own cache layer — hook saved/updated model events.
Debugging routing issues: run php artisan route:list and look at the resource's routes to confirm the index is genuinely redirecting to edit rather than rendering an empty table. Most "it doesn't work" reports on packages like this are Nova version mismatches or a resource not registered.
Extension points are thin: expect to subclass the provided resource and override fields(), authorizedToCreate(), and navigation methods yourself. Don't expect a config file with dozens of toggles — inspect the package source (it's small) rather than assuming documented options exist.
Migration path off the package: because it's a thin wrapper, replacing it usually means subclassing Laravel\Nova\Resource directly and overriding index/availableForNavigation to redirect to edit. Budget for that if you adopt it in a long-lived project.
How can I help you explore Laravel packages today?