Media Bundle Laravel Package

Product Decisions This Supports

• Buy vs. build vs. adopt for media handling. This bundle is a candidate only for legacy Sylius storefronts needing product image galleries, thumbnails, and channel-specific media variants. The evidence — 0 stars, 0 dependents, last release 2016-05-24 — makes the useful output a "do not adopt" decision, which closes an option and narrows the shortlist.
• Stack-fit correction before feature scoping. Despite the "Laravel/PHP" framing, this is a Symfony/Sylius bundle (dos-media-bundle), not a Laravel package. If the roadmap is Laravel-based, strike it from the shortlist without a technical spike — no engineering time required.
• Upgrade-path costing. The bundle targets a roughly 2016 Sylius generation. For any team on Sylius 1.7+ (or PHP 8.x), adoption means forking and modernizing — current Sylius APIs, PSR compliance, dependency graph. That reframes "free bundle" as a multi-day to multi-week engineering cost.
• Reference design, not dependency. If we build an in-house media module, its structure (model interfaces, mapped superclasses, upload listeners) is worth skimming as prior art — read-only, never vendored.
• Risk register input. Zero maintainers, zero dependents, ~9 years without a release, and no advisory coverage. That belongs in the supply-chain risk section of the architecture review, and it touches file upload — the highest-risk surface for traversal and unrestricted-upload classes of vulnerability.
• Sprint planning input. Reading the codebase is roughly one engineer-day (small, no docs, no tests). Migration effort is dominated by data backfill and call-site rewrites, not comprehension — budget accordingly, not for "understanding the library."

When to Consider This Package

Consider (narrowly):

• You maintain a legacy Sylius 0.x/1.0 application pinned to that era and need to read or unwind an existing installation. Here it is maintenance archaeology, not adoption.
• You want architectural reference material for how a media bundle was structured — as reading, not as a dependency.
• Do not integrate into any Laravel application. There is no realistic path without a rewrite; the bundle uses Symfony's Kernel::registerBundles(), compiler passes, XML/YAML service definitions, and Doctrine mappings — none of which map onto Laravel's provider/container model.

Look elsewhere (default):

• Modern Sylius — use Sylius core media handling plus LiipImagineBundle for thumbnails/filters and supported Flysystem integration for storage. Maintained, documented, actively used.
• Laravel — use spatie/laravel-medialibrary (model-attached media, conversions, multi-disk storage), Laravel Filesystem + Flysystem for S3/GCS and signed URLs, and intervention/image for queued derivative generation. This bundle offers nothing here.
• Any requirement involving active maintenance, security patching, PHP 8+, or vendor support — disqualifying.
• Any situation where you'd be dependents #1 through #N on an abandoned library — that is a permanent internal support burden.
• If it is already in a codebase — classify as technical debt with a removal ticket, sequenced ahead of any framework upgrade so the upgrade is not blocked by an unresolvable package.

Questions to resolve before deciding: Is the requirement Laravel uploads or legacy Sylius maintenance? Is this already in production (inherited) or under fresh evaluation? Which Sylius/Symfony/PHP versions are pinned in the lockfile? What does the license permit, and is there a maintained fork? Do we need the schema/storage layout for data migration even if we replace the runtime?

How to Pitch It (Stakeholders)

Executives: We evaluated liverbool/media-bundle for product media management and recommend against it. It has zero adoption (0 stars, 0 dependents) and no release since May 2016 — roughly nine years dormant. Adopting it means owning 100% of maintenance and security for code nobody is watching, on the highest-risk surface we run (file upload and public serving). It is also the wrong ecosystem: it is a Symfony/Sylius bundle, not Laravel, so it does not fit our stack at all. We recommend maintained alternatives — Spatie Media Library on Laravel, or Sylius core plus LiipImagine on Sylius. The cost is a short integration spike (estimate one to two days to confirm parity on galleries, per-channel variants, and CDN offload) rather than an open-ended fork.

Engineering: Confirm stack fit first — this is a Sylius bundle, not Laravel. If Sylius, core media plus LiipImagine and Flysystem cover the same ground with active maintenance and current PHP support. Do not vendor or fork; the modernization effort (PHP 8, current Symfony/Sylius APIs, dependency graph, Doctrine mappings, removed container APIs) likely exceeds writing the feature fresh. Assume compatibility failure until proven otherwise — composer require liverbool/media-bundle --dry-run against target constraints is the cheap test; if it fails, that is the expected outcome, stop there. If an instance is inherited, sequence it as audit → contain/pin the exact commit → abstract behind an internal media interface (store, retrieve, delete, url) → replace the implementation → dual-write and backfill with checksum verification → remove the dependency and its stale transitive packages.