Sonata Media Chunk Uploader Laravel Package

Product Decisions This Supports

• Framing correction that drives the decision: this is a Symfony bundle for Sonata Media Bundle, not a Laravel package. It plugs chunked (resumable) uploads into the Sonata admin media form. For a Laravel roadmap, the leverage is conceptual only — the pattern (client-side chunking → server reassembly → standard media item) — and the correct decision is "use a Laravel-native chunked upload path" (e.g. pion/laravel-chunk-upload, a tus server, or Laravel filesystem + resumable JS), not adoption of this code.
• Unblocking large-media workflows in the back office. Where a Sonata admin exists, this lets editors upload video, high-res imagery, and large PDFs without hitting PHP upload_max_filesize / post_max_size / time limits. That's a direct unlock for content operations if today those assets are moved manually by engineering.
• Scoping "media library" as a roadmap item. Chunked upload is an enabling capability, not a headline feature. This package lets you cheaply test whether editor self-service for large assets matters before committing to a custom build or a DAM purchase.
• Build vs. buy vs. wire-up. In a Symfony/Sonata shop, adoption is the "wire-up" path — hours of integration vs. days building chunk assembly, temp-file lifecycle, and progress UX yourself. The decision turns on dependency risk, not effort.
• Ops/support cost reduction. Resumable chunks reduce failed uploads on flaky connections and cut "my upload failed" tickets and partial/corrupt media records.
• Feature-flag scoping. Because the package is unmaintained (0 stars, 0 dependents), the right product posture is an admin-only, flagged capability with a named internal owner — not a customer-facing surface.

When to Consider This Package

Consider it when:

• You are on Symfony + SonataAdminBundle + SonataMediaBundle, and the upload pain is confined to the admin/back-office, not the customer-facing app.
• Your blocker is transport — PHP upload limits, timeouts, flaky networks — not media pipeline features (transcoding, adaptive streaming, virus scanning).
• The audience is internal and small (editors, ops), so a low-maturity dependency has limited blast radius.
• You need it now and cheaply, and you're prepared to treat it as code you own: vendor/fork, pin an exact commit, and wrap it behind your own service so it's replaceable.

Look elsewhere when:

• Your app is Laravel (or any non-Sonata stack). There is no integration path; you'd be borrowing ideas, not code. Solve chunked upload natively with a maintained Laravel/tus option.
• You need resumable uploads across sessions, background processing, or S3 multipart — use the tus protocol, a JS chunker (Uppy/Dropzone/resumable.js) plus your own endpoint, or presigned direct-to-object-storage uploads.
• Uploads are public-facing or security-sensitive — chunk handlers are a known attack surface (temp-storage exhaustion, path traversal on filenames, MIME/extension spoofing, chunk-flood DoS, weakly authorized finalize endpoints), and this package has no community scrutiny or maintenance signal.
• You need lifecycle guarantees — no adoption means no upgrade path when Sonata or Symfony majors move. If the capability is strategic, own it.
• Multi-node/ephemeral deployments — if it assumes local temp storage, resumability breaks behind a load balancer; verify before committing.

How to Pitch It (Stakeholders)

To executives: We have a small, free option that lets editors upload large media files through the CMS, which today is blocked by server upload limits and generates support overhead — but only if we run a Symfony/Sonata admin. It has essentially no user base, so we should treat it as internal glue code we own, with a small engineering budget to fork, pin, and security-review it. If large-media management is strategic, this is a cheap way to validate the need before investing in a proper build or a DAM vendor. If our stack is Laravel, this isn't adoptable — we'd build the equivalent with supported tooling.

To engineering: It adds chunked, resumable upload to the Sonata Media admin form, working around PHP limits and adding retry behavior. Scope is narrow — transport only, no transcoding or scanning. Integration cost is low (config + form + routing), but the dependency is effectively unmaintained at 0 stars / 0 dependents: plan to vendor or fork, read the chunk-assembly and temp-file code for path traversal and orphaned-chunk cleanup, add idempotency on finalize, and keep it isolated behind our own wrapper so we can swap it out. Confirm Sonata Media and Symfony LTS compatibility and whether a client-side chunking JS is actually included before estimating.

Recommendation: Conditional adopt — Symfony/Sonata admin only, time-boxed spike (budget ~1–2 engineer-weeks including security review), with explicit internal ownership and a fork-and-pin exit path. Do not adopt for Laravel — use a maintained Laravel-native or tus-based chunked upload instead. Re-evaluate at the six-month mark against the fork's maintenance cost, and move to presigned direct-to-object-storage if large media becomes a first-class product surface.