Nova Blog Laravel Package

Product Decisions This Supports

• Build vs. buy for content administration. The package ships Nova resources for articles, categories, and authors, plus rich text (WYSIWYG or Markdown), draft/scheduled publishing, SEO fields (slug, meta title, description), and featured image uploads. That is the exact 80% of an internal blog back office. The PM decision it unlocks is: do we spend 2–6 engineering weeks building CRUD screens, publishing state, and SEO plumbing inside Nova, or do we adopt and extend an existing plugin? For a team already on Laravel Nova, adopting is a credible default and frees that capacity for the differentiating work.
• Roadmap sequencing for content-led growth. If organic traffic, editorial cadence, or a content marketing motion is on the roadmap, the gating dependency is almost never the front end — it is whether editors can publish without an engineer. This package removes that dependency. It should therefore be scheduled ahead of the content launch milestone, not alongside it.
• Admin surface consolidation. Choosing to manage blog content inside the existing Nova admin panel rather than standing up a separate CMS is a product decision with real cost implications: one identity system, one deploy, one set of permissions, no second vendor contract or integration. This package is the artifact that makes that decision executable rather than aspirational.
• Accessibility and SEO as content-model requirements, not template fixes. The v1.3.1 release added alternative text for images on both Articles and Categories. Alt text is the minimum bar for WCAG 2.1 AA (1.1.1 Non-text Content) and a recurring blocker in public-sector tenders and enterprise procurement reviews. Because it lives on both entity types, the package supports a consistent image content model across the two main publishing surfaces — which is a signal toward buy-and-extend rather than fragmenting image handling across bespoke models.
• Localisation readiness. Alt text, meta titles, meta descriptions, and slugs are all translatable copy that now sits inside a structured content schema. If multi-market content is on the roadmap, having these fields in the core schema now avoids a later migration and re-authoring pass across existing articles.
• Upgrade and lifecycle risk as a tracked line item. Last release 2020-01-07, 5 GitHub stars. This is a low-adoption, effectively dormant package. The PM-relevant decision is not only "should we use it" but "what is our exit plan and how much of our admin surface becomes hostage to an unmaintained dependency." That should be recorded as an explicit risk with an owner, not absorbed silently by engineering.

When to Consider This Package

Adopt when:

• You are already running Laravel Nova. The package is an admin-panel plugin; without Nova it delivers nothing. This is the single hard gate.
• The content model is genuinely simple. One flat layer of articles, one layer of categories, named authors. If that matches the editorial reality, the package fits almost exactly and extension is cheap.
• Editors are the primary users and engineers are the bottleneck. The value proposition is "a marketer can publish a scheduled, SEO-tagged post with a featured image without a developer." That is measurable: count the engineering tickets currently spent on content changes.
• Accessibility compliance is a requirement. Public sector, regulated industries, EU/UK markets, or any customer with an accessibility clause. The alt text fields on Articles and Categories materially reduce your remediation surface, and they do it at the authoring layer where it is cheapest to fix.
• You can absorb routine dependency maintenance. Laravel and PHP version drift since 2020 is the practical concern. Budget a compatibility audit (PHP/Laravel version constraints, Nova major-version compatibility) before committing, and treat that audit as a cost of adoption.
• You have a named owner for the fork. Because upstream is quiet, plan for the realistic outcome that you vendor or fork the package. That is fine — it is a small, well-scoped plugin — but it must be a planned decision with an owner, not an accident discovered during an upgrade.

Look elsewhere when:

• You are not on Nova, or you are on a Nova version the package does not support. Do not adopt a dormant package as a reason to adopt a framework you were not already using.
• The content model is richer than Articles/Categories. Complex taxonomies, multi-step editorial approval chains, multi-tenant publishing, revisions and diffing, or a full editorial calendar. A dedicated headless CMS will serve you far better than extending this.
• Your front end is decoupled and already normalises media metadata in a DAM or media library. In that case alt text and image metadata belong in the DAM, and these fields risk becoming a second, divergent source of truth. Decide deliberately which system owns image metadata before adopting.
• You need a support contract or guaranteed maintenance. This package cannot offer that. If the blog is revenue-critical or compliance-critical, weigh the fork cost honestly — or pick a maintained alternative and accept the cost of building the missing pieces.
• Your deployment pipeline treats schema changes as high-ceremony events. Even additive migrations need coordination, and you will own them permanently once upstream stops.
• Scheduled publishing is load-bearing and untested by you. Verify the scheduling behaviour yourself in staging; a dormant package's edge cases are yours to find.

How to Pitch It (Stakeholders)

To executives: We need editors to publish blog content — with drafts, scheduling, SEO metadata, and images — without filing engineering tickets. This package provides that entire back office inside the admin panel we already run, so there is no new vendor, no new login, and no integration project. The alternative is building the same screens ourselves, which is weeks of engineering for a non-differentiating capability. The trade-off is maintenance risk: the package has seen no releases since January 2020, so we should treat it as code we will own and budget a compatibility check plus light ongoing upkeep. Recommendation: adopt behind a short technical spike, with a named owner and a documented fallback, and revisit if the blog becomes revenue-critical.

To engineering: This is a Nova plugin adding resources for articles, categories, and authors, with rich text, draft/scheduled publishing, SEO fields, and image uploads — including alt text on both Articles and Categories as of v1.3.1. Before we commit, I need four things back: (1) a compatibility audit against our PHP/Laravel/Nova versions, since the last release is 2020; (2) confirmation of what the package actually ships versus what we must implement — migrations, form validation, API resources, template rendering, fallback behaviour when alt text is absent; (3) whether our content model maps cleanly onto Articles/Categories/Authors or needs extension, and how expensive that extension is; (4) an honest estimate of fork-and-maintain cost, because that is the likely steady state. If the audit is unfavourable, say so early — I would rather build the narrow version than inherit a dead dependency.

To the wider business: We are choosing to satisfy accessibility and SEO requirements in the content model — at the point where editors write — rather than patching them in templates. Editors fix it once at the source; engineers do not fix it on every page. That is the cheaper and more durable option, and this package makes it available to us now. The caveat we are managing openly is that the package is small and quiet, so we are adopting it with our eyes open: a compatibility check up front, a named owner, and a clear exit if it stops serving us.