- Is ruwork/upload-bundle a Laravel package?
- No. It is a Symfony bundle built around a Bundle subclass, a DI extension, and a configuration tree, with no Laravel service provider, config/upload.php, or facade. On Laravel you would need a bespoke bridge or, more realistically, a native implementation using UploadedFile and a Flysystem disk.
- How do I install ruwork/upload-bundle?
- You install it with Composer via composer require ruwork/upload-bundle and then register the bundle in your Symfony kernel. Because the package is flagged abandoned on Packagist and last released in 2018, expect to relax PHP and Symfony constraints to get it to resolve on a modern stack. The GitHub repository is a read-only subtree split, so changes belong in the upstream Ruwork repository.
- What Symfony and PHP versions does ruwork/upload-bundle support?
- The bundle dates from the Symfony 3.4/4.0 era and typically pins PHP ^7.1 with Symfony ^3.4|^4.0 constraints. It will not resolve cleanly against Symfony 6.4 or 7.x or PHP 8.2+ without constraint changes. Even after relaxing constraints, deprecated container conventions and PHP 8 issues are likely friction points.
- Is ruwork/upload-bundle still maintained?
- No. The last release was 2018-07-30, the repository has zero stars and zero dependents, and Packagist flags it as abandoned. There is no upstream maintainer to patch security or PHP compatibility issues. The MIT license does at least make forking or vendoring legally straightforward.
- How does ruwork/upload-bundle handle uploads on Doctrine entities?
- It integrates with Doctrine lifecycle events to save, replace, and delete files associated with uploadable entities. The bundle wraps uploaded files and persists them to configured storage, removing the previous file when it is replaced or the entity is deleted. This is conceptually similar to VichUploaderBundle but with a Symfony-native integration seam.
- Can I configure storage paths and file naming in ruwork/upload-bundle?
- Yes, the bundle exposes a configuration tree for storage location and file naming, which is one of its stated features. Configuration is handled through the Symfony DI extension rather than a Laravel-style config file. Exact options should be checked against the bundle's configuration reference for the 2018 release.
- What is a good alternative to ruwork/upload-bundle for Laravel?
- For Laravel, use the framework's native UploadedFile::store() with a Flysystem-backed disk and an explicit service or model method that owns persist and delete. If you need ORM lifecycle hooks for uploads in Symfony, VichUploaderBundle is the maintained equivalent. league/flysystem-bundle is the right storage abstraction if you are on Symfony.
- Does ruwork/upload-bundle delete files when an entity is removed?
- Yes, lifecycle handling to delete uploaded files on entity removal is part of the bundle's stated scope, alongside save and replace. It hooks into Doctrine events for this. You should verify orphan cleanup behaviour and filesystem permissions in your own environment, since the code has not been maintained since 2018.
- Can I use ruwork/upload-bundle with Symfony 6 or Symfony 7?
- Not without compatibility work. The bundle's constraints target Symfony 3.4/4.0, and modern Symfony removes or deprecates the container conventions it relies on. In practice the migration effort is likely larger than the bundle's useful surface area, so replacing it with Flysystem plus an explicit upload service is the safer path.
- What are the production risks of using ruwork/upload-bundle?
- The main risks are abandonment, supply chain exposure from pinning an untested 2018 dependency graph, and the security-sensitive nature of upload code such as path traversal, MIME validation, filesystem permissions, and orphan cleanup. With no upstream maintainer, you own any CVE or PHP compatibility fix. For a new build, prefer maintained first-party or framework-native upload handling.