Admin Generator Laravel Package

Getting Started

Install against the right stack, or don't start. This generator is not a standalone admin scaffold — it emits controllers, routes and Blade views that assume savannabits/craftable is already installed and booted (AdminLTE layout, base controller, auth scaffolding, asset pipeline). It targets Laravel 7 / PHP 7.2–7.4. If you're not on Craftable, stop here; the generated files will load but render without the admin chrome, and you'll spend the day debugging a layout that was never there.

Pin the install to a scratch branch first.

git checkout -b spike/admin-generator
composer require savannabits/admin-generator
php artisan vendor:publish --provider="Savannabits\AdminGenerator\AdminGeneratorServiceProvider"

Confirm the actual service provider class with composer show -a savannabits/admin-generator before trusting the FQCN above — the package predates reliably documented command auto-discovery, so verify rather than guess.

Discover the command surface directly. Don't infer command names from a blog post:

php artisan list | grep -i admin
php artisan help <the-command-you-found>

Read the published stubs before generating anything. The stubs/ directory is the real specification: it tells you exactly which field types, validation rule shapes and relationship forms the generator understands. That is more accurate than any README for a 2020-era package.

First use case: a flat reference table. Pick a Category, Tag or Country with 4–6 scalar columns and no relationships. Generate it, verify index/create/edit/destroy all work end to end in a browser, then move to a model with belongsTo. Relationship handling is where generators of this vintage fall over, and you want a proven baseline before you debug it.

Seed before you judge. Generated index tables look broken when empty. Ten to twenty realistic rows via factory + seeder is the fastest way to catch type mismatches — dates rendering as 0000-00-00, booleans as 0/1, long text blowing out the table width.

Implementation Patterns

Generate → commit → customize. This is the single most important habit. Run the generator on a clean tree and commit raw output as its own commit:

git commit -am "raw generator output: Category"

Every subsequent regeneration then produces a readable diff instead of an untraceable overwrite. Without this, you lose the ability to tell what the generator produced from what you authored.

Keep field definitions in source, not in shell history. Whatever you feed the generator — model docblocks, a config array, or interactive prompts — belongs in a committed file. Re-running the generator months later against a re-typed definition is how you silently drop custom validation rules.

Separate generated structure from authored behavior. The generator owns the skeleton; you own the logic. Practical split:

• Leave the generated controller and index/create/edit views largely intact.
• Push table-specific rules into form requests, model accessors/mutators, and small Blade partials included from the generated views.

That way, when a column is added you can regenerate-and-diff the view without clobbering your business logic.

Tighten validation in the same PR as generation. Generated rules are required|string|max:255-level only. Add immediately:

• Rule::unique(...)->ignore($model) on update
• exists: on foreign keys
• image|mimes: on uploads
• date_format: where the DB column is strict

This is routinely deferred and then forgotten.

Wire up the three things the generator won't. (1) A sidebar/menu entry — Craftable's nav is hand-edited config or views. (2) Permissions/roles — generated routes are typically unguarded, and Craftable's guard returns 403, not 404, when you forget. (3) Route registration — check whether it appends to routes/web.php or expects you to add the resource route yourself.

Relationship sequencing. For belongsTo, generate the parent CRUD first so the select-box data source exists, then confirm the generated form does a proper pluck/query rather than a raw numeric ID input. For belongsToMany, expect manual work — generated forms won't handle pivot sync, so add it in the controller:

$model->tags()->sync($request->input('tags', []));

Use it as a prototyping accelerator, not a foundation. The honest value proposition is 20 minutes to a working internal admin screen for a schema you're still validating. Once the schema stabilizes, the output is ordinary PHP — refactor toward your own conventions rather than fighting the generator to stay in sync.

Gotchas and Tips

Regeneration is the number one footgun. Generators in this family overwrite without merging. Always git status after re-running, and never regenerate a controller you've customized without diffing first. If a --force flag exists, assume the default is "skip existing" and the flag means "destroy my work."

Treat the package as effectively unmaintained. Last release 2020-05-15, zero dependents, Laravel 7 era. Consequences you will actually hit:

• It will not install on Laravel 9+ without constraint hacks.
• PHP 8.0+ may surface fatal errors from the underlying Craftable fork.
• No security patches, no upgrade path, no community backstop.

If you must use it, budget for vendoring or forking the package into your repo so you control the stubs. Do not start a new project on it.

Naming conventions drive everything — and irregulars break them. Route names, view paths, controller names and foreign-key guesses (category_id from Category) all derive from the model name. Multi-word and irregular plural models (BlogPost → blog_posts vs blogposts) are the classic breakage. After generating, grep the output for both the model name and table name to confirm consistency before opening a browser.

Clear caches before you debug anything. Stale route/view/config caches cause phantom bugs that look like generator failures:

php artisan route:clear && php artisan view:clear && php artisan config:clear

A generated route that 404s is almost always the route cache.

Debugging order when a generated screen 500s:

1. storage/logs/laravel.log — the trace names the generated file and line.
2. php artisan route:list — confirm the route exists and check its middleware.
3. Whether the Craftable base layout/asset exists — View [layouts.app] not found means Craftable isn't installed correctly, not that the generator failed.
4. Permissions — Craftable's guard will 403 rather than 404.

Never vendor:publish --force over an edited config. It silently reverts your customization. Copy published config into version control and diff by hand on any upgrade.

Extension points, in order of preference:

• Published stubs — customize field types and view structure at the source. If you find yourself post-processing output with sed on every generation, move that change into the stub instead.
• Config file — paths, namespace, route prefix.
• Generated files themselves — plain PHP, freely editable. The final fallback is always "edit it, it's yours now."

Don't misread the version scheme. The v7.0.0 note describes a policy where the package major tracks the Laravel major. Given the May 2020 release date, that refers to Laravel 7, not Laravel 12. Do not read ^7.0 as "works on Laravel 7 and later." Check the real constraints before installing anywhere that matters:

composer show -a savannabits/admin-generator   # inspect illuminate/* and php constraints