- Does kolyadin/sonata-media-chunk-uploader work with Laravel?
- No. Despite showing up in Laravel package research, this is a Symfony bundle built for Sonata Media Bundle and Sonata Admin. It ships no Laravel service provider, no config publish tag, and no adapter that makes a Sonata admin form work inside a Laravel application. If you are on Laravel, close the evaluation and build a chunked upload endpoint with tus, resumable.js, or S3 presigned multipart uploads instead.
- How do I install kolyadin/sonata-media-chunk-uploader?
- Install it with Composer, then register the bundle in your Symfony kernel (bundles.php on Symfony Flex) and enable it alongside your existing Sonata Media configuration. Because the project has no release history or CI signal, pin an exact commit rather than floating a version constraint. Treat the README as a hypothesis and confirm the declared Symfony and Sonata Media constraints in composer.json before you start.
- How do I configure chunk size and temporary storage?
- The bundle exposes configuration for the chunk size and the temporary directory where partial pieces are staged before reassembly. Keep each chunk comfortably below PHP post_max_size and any web server body limit such as nginx client_max_body_size, because multipart overhead is added on top. If you run more than one app server, the temp directory must live on shared storage, not a container-local disk, or chunks will land on different machines and never reassemble.
- Which Sonata Media and Symfony versions does it support?
- That is not reliably documented in public metadata, so it must be checked in composer.json and then proven with a one-day spike against your target Symfony LTS and Sonata Media major. Do not assume compatibility because the bundle installs cleanly. The most common failure mode for low-traffic bundles in this space is stale version constraints that resolve but break at runtime.
- Does it include a JavaScript client for chunking?
- This is unverified and it matters, because chunked upload is a two-sided contract of server endpoint plus client protocol and packages here often ship only the server half. Check whether a flow.js, resumable.js, or plupload-style front-end is bundled, and whether that front-end assumes Assetic or Webpack Encore, since that must match your build pipeline. If no client is included, budget time to write the chunking, retry, and finalize calls yourself.
- How does it get around PHP upload_max_filesize and post_max_size?
- It splits a large file into smaller pieces that are uploaded in sequence and reassembled server-side, so no single request has to carry the whole asset. Each individual chunk must still fit within post_max_size together with multipart overhead, so chunk size and PHP limits have to be tuned together. Server-side limits such as nginx body size and request timeouts still apply and are separate settings.
- Are uploads resumable if the connection drops?
- Resumable uploads are the stated capability, meaning an interrupted transfer continues from the last accepted chunk instead of restarting from zero. The details that matter are not documented publicly, including how chunks are identified, how offsets are validated, and whether the finalize step is idempotent. Test resume behaviour on a deliberately flaky connection before relying on it for editors on slow links.
- Does it support S3 or Gaufrette, or only local disk?
- Storage adapter support is unclear from the available information, and packages in this category commonly assume a local temporary directory. That assumption collides with horizontally scaled or ephemeral deployments where local disk is neither shared nor durable. Confirm the storage story first, and if it is local-only, plan a shared volume or accept the bundle as a single-server tool.
- Is it safe to use for file uploads in production?
- Chunk upload handlers are a well-known vulnerability class, covering unbounded temp-chunk accumulation and disk exhaustion, path traversal through client-supplied filenames, MIME and extension spoofing at assembly, chunk-flood denial of service, and weakly authorized finalize endpoints. With no community scrutiny behind this package, you are inheriting unreviewed file-handling code. If you adopt it, restrict it to an internal Sonata admin capability rather than a public upload path, enforce admin gating on both the chunk and finalize endpoints, and schedule cleanup of abandoned chunks.
- Is the package actively maintained, and what are the alternatives?
- There is no meaningful maintenance signal: no stars, no dependents, no CI status, and a single maintainer, so plan for a fork-and-pin posture rather than depending on upstream. On Symfony, look at OneupUploaderBundle, a tus-based upload server, or direct-to-object-storage presigned multipart uploads as maintained options. On Laravel, use a resumable protocol with Laravel Filesystem plus presigned multipart, which delivers the same capability with security review and support coverage behind it.