Media Bundle Laravel Package

Product Decisions This Supports

Build-vs-buy for media handling — with a "no" as the default answer. This bundle's value proposition (upload via Symfony forms, image variations via Imagine, media documents stored in PHPCR-ODM and referenced from CMS content) is a solved problem in 2024 with commodity pieces: Flysystem or Laravel's filesystem for storage, Intervention Image / Glide / a CDN transform service for variations, and your existing relational or document store for asset metadata. The buy decision only pencils out if you are already running PHPCR-ODM.

Legacy CMS estate triage. If the org owns a Symfony CMF 1.x application, this is the media layer that app already depends on. That makes it a maintenance-cost input — fork-and-vendor, freeze, or migrate — rather than a greenfield technology choice.

Architecture decision: PHPCR-ODM, not "do we need a media bundle." PHPCR content repositories (Jackalope, Doctrine PHPCR-ODM) buy you a hierarchical content tree, workspace-level versioning, and reference integrity between content and assets. That is the actual product decision. If the roadmap doesn't require versioned, tree-structured content, PHPCR is a tax you should not pay, and this bundle goes with it.

Roadmap scoping on image variation requirements. The variation/thumbnail model is the one genuinely reusable idea here — "define named renditions once, request them by name from templates." That belongs in your media spec regardless of which library implements it. Copy the concept, not the code.

A correction that changes the decision: a prior internal note on this package frames it as a Laravel dependency and discusses composer require, config/app.php service providers, facades, and php artisan tinker. That note is wrong. Symfony bundles require the Symfony kernel and DI container; Laravel consumes Symfony components (HttpFoundation, Console, Finder) under a different contract. There is no integration path here, and the Symfony 3.0 compatibility in release 1.3.1 refers to Laravel 5.2/5.3 only in the sense that both happened to ship Symfony 3.0 components in 2016. Treat the Laravel angle as a documented false positive so it doesn't resurface in the next package review.

Risk register entry. 30 stars, archived, last release 2016-06-14. This is a "do not add to any new roadmap" line item, and a named dependency to be removed from existing ones on a schedule.

When to Consider This Package

Consider it, narrowly, when all of the following are true:

• You already run Symfony CMF 1.x with PHPCR-ODM in production and this bundle is already in composer.json.
• The alternative is a rewrite of the media subsystem, not a library swap.
• You need media organized as repository documents, referenceable from CMS content, with form-integrated uploads — and the existing implementation is working.
• You are willing to own the code: fork it, keep it on a pinned PHP/Symfony line, and accept that upstream will not patch it.

Look elsewhere — and expect this to be the answer most of the time — when:

• The stack is Laravel, or any non-Symfony-kernel framework. There is no bundle integration, full stop.
• You are greenfield, or planning Symfony 4+/PHP 8+. The bundle predates Symfony 4's bundle-less conventions and PHPCR's ecosystem has not kept pace.
• You need LTS guarantees, a security policy, or a CVE response process. An archived 2016 repository has none of these, and that is a procurement blocker rather than a tradeoff.
• You need S3/CDN delivery, signed URLs, on-the-fly transforms, or modern formats (WebP/AVIF). The Imagine-based variation pipeline is of its era.
• You need a rich admin media library. This is a storage and variation layer, not an asset-management UI.

Evaluation shortcut: the decision should take one meeting. If PHPCR-ODM is not already in the dependency graph, stop — the cost of introducing a content repository to justify a 30-star archived bundle is not a defensible line in any business case.

How to Pitch It (Stakeholders)

To executives: This is an archived Symfony CMS component last released in 2016, with no security patching, no active maintainers, and 30 GitHub stars. It is not a candidate for new investment and should not appear on any forward roadmap. The only live question is whether we currently pay to maintain it inside a legacy Symfony CMF application; if so, the recommendation is to budget a migration to commodity file storage plus an image-variation service rather than a fork. One housekeeping item: an earlier internal review mistakenly described this as a Laravel package. It is not — it cannot be installed into a Laravel application — so any work item that assumed otherwise should be closed, not resourced.

To engineering: Two things to align on. First, the integration premise in the prior note is incorrect — Symfony bundles need the Symfony kernel and container, and Laravel's use of Symfony components does not provide that; drop any spike around installing this in a Laravel app. Second, the honest assessment of the code: the reusable idea is the named-rendition variation model and PHPCR-backed media documents with content references. Everything else — the Imagine pipeline, the form integration, the Symfony 2.7/3.0 compatibility envelope — is dated and unmaintained. For anyone on a current PHP or Symfony line, the equivalent is a filesystem abstraction with a transform-on-request strategy; that is a small, well-understood build, and it removes a dependency we cannot get patches for. If we do have a PHPCR-CMF estate in production, the right move is to pin and isolate it behind our own media interface so the eventual swap touches one adapter rather than every caller. Either way, we should not be adding it anywhere new.