Ezmultiupload Ls Laravel Package

Product Decisions This Supports

• Vendor/package triage on a PHP roadmap. This is a decisive input for a "do not adopt" call: archived repo, last release May 2017, 22 stars, zero dependents, and a NOASSERTION license that legal cannot clear without manual review. That combination alone is enough to close the evaluation ticket.
• Platform-fit validation before a spike. The package is not a Laravel package at all — it is an eZ Publish legacy stack (-ls) extension providing multi-file upload behavior in the legacy admin/content editing UI. For a Laravel product, this is a category mismatch, not a version-compatibility problem. Use it to kill the "can we just pull in a multi-upload package?" question early.
• Build vs. buy (verdict: build). Multi-file upload is a commodity capability: a JS dropzone, chunked/resumable POSTs, server-side validation, queue-backed thumbnail/derivative generation. Modern Laravel (Livewire/Inertia + a maintained uploader component, or a paid SaaS like Transloadit/Cloudinary) covers this in days. Buying here means buying a decade-old fork.
• Prior-art / UX reference only. Worth 30 minutes of reading to see how a mature CMS modeled batch binary ingestion attached to a content object (datatype-level handling, per-file validation, partial-failure UX). Useful as a spec input to your own design, not as a dependency.
• Migration scoping for legacy eZ shops. If a stakeholder is still on eZ Publish Legacy 4.x and needs multi-upload before migrating to Ibexa, this is a stopgap decision — with an explicit sunset date, a vendored fork, and an owning engineer assigned.
• Roadmap de-prioritization evidence. "Opportunity 14.02" and a 0.375 score reflect the market's verdict: near-zero community demand. Good ammunition for saying no without a long debate.

When to Consider This Package

Consider it only if all of the following hold:

• You are running eZ Publish Legacy (4.x) with the legacy admin interface and need batch upload of media/binary attributes inside content editing.
• You can accept unmaintained code — no security patches, no PHP 7.4+/8.x support, no framework updates, no upstream fixes.
• Legal has independently cleared the license. NOASSERTION means GitHub could not identify a known license; do not assume GPL compatibility with your distribution model until counsel signs off.
• You are willing to vendor/fork the source into your own repo and own it, because Composer installability and dependency resolution against a modern PHP stack will not work as-is.

Look elsewhere — decisively — when:

• The target application is Laravel or any modern PHP framework. Different runtime, different admin, different asset pipeline; the integration cost exceeds a from-scratch build.
• You are on eZ Platform / Ibexa (v2+). Native multi-file upload and the Studio UI already cover this; do not backport legacy extensions.
• You require maintained dependencies, security response, or a support contract. None are available.
• You need chunked/resumable uploads, S3/multipart, progress UX, or async derivative processing — none of which a 2017-era legacy extension addresses.
• Your procurement process requires SPDX-identifiable licensing in the dependency manifest.

How to Pitch It (Stakeholders)

For executives: We evaluated ezsystems/ezmultiupload-ls for our upload capability and recommend not adopting it. It is an archived extension for eZ Publish's legacy admin interface — not a Laravel package — last shipped in May 2017, with 22 GitHub stars, zero dependent projects, and an unidentified license. The functionality it provides (uploading several files at once into a content editor) is a well-understood commodity we can deliver in-house in a fraction of the time it would take to fork, modernize, and legally clear a dormant codebase. Adoption would add long-term maintenance and license risk with no offsetting benefit.

For engineering: Treat this as a reference implementation, not a dependency. Read it for the batch-ingestion data model (per-file validation, partial-failure handling, attachment-to-entity semantics), then close it. Our path is a maintained uploader in the front end plus queue-backed server-side processing on Laravel — roughly a sprint of work, fully owned, with PHP 8 and S3 support that the original never had. If anyone is genuinely still on eZ Publish Legacy, that's a separate, time-boxed fork decision that needs a named owner and a migration deadline attached.

Bottom line: zero-dependency-risk tolerance, near-zero community demand, and a platform mismatch make this a clear no. The measurable value is a short read and a validated spec, not a composer require.