Nova Blog Tool Laravel Package

Getting Started

1. Install it into an existing Nova app (it assumes laravel/nova is already installed and licensed):

   composer require digitalcloud/nova-blog-tool
   

2. Register the tool in app/Providers/NovaServiceProvider.php. Nova tools are not auto-discovered, so look for the tool class in the package namespace (typically DigitalCloud\BlogTool\BlogTool or similar — open vendor/digitalcloud/nova-blog-tool/src and check the ToolServiceProvider first, since this repo is small and likely unmaintained and the exact namespace may differ from the README):

   public function tools()
   {
       return [
           new \DigitalCloud\BlogTool\BlogTool,
       ];
   }
   

3. Publish and run migrations. This is the step to check first — open the package's src folder and confirm whether migrations/models ship inside the package or are expected to be published. Typical:

   php artisan vendor:publish --provider="DigitalCloud\BlogTool\BlogToolServiceProvider" --tag=migrations
   php artisan migrate
   

   Also check for a --tag=config publish; if a config file exists, skim it before touching anything else.

4. Locate the resource in Nova's sidebar. After registration you should see a Blog/Posts entry. That resource is the package's UI — the underlying Eloquent models are what you'll build the frontend against.

5. First use case: create one post through the Nova UI end-to-end (title → slug → body → publish), then query it from tinker to confirm the table/column names and model class before writing any frontend code. The column naming is the real contract you'll depend on.

Given the low star count and stale score, treat step 3 as a go/no-go gate: if migrations don't match your Laravel version or the models aren't discoverable, stop and evaluate alternatives before building on it.

Implementation Patterns

• Separate admin from delivery. The package gives you Nova CRUD; it does not give you a frontend. Expose posts via your own controller or API resource using the package's Eloquent models (import them, don't re-declare). This keeps you free to swap the admin package later without touching routes.
• Wrap the models, don't fork them. Extend or alias the package model in your app (e.g. a Post that extends the vendor one) if you need scopes, accessors, or relationships to your own entities. Overriding behavior in your app layer survives composer update; editing vendor/ does not.
• Slug/route integration. Point your route model binding at {post:slug} and add a getRouteKeyName() override in your wrapper class rather than relying on whatever the package chose.
• Publishing workflow. If the package has status/published_at columns, add a query scope in your app (e.g. published()) and use it consistently in controllers, sitemaps, and feeds. Do not scatter where('status', ...) across the codebase — the enum value names are the package's to change.
• Editor/media handling. Blog tools frequently assume an editor field or file uploads on Nova's default disk. Before relying on images, check the package's disk config and set it to public/your CDN disk explicitly; uploads tied to a hardcoded disk are a common source of broken production images.
• Seed and test. Write a factory for the package model early so feature tests and local seeding don't depend on clicking through Nova. Because the package likely ships no tests, your own factory + one feature test is your regression safety net.
• Asset publishing for the Nova UI. If the tool has JS/CSS (check dist/), run php artisan vendor:publish --tag=nova-blog-tool-assets or nova:publish as the README dictates, and commit published assets if your deploy doesn't rebuild them.

Gotchas and Tips

• Nova version compatibility is the biggest risk. Nova changes its tool/resource APIs between majors (v4 → v5 in particular). A 20-star package with a low score is unlikely to be tracking the latest Nova. Pin Nova and this package together in composer.json, and read the repo's composer.json constraints for laravel/nova before installing.
• Abandonment. Assume no upstream fixes. Budget for vendoring the source (copy into app/ or a private path repository) if you ship it to production — that removes the "install breaks" failure mode entirely.
• Missing migrations / wrong table names. If vendor:publish lists no tags, inspect ToolServiceProvider::$publishes directly. Some small packages expect you to create tables yourself — check for a database/ folder.
• Config cache. After changing the package config, run php artisan config:clear; Nova tools silently mis-register under a stale config cache.
• Tool not appearing in sidebar. Confirm the class is in tools(), the provider is registered (Nova auto-discovers service providers via extra.laravel.providers — verify it's there), then php artisan optimize:clear. A 500 on the Nova dashboard usually means a missing asset publish or a mismatched Nova version.
• Slug collisions. If the package doesn't uniquify slugs, add that in your wrapper model's booted() hook (creating/updating), otherwise the first duplicate insert throws and you'll be debugging Nova's error toast instead of your code.
• Mass-assignment / guarded. Check $fillable on the package model; if the editor field isn't fillable, saving from a custom form silently drops content with no error.
• Extension points to prefer: config file (disk, per-page, route prefix) → wrapper models → published views → modifying vendor (last resort, never). If none of these cover your need, that's your signal to replace the package rather than patch it.
• Debugging tip: because there's little documentation and few users, dd() on the Nova resource's fields() method is faster than searching GitHub issues. The resource class is the spec.