Recent Posts Block Extension Laravel Package

Product Decisions This Supports

• Roadmap: page-composition strategy. This package only exists to serve PyroCMS's Blocks module — a region-based page builder where editors drop widgets into layout regions. Adopting it is an implicit bet that Blocks stays your content-assembly layer. If you're evaluating alternatives (headless CMS + front end, Filament/Inertia admin, Livewire page builders), this package is a data point on how far the platform's ecosystem actually goes.
• Build vs. buy (really: build vs. adopt). The scope is narrow — a block definition with a form schema (post count, ordering, maybe category filter) and a Blade view that queries the Posts module. That's typically under a day of work for a Laravel dev already inside the codebase. The honest framing is reference implementation, not dependency: it codifies the expected extension structure (service provider, block class, field definition, view path) so your team doesn't reverse-engineer the Blocks API.
• Feature decision: is "latest from the blog" launch-critical? For content marketing sites this is usually table-stakes on the homepage and article templates. Having a known-good implementation shifts the question from "can we do this?" to "do we want filtering, pagination, caching, and taxonomy controls?" — which this package likely does not provide.
• Platform risk assessment. Zero stars, zero dependents, no release signal. That's not a knock on the code (it may be fine), but it means you are the maintainer the moment you install it. Feed this into any "should we stay on PyroCMS?" review alongside the rest of the extension catalog.
• Scope negotiation with stakeholders. Because the widget looks trivial to request ("just show three recent posts"), it's a good forcing function to agree on a reusable block contract — field names, cache TTL, fallback behavior when no posts exist — rather than one-off template edits per page.

When to Consider This Package

Consider it when:

• You are already running PyroCMS (or the AnomalyLabs addon stack) with both the Posts and Blocks modules installed — this extension is useless standalone and has hard runtime dependencies on both.
• You need a recent-posts widget in a template region this sprint and want a working pattern to copy rather than read the Blocks module source.
• The site is internal, low-traffic, or a prototype where an unmaintained dependency carries acceptable risk.
• You want a baseline to fork and extend with your own filtering, caching, or editorial curation.

Look elsewhere when:

• You're on a modern Laravel app without PyroCMS — there is nothing here to reuse; build the equivalent with a query scope and a Blade component.
• You need pagination, category/tag filtering, per-request cache busting, scheduled publishing awareness, or localization. Assume you'll be writing that yourself.
• You require a supported dependency with a version compatibility matrix, security advisories, or an upgrade path. Empty star count and zero dependents mean no maintenance guarantee and no community-tested upgrade stories.
• Your Laravel/PHP version is newer than the package's last release. Verify the composer.json constraints and the Blocks API signature before committing — the failure mode is a fatal error at boot, and it will surface in staging, not in review.

Before adopting, verify: last commit date, composer.json version constraints against your PHP/Laravel, whether it registers via the Blocks extension contract your version expects, and whether the query respects post status/dates. Pin the version in composer.json and plan to vendor the code into your repo if it's unmaintained.

How to Pitch It (Stakeholders)

For executives: This is a small, pre-built widget that shows recent blog posts inside our page templates — the "Latest from the blog" strip on the homepage. It could save roughly one to two developer days versus writing it from scratch. The important caveat is that it has no active user base or maintenance signal, so we should treat it as a starting reference we own and can modify, not a vendor product we rely on. Recommendation: green-light it as a template only, budget a half-day of engineering review, and do not add it as a long-term dependency without pinning and forking.

For engineering: It's a PyroCMS Blocks extension that defines a block type rendering recent entries from the Posts module. Expect a block class, a field schema, and a Blade view — nothing architectural. Confirm compatibility with our PHP/Laravel and Blocks versions first; the package is unmaintained, so plan to vendor the code, pin the constraint, and add the caching and status/date filtering we actually need. Assume we own it after install.