Podcast Categories Laravel Package

Technical Evaluation

What this package is. statamic/podcast-categories is a Statamic addon, not a generic Laravel library. It bundles Apple’s podcast category taxonomy and exposes it as a blueprint fieldtype so editors can assign canonical category/subcategory values that flow into RSS feeds. The integration surface is the Statamic CMS, not an independent PHP service.

Architecture fit. Two binary conditions determine fit:

• Host platform: v2.0.0 is explicitly a Statamic 6 compatibility release. It is only adoptable at v2 if the site is on Statamic 6 or committed to migrating this cycle. On Statamic 4/5 the v2 line does not apply; the v1 line is effectively an unmaintained branch.
• Product relevance: the addon earns its place only on a Statamic site that publishes a podcast RSS feed and needs Apple‑compliant category values. On any other Statamic site it is dead weight — a dependency, a security surface, and an upgrade obligation for zero capability.

Integration feasibility. Mechanically trivial: Composer install, addon autoregistration, add the field to one or more blueprints, optionally republish config. There is no external API, no credentials, no queue, no storage concern. Realistic effort is a few hours of engineering plus an editorial pass, not a project.

Technical risk — the adoption signal matters. The release note is one line (“Updated for Statamic 6”), and the package metadata carries the stronger signal: 1 star, 0 dependents, no published upgrade guide, no visible test suite. For a TPM the consequence is not that the package is dangerous — its blast radius is small — but that there is no external validation to borrow. We would be the only known consumer of the v2 line. That is an asymmetric position: we absorb the review cost and the maintainer gets the bug reports.

Build versus buy is the real decision. The durable asset is a static, publicly documented taxonomy — the Apple category list. The code around it is a thin fieldtype wrapper. “Buy” is justified only if the maintainer’s ongoing curation of that list is worth more to us than roughly a day of engineering to vendor the list ourselves and register a repository‑owned select field. For most teams, copying the taxonomy into repository‑owned config removes the dependency entirely and makes the next Statamic major a non‑event. This is the highest‑leverage TPM decision in the assessment.

Key questions to close before committing.

• Are we on Statamic 6, and is the podcast feed on a revenue‑ or brand‑critical path?
• Does the v2 field data shape match what v1 wrote, and is there a migration or reindex step? No guide is published — assume none exists and verify by diff.
• What are the exact composer.json constraints for Statamic, Laravel, and PHP in v2.0.0 versus v1.x, and do any sibling addons pin Statamic 5 and deadlock resolution?
• Is there a test suite or CI matrix? If not, we own correctness verification.
• Who maintains it, what is the release cadence, and what is the bus factor?
• Do we need the dependency at all, or should we vendor the category list?

Integration Approach

Stack fit classification — do this first.

• (a) Statamic 6 site launching or maintaining a podcast feed: the addon fits, with the build‑versus‑vendor caveat above.
• (b) Statamic 5 site: v2.0.0 does not apply. Defer adoption entirely or adopt the latest v1 and log the end‑of‑support date.
• (c) Plain Laravel / non‑Statamic stack: not applicable. Exclude from the evaluation set.

Migration path — existing consumer (v1 → v2).

1. Pin the currently installed version explicitly before any experimentation; do not leave an implicit constraint floating while a major is in flight.
2. Diff composer.json between the installed v1 tag and v2.0.0. The constraint delta is the plan.
3. Run composer why-not statamic/podcast-categories 2.0.0 in a scratch branch to surface blocker addons before writing code — the cheapest possible failure.
4. Diff the package source for renamed config keys, changed field config options, and changed stored value format; grep our own blueprints and any templates that render the category.
5. Sequence strictly: platform major first (Statamic 6 + Laravel + PHP), verified in staging; then this addon; then feature validation; then production. Never upgrade host and addon in the same commit — a break with two possible causes costs more than the sequencing saves.
6. Validate against a staging clone of real content, not a fresh install. Fieldtype and taxonomy addons fail on legacy entry data far more often than on empty databases. Take a restorable backup and dry‑run before touching live content.

Adoption path — new consumer. Timebox a spike: scratch Statamic 6 instance, install, build one blueprint with the field, create entries, render the feed, confirm category values match Apple’s published list. Under a day. Adopt only if the spike is clean and the build‑versus‑vendor case favours buy — otherwise vendor the list and skip the dependency.

Compatibility and sequencing. Enumerate the matrix explicitly before committing: Statamic version, Laravel version, PHP version, and every sibling addon sharing the Statamic constraint. In practice the binding constraint is usually a different addon, not this one; if Statamic 6 support across our addon set is incomplete, we are blocked on the ecosystem and the correct action is to wait on a 6.x point release rather than lead the migration with a one‑star package.

Content migration note. Category values live in entry data. If v2 changes the stored shape, existing entries may render blank categories into the RSS feed — a silent, brand‑visible defect. Budget a scripted audit of existing entries’ category values as part of the upgrade, not as a post‑launch fix.

Operational Impact

Maintenance. Low in absolute terms, but not zero, and the cost is scheduling, not engineering. Every future Statamic major (7, 8) reopens the question and, given this project’s history, may reopen it on the maintainer’s timetable rather than ours. The realistic posture: pin the version, add the package to the pre‑upgrade dependency checklist, and review at each platform major. If we vendor the taxonomy ourselves, this line item disappears entirely — the strongest operational argument for build‑over‑buy here.

Support. Effectively self‑support. There is no commercial backing, no published upgrade guide, no visible test suite, and a one‑line changelog. Assume first‑line support for any upgrade problem is us. Document our own upgrade notes at the first migration; they will be the only documentation that exists when the next platform major lands. If the field is on a launch‑critical path, wrap it behind our own field configuration so a swap is a config change rather than a content migration.

Scaling. Negligible throughput risk. The taxonomy is a static list resolved at render or panel‑load time; there is no external call, no per‑request query pattern of concern, and no queue or storage footprint. Watch only for: (i) page‑cache correctness if the category is rendered into cached feed output — confirm invalidation is wired into Statamic’s static caching; (ii) panel payload on very large entry listings if the field resolves options per row. Neither is likely to be material at realistic podcast‑catalogue volumes.

Failure modes, ranked by likelihood × blast radius.

• Composer resolution deadlock — high likelihood, blocks all work, no runtime impact. Mitigate by resolving constraints before any code is written.
• Silent config or value‑shape change — medium likelihood, high blast radius; presents as blank or wrong categories in the RSS feed, which is externally visible. Mitigate with a staging clone of real content, a scripted entry audit, and feed validation against Apple’s current list.
• Maintainer abandonment or stalled v3 — medium likelihood over a 12–24 month horizon; low immediate blast radius because the package is small. Mitigate by vendoring the taxonomy or wrapping the field behind our own config so a replacement is a config change.
• Security vulnerability in the addon — low likelihood; small attack surface with no external calls. Treat as a standard dependency: track releases, review source before upgrading.

Ramp‑up. Trivial for developers familiar with Statamic. Editors need a short guide on selecting the correct category/subcategory and understanding that the list is Apple‑specific. Because documentation is minimal, write a one‑page internal runbook covering installation, blueprint configuration, feed rendering, and the upgrade checklist. Time to productivity: hours for engineering, minutes for editorial once the field is in place.