Problem/Motivation

dropzonejs.libraries.yml references legacy file paths:

/libraries/dropzone/dropzone-min.js
/libraries/dropzone/dropzone.css
When enyo/dropzone 5.7.2 is installed via Composer (using composer.libraries.json + wikimedia/composer-merge-plugin), the archive does not contain those files. The library ships:

dist/min/dropzone.min.js
dist/min/dropzone.min.css
Bulk upload and other Dropzone integrations fail silently because the JS/CSS assets are not found.

Steps to reproduce

Install enyo/dropzone 5.7.2 to libraries/dropzone/ via Composer (composer.libraries.json + merge plugin).
Enable dropzonejs (stock, unpatched).

Open a page that uses Dropzone (e.g. /admin/content/media/bulk-upload).
Observe: Dropzone widget does not load; browser console shows 404 for dropzone-min.js and dropzone.css.

Proposed resolution

Update dropzonejs.libraries.yml to reference the dist/min paths in the Composer-installed archive layout:

JS: /libraries/dropzone/dist/min/dropzone.min.js
CSS: /libraries/dropzone/dist/min/dropzone.min.css

Remaining tasks

Review attached patch
Manual testing per steps below
RTBC / commit if accepted

User interface changes

None.

API changes

None.

Data model changes

None.

Steps to test

Install enyo/dropzone 5.7.2 to libraries/dropzone/ via Composer.
Apply the attached patch.
Enable dropzonejs and simple_media_bulk_upload.
Open /admin/content/media/bulk-upload and confirm the Dropzone widget loads (no missing library errors in browser console).

Related

simple_media_bulk_upload #3604053 (composer.libraries.json for enyo/dropzone)

Issue fork dropzonejs-3604054

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

johanvdr created an issue. See original summary.

johanvdr’s picture

StatusFileSize
new513 bytes
johanvdr’s picture

Related: this patch fixes library paths after enyo/dropzone is installed via Composer.
That library declaration is proposed in:
https://www.drupal.org/project/simple_media_bulk_upload/issues/3604053

sriram_s’s picture

I followed the reproduction steps exactly, on clean installs of both Drupal 10.6
and Drupal 11.3:

- dropzonejs 2.11 (stock, unpatched) + simple_media_bulk_upload 2.0
- enyo/dropzone 5.7.2 installed via Composer using the same composer.libraries.json
declaration that ships with dropzonejs (type: drupal-library, target
libraries/dropzone/), which extracts to libraries/dropzone/dist/min/
- Opened /admin/content/media/bulk-upload

On both versions the Dropzone widget loads and works — no 404 for dropzone-min.js
or dropzone.css.

The reason is dropzonejs_library_info_alter() in dropzonejs.module. It has used
LibrariesDirectoryFileFinder to auto-detect the library path since #3099836 (2020),
and its candidate lists already include dropzone/dist/min/dropzone.min.js and
dropzone/dist/min/dropzone.min.css. On my installs it resolves to:

/libraries/dropzone/dist/min/dropzone.min.js => HTTP 200
/libraries/dropzone/dropzone-min.js (legacy) => HTTP 404 (not used)

So on current 2.x the .libraries.yml patch looks unnecessary — the hook overrides
the .yml paths at runtime with the resolved location.

To help pin down your case: could you share the exact path your dropzone files
landed at under libraries/ (the output of `ls libraries/dropzone/`)? If they're not
under one of the paths the hook checks (dropzone-min.js, dropzone.min.js,
min/dropzone.min.js, dist/min/dropzone.min.js), that's the real root cause — and
it'd point to the libraries directory setup rather than the .yml paths.

berdir’s picture

Status: Active » Postponed (maintainer needs more info)

chamilsanjeewa made their first commit to this issue’s fork.

chamilsanjeewa’s picture

StatusFileSize
new1013 bytes

Re-rolled the patch for Dropzone 6.3.5.