Nova Hide Navigation Laravel Package

Getting Started

This package is archived (last release 2023-11-04, 2 stars, 0 dependents), so treat it as unmaintained code you are adopting rather than a dependency you are consuming. Before writing anything, read the README's maintained-alternatives note and decide whether you are forking, vendoring, or migrating.

Minimal path:

1. Check your Nova major version. The package targets the Nova 4.x era; if you are on Nova 5+, assume incompatibility until proven otherwise and test in a scratch branch first.
2. Pin the version explicitly in composer.json rather than relying on a floating constraint, since no further patches will arrive.
3. Install: composer require norman-huth/nova-hide-navigation and let package auto-discovery register the service provider. If discovery is not used, add the provider to config/app.php or your Nova application bootstrap.
4. Publish anything it exposes (vendor:publish with the package provider, then php artisan nova:publish) and inspect the published config/assets — that is where the actual toggle lives.
5. First use case: hiding the Nova main navigation for a specific audience (e.g. non-admin users, an embedded/kiosk view, or a client-facing panel) so resources are reachable only by direct URL or dashboard links. Confirm the hide is scoped to the right users before shipping.

Where to look first: the published config file, the package's service provider, and any published assets/views. Those three tell you whether hiding is config-driven, middleware-driven, or CSS/asset-driven — and that determines the integration pattern below.

Implementation Patterns

Wrap it behind your own adapter. Because the package is archived, do not call its API from controllers, policies, or Blade views directly. Put a single class (e.g. App\Nova\NavigationVisibility) that reads your config/env and delegates to the package. When you migrate to a maintained alternative, only the adapter changes.

Config-driven, not hard-coded. Keep the enable/disable logic in a config file keyed by guard, role, or environment. This gives you a one-line kill switch in staging and local without touching code:

// config/nova-navigation.php
'hide' => env('NOVA_HIDE_NAV', false),
'except_roles' => ['admin'],

Per-request scoping. If the package toggles behaviour during Nova boot, prefer request-time callbacks (Nova::serving(...), Nova::available(...), or a small middleware) over boot-time Auth::user() checks. Nova boots before the authenticated user is reliably resolved in some flows — the toggle will silently no-op if you check too early.

Tool vs. card registration. If the package registers a Nova Tool, it goes in NovaServiceProvider::tools(); if it's a card, cards(). Register it conditionally so it doesn't appear in production menus you are trying to hide.

Pair hiding with authorization. Hiding navigation is cosmetic. For each resource you hide, also set authorizedToViewAny / policies so the endpoint is unreachable. Day-to-day this means your PR checklist has two items: "hidden from nav" and "blocked by policy".

Asset-layer integration. If the hide is implemented as a body class or injected CSS, publish the assets and target them from your own resources/css/nova.css. Compile once and let nova:publish copy it. Keep custom CSS separate so a future package swap does not lose your styling.

Testing. Add a plain HTTP test hitting /nova as each role and assert on the presence/absence of the nav markup (or the package's injected class). A feature test here catches almost every regression this package can cause.

Migration path. Document the adapter's contract in a docblock. The realistic alternative is either a maintained Nova package from the README or Nova's own menu customization (Nova::mainMenu(), Nova::userMenu() in Nova 4+), which removes the dependency entirely for most hide-nav use cases.

Gotchas and Tips

• No upstream support. With 2 stars and 0 dependents there is effectively no community to debug with. Budget time to read the source; it is small, and you now own it.
• Fork before you need to. Consider "repositories": [{"type": "path", "url": "packages/nova-hide-navigation"}] so you can patch Nova-compatibility issues without waiting on a release that will never come.
• Hiding is not securing. Direct URLs to resources still resolve unless policies block them. This is the most common production mistake with nav-hiding packages.
• Caches. config:cache, route:cache, and Nova's compiled assets all freeze the toggle. After any change run php artisan config:clear && php artisan nova:publish and hard-refresh the browser.
• Stale assets. "It's not hiding" is usually a stale public/vendor/... bundle. Check the network tab for the old asset hash before debugging PHP.
• SPA navigation. Nova is an Inertia/Vue app. If the package only adds a CSS class on the initial page, client-side navigation may re-render the nav. Test by clicking between resources, not just by loading a page.
• Guard/session timing. Toggling on Auth::user() during Nova boot can be too early — move the check into a serving/available callback or middleware.
• Environment leakage. A global "hide nav" flag left on in production is a support ticket. Gate it with app()->isProduction() sanity checks and log when the hidden mode is active.
• Debugging. Inspect the rendered HTML for the class/attribute the package injects; dd() inside the service provider to confirm registration; check storage/logs/laravel.log for provider resolution errors.
• Extension points to note before you archive the decision: published config, published views/assets, and service-provider bindings. Anything not on that list is private internals — don't build on it.
• Prefer native Nova menu customization for new work if your Nova version supports it; it is supported, cached correctly, and removes an unmaintained dependency from your composer.lock.