Ezmultiupload Ls Laravel Package

Getting Started

Reality check before anything else: this is not a Laravel package and cannot be used from Laravel. ezsystems/ezmultiupload-ls is an eZ Publish legacy-stack extension — the -ls suffix means it is packaged for ezpublish_legacy/extension/, not for the Symfony/eZ Platform kernel. There is no service provider, no facade, no config/, no migrations, no routes in the Laravel sense. If your application is a Laravel app, stop here and read the last bullet in Gotchas instead.

If you genuinely maintain an eZ Publish 4.x / eZ Platform-with-legacy-bridge install, the setup is:

composer require ezsystems/ezmultiupload-ls
# requires ezsystems/ezpublish-legacy-installer as a Composer plugin,
# which drops the files into ezpublish_legacy/extension/ezmultiupload

Then enable it, regenerate the legacy autoload map, and clear every cache layer:

# settings/override/site.ini.append.php
[ExtensionSettings]
ActiveExtensions[]=ezmultiupload
ActiveAccessExtensions[]=ezmultiupload

php bin/php/ezpgenerateautoloads.php -e
php bin/php/ezcache.php --clear-all
# on eZ Platform also: php bin/console cache:clear

Finally grant the multiupload/upload module function to whatever role your editors use — otherwise the button renders and the AJAX call 403s.

Where to look first, in this order:

1. extension/ezmultiupload/settings/ezmultiupload.ini.append.php — the only real configuration surface (size limits, mime whitelist, upload target).
2. extension/ezmultiupload/modules/multiupload/upload.php — the actual behaviour; this is the whole feature in one file.
3. extension/ezmultiupload/design/standard/templates/ and settings/override/ — the template overrides that inject the widget into the object edit form.

First use case: an editor editing a gallery or a "Files" folder object gets a multi-file picker instead of adding attachments one at a time, then publishes once. That is the entire product.

Implementation Patterns

• Treat it as UI, not an API. There is no PHP service class to call. The integration point is an ezjscore AJAX endpoint (/multiupload/upload) plus template overrides. If you need to create content programmatically, use eZContentFunctions::createAndPublishObject() (legacy) or ContentService::createContent() (Platform) — not this extension.
• Fork, don't patch in place. ezpublish_legacy/extension/ is a Composer-managed vendor path. Any template or JS tweak must live in your own design extension, overriding the extension's templates, or it will vanish on the next composer update.
• Replace the front-end, keep the endpoint. The bundled JS is 2015-era and swallows errors into alert dialogs. A very common day-to-day pattern is to leave modules/multiupload/upload.php alone and drive it from Dropzone/FilePond/Uppy instead. Capture one working request in the browser network tab, then replay it: it needs the eZ session cookie plus ezjscore's request token, and the response is JSON — inspect upload.php for the exact key names before writing the client.
• Verify the semantics of "multi" before promising it. Depending on which datatype template is overridden, the widget either fills a multi-value attribute on one object or creates one object per file. Read upload.php and confirm with a two-file test on a staging class; do not assume bulk attach when it is actually bulk create.
• Let the normal publish pipeline run. Because files go through regular content publish, workflow events, Solr/Lucene indexing, and view-cache invalidation all fire correctly. Resist any "speed it up" instinct that writes directly to the storage directory.
• Limits stack multiplicatively. upload_max_filesize / post_max_size (PHP), client_max_body_size (nginx) or Apache LimitRequestBody, the ini setting in ezmultiupload.ini, and the datatype's own constraints. When one batch fails while individual uploads succeed, it is almost always post_max_size — a silent empty $_FILES with no error.
• If you are bridging to Laravel: skip this entirely. Dispatch one queued job per uploaded file that POSTs to the eZ REST API (/api/ezp/v2/content/objects) or shells out to a legacy CLI script. You get retries, progress, tests, and logging for free — none of which this extension offers.

Gotchas and Tips

• Archived, last release May 2017, zero dependents. No security patches, no PHP 7.4/8 compatibility work. The legacy kernel (and this extension's assumptions) breaks on modern PHP. Running it means pinning an old PHP image for the admin UI.
• License is NOASSERTION. The upstream is almost certainly GPL-2.0 (eZ legacy lineage) but it is not machine-declared. In any organisation with licence scanning, that is a procurement blocker, not a footnote.
• Composer 2 will silently no-op the install. The package's type is handled by ezsystems/ezpublish-legacy-installer, which is a Composer plugin. With Composer 2's allow-plugins, an unlisted plugin is skipped without a hard failure — you get a successful require and no files. Add it to config.allow-plugins and re-run.
• Override precedence is the opposite of intuition. Design/siteaccess order wins, and among extensions the last active one takes the template override. "The button doesn't appear" is nearly always ordering in ActiveExtensions, not a missing template.
• Regenerate autoloads every time. Legacy extensions do not use PSR-4. Forget ezpgenerateautoloads.php and you get "class not found" or a blank template with no error.
• Three caches, all of them. eZ view cache, template compile cache, and (on Platform) the Symfony container/HTTP cache. Clearing one leaves you debugging a ghost for an hour.
• Debugging the AJAX layer: enable [DebugSettings] DebugOutput=enabled and Debug=inline in site.ini to get stack traces instead of a generic alert; tail var/log/error.log. The legacy kernel's debug.log is per-siteaccess under var/<siteaccess>/.
• Extension points are limited to four: the ini file, the single module view, the bundled JS, and template overrides. There are no signals/slots, no DI container, no events. Do not go looking for a Symfony bundle inside it.
• Worth stealing for a Laravel rewrite: the UX flow (pick parent location → pick content class → drop N files → publish) is the only durable idea here. The implementation is roughly 150 lines of "validate, loop, create content" and maps cleanly onto Storage, FormRequest validation, a queued job, and FilePond. Rebuild it; don't port it.