Featured Posts Block Extension Laravel Package

Product Decisions This Supports

• Content merchandising on the homepage (or any page with blocks): this package answers a narrow but recurring product question — "how do editors hand-pick a set of posts and surface them in a block without a developer?" It backs the decision to ship an editorial curation surface rather than an algorithmic feed.
• Build vs. buy for a "Featured posts" widget: if you're already on PyroCMS 3.x with the Posts module, this is a ~zero-cost build-vs-buy decision. A custom block would be a few hours of work, but this removes it from the backlog entirely.
• Roadmap sequencing for CMS-driven marketing pages: blocks like this are the unit of page composition in Anomaly's block system. Adopting it establishes a pattern (block per editorial slot) you can replicate for "Latest news," "Editor's picks," "Related posts" — useful when deciding whether to invest in a block library or a page-builder replacement.
• Scope boundary for the content team: it clarifies that selection of featured content stays in the CMS admin, not in a spreadsheet or hardcoded template — a governance decision more than a technical one.
• Not a decision it supports: analytics, personalization, ranking, A/B testing, or performance of the feed. This is a static curated list, not a recommendation engine.

When to Consider This Package

Consider it when all of the following hold:

• You are running PyroCMS 3.x (Anomaly Labs) and the Posts module is installed and is the source of truth for article content.
• You need a manually curated set of posts rendered in a page region — no ranking logic, no per-user variation.
• You are comfortable with the Anomaly block/addon model and Composer-based extension installs.
• The risk tolerance for a low-signal dependency is acceptable: no stars recorded, a score of 0, and 0 dependents on the package graph. Treat it as unmaintained-until-proven-otherwise; pin the version, fork it into your VCS if it's load-bearing, and budget for owning it.

Look elsewhere when:

• You're not on PyroCMS. This has no value outside the Anomaly block runtime; it is not a general Laravel package.
• You need dynamic or personalized featured content — build the query yourself against your own models.
• You're evaluating a CMS migration or greenfield build. The zero-star / zero-dependent profile is a signal that the ecosystem around this addon is thin; factor that into any decision to standardize on PyroCMS blocks at all.
• You need active maintenance, security response, or vendor support. There is no evidence of any of these; assume you are the maintainer.
• The Posts module isn't your content source (e.g., headless CMS, external API) — you'd be fighting the abstraction.

How to Pitch It (Stakeholders)

To executives: This is a small, free addon that lets editors choose which posts appear in a "Featured" section of the site without engineering involvement. The decision is low-stakes: it fills a specific editorial gap, costs nothing to acquire, and takes very little engineering time to wire up. The caveat is that it's an unmaintained community component with no visible adoption, so we should treat it as code we own — a one-time, small effort with an ongoing trickle of maintenance rather than a supported product. Frame the recommendation as "cheap to adopt, cheap to replace," not as a platform commitment.

To engineering: It's a PyroCMS block extension — a presentation-layer addon that reads from the Posts module and renders a curated list. No schema changes, no new services, no runtime dependencies beyond what the CMS already loads. Risks: zero dependents and no star activity mean we should vendor/fork it, pin it, and add a smoke test around the block render. Estimated integration effort is hours, not days. If it proves brittle, replacing it with an in-house block is a similarly small piece of work — so the downside is bounded.

Bottom line for the go/no-go meeting: Adopt only if PyroCMS + Posts is already a committed part of the stack. Otherwise, note it as context for a broader question — whether the Anomaly block ecosystem is where we want our editorial surface to live.