Ezmultiupload Ls Laravel Package

Technical Evaluation

What the package actually is. ezsystems/ezmultiupload-ls is a legacy-stack (LS) extension for eZ Publish 4.x/5.x, not for eZ Platform / Ibexa (Symfony). It adds a multi-file upload control to the legacy Administration Interface, wiring a browser-side upload widget into the eZFile / ezfile datatype so editors can attach several binaries to a content object in one pass instead of one-at-a-time. The -ls suffix is the decisive signal: this package lives entirely in the pre-Symfony architecture that eZ Systems formally end-of-lifed in 2018.

Architecture fit — poor. Our target platform decision determines everything here:

Integration feasibility — low. The extension depends on the legacy admin's template override system, its own JavaScript bundle (historically jQuery plus a Flash/SWF-based uploader in earlier revisions), and legacy PHP runtime assumptions (PHP 5.3–5.6 era). Getting it to run on a modern PHP 8.x environment would require non-trivial surgery, at which point we are effectively maintaining a fork. With 0 dependents on Packagist and 22 stars, there is no community surface to lean on and no upstream to escalate to.

Technical risk — high, in three distinct buckets:

• Security. Unmaintained since the 2017-05-18 release and archived upstream. An upload endpoint written for PHP 5.x, on a codebase with no CVE monitoring, is a direct unauthenticated-file-write surface. Any deployment inherits the full backlog of unpatched issues plus whatever the intervening decade of PHP security hardening has invalidated.
• License / legal. Classified NOASSERTION — we cannot assert the license from metadata. eZ legacy extensions were typically GPL-2.0, which is a copyleft obligation and a genuine problem if this touches a proprietary product. This is a hard gate, not a note: legal review must precede any code contact.
• Runtime. PHP 5.x is EOL and unsupported by our hosting baseline. Supporting this package means supporting an EOL interpreter, which cascades into compliance and audit findings.

Key questions to resolve before spending any engineering time:

1. Do we actually still operate any eZ Publish 4.x/5.x legacy installation that is in scope? If no, this evaluation ends here — the package is out of scope by definition.
2. If yes: is that installation under a defined sunset date, and does a 2017 upload widget justify extending it?
3. What is the license in fact (read the bundled LICENSE/COPYING, not the package metadata), and does GPL-2.0 propagate into anything we ship or distribute?
4. Is the requirement "multi-file upload for editors" or "this specific extension"? These have very different answers — see below.

Integration Approach

Stack fit. Treat this as a UI pattern reference, not a dependency. The transferable asset is the small amount of domain knowledge the package encodes: how the legacy ezfile datatype handles multiple attribute collections per object, and what the editor affordance looked like. That is a design input, worth perhaps a day of reading — not a component to install.

Recommended path (for a modern Laravel/PHP target): build the capability natively. Laravel gives us the whole job in first-party primitives:

• Upload transport: Livewire/Inertia + a chunked, resumable uploader on the front end; Storage::disk() (S3 or local) for persistence.
• Validation and safety: FormRequest rules, MIME sniffing, size ceilings, randomized filenames, and quarantine-then-promote for scanned files. This is the area where the legacy package is weakest and where we must not inherit its assumptions.
• Async processing: queued jobs for thumbnailing, virus scanning, and metadata extraction — the thing a 2017 widget could not do.
• Authorization: per-object policy checks (Laravel policies/Gates) rather than the admin-session trust model the legacy extension relied on.

Migration path. There is no incremental migration from the extension; it is a replace, not a port. Sequence:

1. Inventory any live legacy installation and confirm whether the multi-upload feature is actually used (query logs/editor feedback before assuming demand).
2. If a legacy install must be kept alive short-term, isolate it — restrict admin access, keep it off the public attack surface, and set a dated decommission milestone.
3. Build the equivalent capability on the target stack, feature-flagged, with the legacy install as the behavioural reference.
4. Cut over per-editor-group, then retire.

Compatibility checklist if anyone pushes to install it anyway: exact eZ Publish version and patch level; PHP version ceiling; presence of a Flash dependency in the admin browser (already dead in all modern browsers); jQuery version conflicts with other admin extensions; and whether the site's template override chain would be disturbed. Any single "unknown" here should block install.

Sequencing. License clearance → scope confirmation (do we even have a legacy install?) → build-vs-install decision → rebuild behind a flag → cutover → legacy retirement. Do not invert this; the build is cheap, the legacy support tail is not.

Operational Impact

Maintenance. Upstream is archived: zero commits, zero releases since May 2017, zero dependents. Every future defect, PHP compatibility break, and security finding becomes ours permanently. There is no version to upgrade to — the maintenance model is "own a fork forever," which for a UI nicety is a poor trade.

Support. No vendor, no community, no issue tracker activity. Internal support means a named engineer who has read the code — a bus factor of one, on a codebase nobody wants to learn. Editors will file bugs against it and there is no upstream to route them to.

Scaling. Modest but real concerns: synchronous multi-file uploads on large binaries will tie up PHP workers; the legacy pattern typically lacks chunking, retry, and progress recovery, so large uploads fail ungracefully. If our volume assumption is "a few editors uploading a handful of files," tolerable; if we expect bulk ingestion, it is structurally wrong and will push us to rebuild anyway.

Failure modes to expect:

• Silent upload failure on large files (no chunking/resume), producing editor distrust and workaround behaviour (email attachments, shared drives).
• Partial writes leaving orphaned files or inconsistent content objects.
• PHP runtime incompatibility after any infrastructure upgrade — a hard outage of the feature with no patch path.
• Security exposure via the upload endpoint, with no upstream advisory channel to warn us.
• Browser-side breakage if the widget depends on deprecated plugins or Flash.

Ramp-up. Near zero learning curve to use, which is the package's entire appeal. But the organisational cost is the opposite: any engineer touching it must context-switch into a dead framework's idioms, and that knowledge does not compound. Budget for a rebuild rather than a skills investment.

Recommendation. Do not adopt. The score reflects reality — archived, unmaintained, zero dependents, ambiguous license, and architecturally bound to a platform we should not be extending. Harvest the UX intent, rebuild the capability natively in the current stack in a few days of engineering, and close the legacy surface rather than investing in it.