Getting Started

Reality check before you install: this package was last released in October 2018, targets the Laravel Nova 1.x era (Laravel 5.7 / PHP 7.1–7.2), and is archived. Treat it as a code generator you run once on a throwaway branch, not a long-lived dependency. Do not add it to a Nova 4/5 or Laravel 10+ project and expect it to resolve.

Minimal steps:

Spin up an isolated environment. Either a scratch Laravel 5.7 app or a Docker container pinned to php:7.2 with a matching laravel/nova version. Your production app is not the place to experiment.
Install on a branch:
```
composer require mattmangoni/nova-blogify-tool
```
If Composer reports a conflict against laravel/nova, stop — that is the package telling you the Nova API it was written against no longer exists.
Locate the service provider and what it publishes. Before wiring anything, run:
```
composer show -a mattmangoni/nova-blogify-tool
php artisan vendor:publish
```
The second command lists the provider class and publish tags. Use that output to publish config, migrations, and any views. The package is small enough to read end-to-end in ten minutes — do that first.
Register the tool the Nova way in app/Providers/NovaServiceProvider.php:
```
public function tools()
{
    return [
        new \Mattmangoni\NovaBlogifyTool\NovaBlogifyTool(),
    ];
}
```
Remember that a Nova tool (a menu entry with a custom Vue screen) is not the same as a Nova resource. The package does both — the tool is the scaffolding button, the resources are what it produces.
Run migrations, then open /nova and click through the tool's menu entry.

Where to look first, in order:

vendor/mattmangoni/nova-blogify-tool/src/ — the tool class, the artisan command (if any), and the stubs it copies.
src/stubs/ or resources/stubs/ — this is where the actual Post/Category models, migrations, and Nova resources come from. These stubs are the real deliverable.
config/ — post-install publishable config for table names, model namespaces, or route prefixes.

First use case: stand up a disposable admin for Posts + Categories in a sandbox app, generate the scaffold, then copy the generated files into your real project's app/ and database/migrations/ and delete the package. That is how you get value out of a 22-star archived scaffold: you take the code, not the dependency.

Implementation Patterns

Fork-then-forget (the recommended pattern). The one-click installer writes models, migrations, and Nova resources into your app. Once generated, those files are yours. Remove the package from composer.json immediately after, commit the generated output, and never re-run the installer. This avoids the "archived package breaks on Laravel upgrade" problem entirely.

Extending generated Nova resources instead of fighting them. The generated Post resource will have a fixed field set. Add fields in the resource's fields() method rather than in the package:

public function fields(Request $request)
{
    return [
        ID::make()->sortable(),
        Text::make('Title')->rules('required', 'max:255'),
        Slug::make('Slug')->from('Title')->creationRules('unique:posts,slug'),
        Markdown::make('Body'),
        BelongsTo::make('Category', 'category', Category::class)->nullable(),
        Boolean::make('Published'),
        DateTime::make('Published At')->hideFromIndex(),
    ];
}

Handle the public side yourself. This package gives you Nova admin CRUD only. There is no front-end routing, controller, or Blade view. Expect to write:

Route::get('/blog/{slug}', [PostController::class, 'show'])
A Post::published()->latest('published_at')->paginate() scope
Slug resolution with a 404 fallback and a redirect for renamed slugs

Add authorization via policies, not the tool. Nova respects Laravel policies. Add PostPolicy and CategoryPolicy with viewAny, create, update, delete methods. Nova authorizes against these automatically — this is your extension point for editor-vs-admin roles, and it survives any package weirdness.

Migration hygiene. Snapshot generated migrations into your repo with a fresh timestamp (2024_01_01_000000_create_posts_table.php) instead of leaving the vendor's 2018 dates. This keeps php artisan migrate history sane and prevents ordering surprises when you add your own foreign keys to posts.

Seeding for local dev. Write your own factories against the generated models; the package ships none. A PostFactory with states (published(), draft()) makes front-end work tolerable.

API surface, if you need it. The generated models are plain Eloquent, so Route::apiResource('posts', PostApiController::class) plus an ApiResource is a clean bolt-on. Use PostResource::collection(Post::published()->paginate()) and let Nova handle authoring.

Gotchas and Tips

The version-pin trap is the whole story. Last release 2018, zero dependents, archived. If composer require fails with a laravel/nova or illuminate/* constraint clash, that is not a fixable config quirk — the package references Nova 1.x internals (Laravel\Nova\Nova::script, the old tool registration API, Tool::boot) that no longer exist. Don't spend hours on --ignore-platform-reqs; you will get a white Nova screen or a Class not found.

Do not run the installer twice. Scaffolding commands that copy stubs typically overwrite without prompting. One second run can silently clobber customizations to the Post model. If you must re-run, git stash first.

Nova cache is a common red herring. After adding a tool or resource, if the menu entry doesn't appear: php artisan config:clear && php artisan cache:clear, then hard-refresh. Nova caches its compiled script and menu. Also run php artisan route:list | grep nova to confirm the tool's routes registered.

Menu visibility. To hide the tool from non-admins:

public function boot()
{
    Nova::tools([
        (new NovaBlogifyTool())->canSee(fn ($request) => $request->user()->isAdmin()),
    ]);
}

This is the safest way to keep a legacy scaffold button out of your editors' view.

Migrations roll back destructively. The down() generated for posts / categories will drop tables and their data. On any environment with real content, back up before migrate:rollback.

Namespace and table-name collisions. If your app already has App\Post or a posts table, the scaffold will collide. Publish to a different namespace (common config knob: blogify.models_namespace) or rename the generated classes to App\Models\Blog\Post before migrating.

Debugging the generated resources. Nova swallows field-level exceptions into a generic 500. Check storage/logs/laravel.log — the actual TypeError (usually a null BelongsTo or a missing $casts on a datetime) is there. Add ->nullable() and $dates / $casts on the generated model, which 2018-era stubs frequently omit.

Extension points that actually exist: published config, published migrations, generated models/resources (which you own after generation), and Nova policies. There is no pluggable driver or event system — don't look for one.

Final verdict for day-to-day use: don't depend on it. Read its stubs as a reference implementation of a Nova blog admin, copy what's useful (a Post resource with Slug, Markdown, BelongsTo Category is a 60-line file), and build on top of laravel/nova directly. The package's only durable asset is its scaffolding ideas, and those survive the package's archival just fine when they live in your repo.

Nova Blogify Tool Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips