Laravel Navigation Laravel Package

Getting Started

1. Install the package and publish its config:

   composer require fuelviews/laravel-navigation
   php artisan vendor:publish --tag=navigation-config
   

2. Open config/navigation.php first — this is the primary surface area. It holds navigation/menu definitions, route wiring, branding options (logo shape), and contact defaults (phone number).
3. Clear caches after any config edit, since Laravel caches config in production:

   php artisan config:clear
   

4. First use case: define your primary menu items in config, then render them in your layout via the package's Blade component/view. Verify the generated links resolve to the expected named routes before styling.

Implementation Patterns

• Config-driven menus over hardcoded markup. Keep nav structure in config/navigation.php (or a dedicated menu config) and render through the package's Blade layer. This keeps route changes in one place instead of scattered across templates.
• Route-name references, not URLs. Define items by route name where possible. v2.0.5 corrected navigation routes, so hardcoded paths may now be stale — named routes insulate you from that.
• Branding as config. Logo shape and default phone number are config values; override them per environment (config/navigation.php in config/ wins over the package default). Avoid editing vendor files.
• Layout integration. Render the navigation once in your base layout and pass contextual data (current route, user state) from a view composer or the layout itself rather than per-page.
• Environment overrides. Set NAVIGATION_PHONE (or the equivalent config key) in .env for the contact number so staging/production differ without code changes.
• Testing. Assert rendered nav output in a feature test: hit a page and check that expected route URLs and labels appear. This catches route-name drift early.

Gotchas and Tips

• v2.0.5 changed default config values. The default phone number was updated and navigation routes were corrected. If you published the config previously, your copy will not auto-update — diff your published config against the package's to pick up route fixes deliberately.
• Published config drift is the most common pitfall. Track the package version and re-diff config/navigation.php after minor releases; silent route corrections won't reach you otherwise.
• Logo shape comments changed. If you were relying on undocumented behavior around logo shape, re-read the updated config comments and README; the clarification may reveal your value was mis-set.
• Cache blindness. Route and config caching hide changes. When a nav link looks wrong after an update, run php artisan route:clear && php artisan config:clear before debugging.
• Dependency bumps are internal. The CI/tooling bumps in this release (checkout, tag action, PR-description action) don't affect runtime; don't chase them during upgrade.
• Extension point: prefer overriding config and Blade views (re-publish views if supported) over subclassing internals. If you need dynamic menus per user/role, build a thin service that merges runtime items into the config-defined base rather than forking the package.