Nova Resource Landing Page Laravel Package

Getting Started

This package is a small Nova convenience layer for singleton-style resources — models that realistically only ever have one record (site settings, company profile, feature flags table, a "homepage" CMS page). Instead of clicking the sidebar item and landing on an index of one row, you point the nav link straight at that record.

Minimum steps to first use:

1. Install and pin.

   composer require markrassamni/nova-resource-landing-page
   

   The package is archived and last released 2020-10-31 (v3.0.0, aligned to Nova 3.4.1). Pin an exact version in composer.json rather than using a floating constraint.

2. Register it from app/Providers/NovaServiceProvider.php alongside your resources, following the package's service-provider registration call (check the README for the exact Nova::… call — it is typically a boot-time registration, not a publishable config).

3. Find the resource hook. Look at how the package expects you to opt a resource in — likely a property/interface/method on the Resource class, or a registration map in the service provider. Check vendor/markrassamni/nova-resource-landing-page/src first; there is no meaningful published documentation, so the source is the docs.

4. Pick your first resource with exactly one row and confirm the behavior in both cases:

   • With one record: nav click goes to that record's detail (or edit) page.
   • With zero or many records: nav click falls back to the standard index.

Where to look first, in order: src/ (the service provider and any Nav/Link class), then resources/views for the custom view referenced by the v3.0.0 release note, then the README. The v3.0.0 note ("View updated to match Nova v3.4.1") tells you the implementation is view-driven, so expect rendering and Nova asset assumptions rather than a database or config surface.

Implementation Patterns

Singleton-resource pattern (the primary use case). Apply the landing-page behavior to resources where an index page is pure friction — SiteSetting, CompanyProfile, Homepage, FeatureFlag singletons. Leave it off everything else; you do not want a resource with 500 rows accidentally routing to row #1.

Defensive single-record resolution. Treat "only one record" as an expectation, not a guarantee. Confirm (or wrap) how the package resolves the record — most singleton implementations do something like Resource::newModel()->first() at nav-build time. Ensure your resource returns null → falls back to index, not a 404. Test with an empty table before shipping.

Authorization alignment. The package is documented as respecting Nova's authorization and routing conventions, which means the nav link should only appear when the user can viewAny/view the resource. Verify this explicitly:

• A user who can viewAny but not view the single record should not get a broken direct link.
• If your Resource::authorizable() or policy is customized, re-run the nav as a low-privilege user — this is the most common way a "convenience" package becomes a support ticket.

Pair with detail-page actions. Because users now land on the record page, put your useful Nova actions there rather than on the index toolbar. This is where the package pays off: a settings resource becomes "click once, edit the form," which is exactly the ergonomic win for admin-only screens.

Registration as a map, not per-class boilerplate. If the package supports a resource→landing-page mapping in the provider, keep that list in one place (a dedicated method in NovaServiceProvider) so the set of "landing page" resources is auditable in a single diff. This makes it obvious when someone adds a multi-row resource to a singleton list.

Testing pattern. Add a feature test asserting the nav/index behavior:

$this->actingAs($admin)->get('/nova/resources/site-settings')->assertOk();

and a second test after deleting all rows to confirm graceful fallback. Nova's nav is rendered server-side, so this is cheap to cover and catches the archived-package breakage early on Nova upgrades.

Migration/upgrade discipline. Since this package targets Nova ~3.4.1 and is unmaintained, isolate it behind your own thin wrapper if you anticipate ever needing to replace it (e.g., a custom Nova Nav/resource override). A wrapper class you control gives you a swap path without touching every resource.

Gotchas and Tips

• Archived and unmaintained. No future releases; the v3.0.0 note is a single compatibility line. Assume you will own any breakage. Pin the version and add it to your Nova-upgrade checklist.

• Nova version coupling. v3.0.0 was aligned to Nova 3.4.1. If you are on a materially different Nova 3.x or on Nova 4+, the view override is the most likely thing to break first — the nav will render but the link, route helper, or asset references may not resolve. Smoke-test the nav after every Nova bump.

• "Single record" is an assumption, not a constraint. The name says landing page; the short description says "the only record." Confirm which behavior you get with 0, 1, and 2+ rows. If the package naively grabs first(), add a guard in your resource or a test to prevent silently hiding the index from a multi-row resource.

• No config/publishes to rely on. Do not expect vendor:publish for views or config. Customization means overriding the package's view via your own resource or subclassing — document that override in the repo so the next dev knows it exists.

• Nav caching / ordering. Nova caches navigation aggressively at boot; if a landing page appears or disappears based on data (e.g., record count), clear caches and confirm behavior on a cold boot. Data-dependent nav routing is fragile by nature — prefer routing based on resource configuration, not row counts, if the API allows it.

• Debugging a broken link. Start with php artisan route:list --path=nova to confirm the target route exists, then php artisan nova:publish --force (carefully — this overwrites custom views) if the view is stale. Most "nothing happens on click" reports are a stale published asset or a 404 route, not a permissions bug.

• Extension points are thin. The safest extension surface is your own Resource subclass and NovaServiceProvider registration. Avoid editing vendor/; if you must patch, use a Composer patch plugin so the fix survives composer install.

• Blast radius is admin-only. Failures block internal operations but not customers — still, don't let the low stakes become an excuse to skip the authorization test. A broken settings link is annoying; a settings link that 500s for non-admins looks like a security signal to whoever reports it.