Post Categories Block Extension Laravel Package

Product Decisions This Supports

• Feature scoping for content sites: Gives editors a drop-in "category list" widget for blog sidebars, category landing pages, and related-content modules — a recurring request on content-heavy builds that would otherwise become a small engineering ticket.
• Build vs. buy (vs. skip): The build cost is genuinely low (a block type + a view template, roughly half a day), so the real question isn't "buy vs. build" but "adopt a dependency vs. own ~100 lines of view code." This package only wins if your team already speaks Streams block conventions.
• Platform-level roadmap decision: Because this is a satellite repo in the Anomaly Labs / PyroCMS ecosystem (0 stars, 0 dependents, no visible support path), pulling it in is a data point for the larger question of whether to keep investing in PyroCMS/Streams or plan a migration. Track it as a line item in platform-risk, not as a feature.
• Taxonomy as navigation: Forces an explicit product decision about whether Posts categories are a first-class navigation surface or just metadata. If categories drive navigation, you likely need counts, hierarchy, and active-state highlighting — which this block does not appear to provide.
• Backlog hygiene / editor autonomy: If it works, non-technical editors can place and configure the category list themselves, removing a class of low-value requests from the engineering queue. That's the main non-technical ROI.
• Upgrade exposure budgeting: Pinning an unmaintained extension is a signal to budget fork-and-own time at the next platform upgrade rather than assuming upstream fixes will arrive.

When to Consider This Package

Consider it when:

• You are already running PyroCMS 3.x / the Streams Platform with the posts module installed and its categories feature enabled — this is not a general-purpose Laravel package.
• You need a plain category listing rendered inside a page layout, and your team is comfortable with Streams addon/block conventions.
• Posts categories are the taxonomy of record (not a custom stream, not an external taxonomy service).
• You need something this sprint and can accept an unmaintained dependency, ideally by vendoring/forking it into your own repo.

Look elsewhere when:

• You are on a Laravel app that isn't PyroCMS/Streams — adopt nothing here; write a Blade component.
• You need behavior beyond link rendering: hierarchical/multi-level menus, post counts, active-state highlighting, filtering or search. The block is scoped to "display categories," and that scope is narrow.
• Your category data lives outside the Posts module (custom streams, commerce taxonomies, a CMS you're migrating off).
• You require a maintained dependency with a support contract, security-response path, or documented compatibility matrix. There is no visible release/compat signal here.
• You are on a newer PyroCMS/Streams major than the repo targets — treat compatibility as unverified until you test it.
• Your theme already has a category partial: owning the markup is cheaper than owning a third-party dependency for equivalent output.

How to Pitch It (Stakeholders)

Executives (one paragraph): A small, free add-on that lets marketing put a category menu on the blog without consuming engineering time. It's a tactic, not a strategy — it removes a minor build task from the roadmap, worth roughly a day of effort. The decision that actually matters is platform direction: this dependency is a single-maintainer satellite repo in the Anomaly Labs ecosystem with no community adoption and no support path, so it should be adopted only as vendored code we control, and it should factor into our broader PyroCMS/Streams consolidation or exit plan.

Engineering (one paragraph): It registers a Streams block type that renders categories from the posts module via the standard block addon interface. Integration cost is low if we're already on PyroCMS 3.x with Posts categories enabled; otherwise it has no value. Risk is maintenance, not code complexity: 0 stars, 0 dependents, no observable release cadence — so fork it into our repo, pin the commit, and cover the render output with a test so a future platform upgrade fails loudly instead of silently. If we're not already on Streams, don't adopt the platform for this; a Blade partial is cheaper, fully owned, and does the same thing.