Laraveldash Laravel Package

Getting Started

Yaldash is a drop-in admin panel for Laravel. The 3.2.0 release adds configurable routes, which changes the first thing you should look at: config/yaldash.php is now the authoritative source for URLs, not the package's route file.

1. Check compatibility before installing: composer show -a yal/laraveldash and compare the illuminate/* constraints against your composer.json. Pin an exact version ("yal/laraveldash": "3.2.0") rather than a floating constraint — release cadence is irregular, so an unexpected minor bump mid-project is a real risk.
2. Install: composer require yal/laraveldash.
3. Publish config, assets, and migrations:

   php artisan vendor:publish --provider="Yal\LaravelDash\LaravelDashServiceProvider"
   

4. Open config/yaldash.php and set the route group explicitly — prefix, middleware, domain, and route names are now configurable here. Do this before writing any custom admin routes so you know the namespace you're working in.
5. Run the package's installer/seed command to create the admin user and default roles/menus. Confirm the exact name with php artisan list | grep -i yaldash.
6. php artisan migrate and php artisan storage:link (the panel expects uploaded media to be publicly reachable).
7. Verify what actually registered: php artisan route:list --path=<your-configured-prefix>. Log in at that prefix with the seeded admin account.

Where to look first, in order: config/yaldash.php (route customization, prefix, middleware, auth guard, menu), the package's routes file (to see the defaults your config is overriding), published resources/views/vendor/yaldash (the layout you'll extend), and the migrations (to confirm your existing users table won't collide).

First real use case: pick one existing Eloquent model (e.g. Post) and put a CRUD screen on it via the package's resource/CRUD mechanism. That exercises auth, routing, the layout, and the form builder in one pass and tells you quickly whether the panel fits your domain.

Implementation Patterns

Route customization is the new first-class extension point. Define the admin prefix, middleware stack, and route group in config/yaldash.php rather than registering competing routes or editing vendor files. This is now the safest way to avoid prefix collisions with your application's own routes, and it means a single config change can move the whole panel behind a different guard or domain.

CRUD over existing models. Register your model as an admin resource (via config or the package's generator command — the repo documents both). Keep the resource thin: columns, form fields, validation rules, and a query() hook that applies tenant scopes and eager loads. Don't put business logic in the resource definition.

Custom admin pages. With 3.2.0, prefer declaring your extra admin routes inside the package's configured route group (in config where supported, otherwise in routes/web.php wrapped in the same prefix/middleware values pulled from config) over extending the vendor routes file. Pull the prefix and middleware from config('yaldash...') so your routes move with the panel when the config changes.

Sidebar/menu integration. Register entries in config/yaldash.php rather than editing the Blade sidebar. Config-defined menus are the intended extension point and are far less brittle than template overrides.

Authorization. Wrap admin routes in the package middleware plus your own can: gates. Treat the panel's built-in role check as a coarse filter (is this user an admin at all?) and enforce per-model permissions with Laravel policies in the controllers. This keeps you honest if the panel's auth model turns out to be a simple boolean flag.

View overrides. Publish views, then override only the specific files you need under resources/views/vendor/yaldash/.... For lighter touches, use view()->prependNamespace('yaldash', resource_path('views/admin')) to inject your own partials without copying the whole tree.

Media/uploads. Point the package config at a named disk in config/filesystems.php (usually public), and store the disk name in config rather than hard-coding. If you need S3 or private storage, verify the package actually reads the configured disk before assuming it does.

Bounded admin surface. Admin controllers should be thin adapters that call your application's existing actions/services. If yaldash is ever replaced (Filament, Nova, Backpack), you delete the adapters and keep the domain code. Given the irregular release history, this remains the main reason to structure it this way — not optional advice.

Deployment. Publish assets at build time, run php artisan optimize and view:cache in CI, and make sure storage/app/public is linked. Treat published assets as first-party files you own and commit them.

Gotchas and Tips

• Route config changes are not hot-reloaded. After editing the route settings in config/yaldash.php, run php artisan config:clear (and route:clear if you cache routes). A stale cached config is the most likely reason a prefix change "did nothing."
• Upgrading to 3.2.0. It's a minor release, but route registration semantics changed enough that a cached config or a hard-coded /yaldash in your own links will break silently. Grep your app and tests for the old prefix and route names, and re-run php artisan route:list to diff before and after.
• Route shadowing is now solvable, not just avoidable. Previously the fix was ordering your routes after the package provider. Now set a distinct prefix or middleware group in config. Do that rather than relying on registration order.
• Migration collisions. The package assumes it owns the users table and related tables. Review published migrations with php artisan migrate --pretend before running against an existing schema, and edit the published files (they're yours now) rather than the vendor copies.
• Cached views mask overrides. After publishing or editing views, php artisan view:clear is almost always the fix when your override "isn't taking."
• Verify the admin check. Read the middleware before trusting it. Older panels sometimes gate on a boolean column or a hard-coded role name; confirm what it actually checks and layer policies on top.
• Debugging route registration: php artisan route:list --path=<prefix> -v shows exactly what got registered and under which middleware. With configurable routes, always confirm the effective values come from your published config and not the package default.
• Maintenance signals. A single minor release after a long quiet period is not a support commitment. Read the changelog and issue tracker before assuming further fixes; keep the version pinned and be ready to fork.
• Safe extension points, in order of safety: config/yaldash.php (now including routes) → view namespace overrides → published views → published assets → (never) editing vendor/.
• Upgrade path: still thin. If you need this UI long-term, budget for a fork or use the panel as a design reference and rebuild the screens in a maintained package. The screens are simple CRUD; porting them is usually cheaper than maintaining an intermittently-maintained admin layer.