Product Decisions This Supports
- Content model / field-type inventory: If your product runs on Streams Platform (PyroCMS), this package decides how editorial media is modeled — whether a stream entry carries one file, a gallery, or a polymorphic set of attachments. That is a schema decision, not a UI one, and it's hard to reverse after content exists.
- Buy vs. build for the media field: This is effectively a "buy" (adopt) candidate at near-zero cost versus 2–4 weeks of engineering to build an upload field type, relation logic, and admin UI on top of the
files module. The real cost is integration and fork maintenance, not license.
- Admin/editor UX roadmap: It gives content editors a first-class media picker inside the control panel instead of a raw file-ID text input. Useful signal for whether your next roadmap item is "media library v1" or "entry-level attachments only."
- Scope control on DAM ambitions: Adopting this keeps you in "attach files to entries" territory and explicitly out of digital asset management (folders, tags, renditions, rights). That's a useful forcing function to defer a DAM build until usage data justifies it.
- Vendor/fork strategy: With zero stars, zero dependents, and a 2022-08-08 last release, the realistic decision is "adopt with an internal fork" or "don't adopt." The package itself is a signal that the upstream ecosystem around this field type is dormant, which belongs in your platform-risk register.
- Migration sequencing: If you are evaluating a move off PyroCMS/Streams to plain Laravel or a headless CMS, this package's surface area defines how much of your content model is coupled to Streams. Count the entries using this field type before you commit to a migration estimate.
Treat the high opportunity score as headroom and low competition, not validation — a package nobody depends on is not a de-risked choice.
When to Consider This Package
Consider it when:
- You are already on Streams Platform / PyroCMS and need an entry-attached media field this sprint; the integration path is a composer require and a field-type assignment, not a design project.
- Your media needs are modest: upload, store, relate to an entry, render in a template. No renditions, no cropping UI at scale, no rights management.
- You have PHP/Laravel engineers who can read the field-type contract and vendor or fork the code without a learning curve.
- You are prototyping a content product and speed-to-editorial-workflow outranks long-term maintenance.
- You have (or will write) a fallback plan: the field type is thin enough that replacing it with a custom field type or Spatie's
laravel-medialibrary later is a contained migration, provided you keep the storage paths and metadata sane from day one.
Look elsewhere when:
- You are on modern Laravel (10/11/12) without Streams Platform — this package is meaningless outside that host framework.
- You need active maintenance, security patching, or vendor support. A 2022-08-08 release with 0 stars and 0 dependents means no upstream triage; you are the maintainer the day you install it.
- You need real DAM: transformations at the edge, CDN delivery, multi-tenant asset isolation, audit trails, accessibility metadata. That is a different product; buy it or build it deliberately.
- Your roadmap includes headless delivery to web + mobile + partner APIs, where media URLs and renditions need to be a stable contract rather than a CMS-internal relation.
- Compliance or retention requirements apply to uploaded assets — an unmaintained dependency in the upload path is a poor place to carry that risk.
Due diligence before adopting: pin the exact commit, read the upload validation and file-type handling yourself, confirm S3/filesystem behavior, verify PHP/Laravel version compatibility against your stack, and decide in writing whether you are forking. Budget the fork.
How to Pitch It (Stakeholders)
To executives: This is a small, free component that lets editors attach images and files to content inside our CMS instead of filing tickets to engineering. It buys us editorial velocity at effectively zero license cost. The trade-off is honest: the package is unmaintained — no releases since 2022, no community around it — so we should treat it as code we own, not a vendor product. Recommendation: adopt only if we're already on PyroCMS and accept a small internal maintenance line item; otherwise it's a distraction.
To engineering: It's a thin Streams Platform field type that wires an entry field to the existing files module — upload, relation, template rendering. Low complexity, low blast radius, and easy to fork if we need to fix upload validation or storage paths. No new runtime dependency of consequence, but also no upstream fixes: assume we patch it ourselves. Estimate half a day to spike, one to two days to harden and pin if we proceed.
To product/design: You get a working media picker in the admin now, with a deliberately narrow scope — attach and render, not manage. That keeps the media library and DAM conversation on the roadmap where it belongs, driven by usage data rather than by a build we do speculatively.
Decision requested: approve a timeboxed spike and a go/no-go against the alternative (custom field type or laravel-medialibrary), with the explicit understanding that "adopt" means "own."