Roxyfileman Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for WYSIWYG media management: Informs whether to wire a self-hosted file browser (RoxyFileman) into an editor-driven authoring surface, versus buying a hosted DAM/asset service or building a first-party media library.
• Editor stack consolidation: The bundle's one real integration point is IvoryCKEditorBundle, which is itself unmaintained. A PM using this would effectively be deciding to freeze the CKEditor 4 + Ivory combination for a legacy admin surface rather than migrate to a maintained editor (CKEditor 5, Tiptap, TinyMCE) with its own asset pipeline.
• Configuration surface / multi-tenancy: The README documents file-location config, Roxyfileman config, multiple profiles, custom filesystem services, and swappable Roxyfileman versions — useful as a reference spec for what a media-browser abstraction needs (per-profile storage roots, pluggable storage backends) even if you build it yourself.
• Admin-facing scope: Relevant only to internal/back-office authoring features (image upload, browse, insert into rich text) — not a customer-facing or API-surface decision, so it rarely belongs on a roadmap as a line item.
• Framework mismatch is a decision input, not a footnote: This is a Symfony 2 bundle, not a Laravel package. For a Laravel codebase the PM decision is "no," and the useful takeaway is the feature checklist, not the dependency.
• Abandonment triage: 3 stars, 0 dependents, last release March 2018 — this is a sunset/do-not-adopt data point. It feeds a "known unmaintained dependencies" register and a security-review backlog item rather than a feature bet.

When to Consider This Package

Consider it only if all of the following hold:

• The application is a legacy Symfony 2 app already using IvoryCKEditorBundle and CKEditor 4, where touching the editor is riskier than adding one more pinned dependency.
• You need a file browser fast, on a private/internal admin panel, with low blast radius if it breaks.
• You can pin the Composer version and accept no upstream fixes — meaning you own the code, including the RoxyFileman PHP backend it wraps (which has its own upload-validation and path-traversal attack surface).
• An authenticated firewall guards the imported routes; the README explicitly tells you to do this, and file-upload endpoints are a classic RCE vector.

Look elsewhere — or build in-house — if any of these are true:

• You are on Laravel. There is no Laravel integration here; you would be porting a Symfony bundle. Use a maintained Laravel media library (Spatie Media Library, Laravel Nova's file field, Filament's FileUpload) or a hosted DAM.
• You are on Symfony 4+ / 5+ / 6+. This predates Symfony Flex and the modern bundle conventions; expect to rewrite the service wiring.
• Security posture matters. An eight-year-old package wrapping a PHP upload handler is a liability you inherit entirely, with no CVE feed and no maintainer to patch it.
• You need multi-user permissions, image transforms, CDN delivery, or audit trails — RoxyFileman provides none of that, so you would be wrapping it anyway.
• Anyone external touches the uploads. Public-facing upload endpoints without active maintenance is a hard stop.

How to Pitch It (Stakeholders)

For executives: This is not a recommendation to adopt. It is a 2018-era Symfony 2 integration for a self-hosted file browser, with 3 GitHub stars and zero dependent projects — effectively abandoned, and not usable in our Laravel stack without a port. The strategic value is as a requirements checklist: it documents the minimum features a media browser needs (per-profile storage roots, pluggable filesystem backends, editor integration) in about a day of reading, versus weeks of discovery.

For engineering: Treat the repository as a design reference, not a dependency. The bundle's shape — configuration profiles mapping named storage locations to filesystem services, a swappable RoxyFileman build, route prefixing for firewall isolation — is a reasonable skeleton for a first-party media module. Two concrete warnings: (1) the wrapped RoxyFileman PHP backend handles uploads itself, so any adoption imports an unmaintained upload path with no security disclosure channel; (2) its sole ecosystem partner, IvoryCKEditorBundle, is likewise dead, so the integration story only exists inside a CKEditor 4 estate we are trying to leave.

Recommendation: Do not add. If a legacy Symfony 2 admin genuinely needs it this quarter, pin the version, front it with authentication, restrict upload MIME types at the web-server layer, and book migration off it. Otherwise, scope a 2–4 week build on Spatie Media Library (Laravel) or pick a hosted DAM, and use this README as the acceptance-criteria starting point.