Download the PHP package ethsam/symfony-dropzone without Composer

Symfony Dropzone Bundle

Seamless integration of Dropzone.js into Symfony Forms with automatic entity relationship management for drag-and-drop file uploads.

ES

Features

• Drag-and-drop file uploads: Powered by Dropzone.js
• Entity relationship support: Automatically manage OneToMany and ManyToOne associations
• Built-in data transformation: IDs to entities via Doctrine ORM
• Pre-populated edit forms: Show existing files in edit mode
• Fully configurable: Dropzone.js options exposed in form builder
• Single or multiple files: Control upload mode per form field
• Custom upload/remove handlers: Route-based endpoints with JSON responses
• Image resizing: Client-side image processing before upload
• Flexible authentication: Custom headers for API integration
• Symfony Flex compatible: Automatic bundle registration

Requirements

• PHP: ≥8.1
• Symfony: 5.4, 6.x, 7.x
• Doctrine ORM: 2.12+
• Symfony Doctrine bridge: pulled in by Composer, it provides the EntityType the single-file mode builds
• Dropzone.js: 6.0+ (included via CDN)

Installation

Step 1: Install via Composer

The bundle registers automatically with Symfony Flex. If you're not using Flex, add to config/bundles.php:

Step 2: Include Dropzone.js

Add the following to your base template (e.g., base.html.twig):

That's it! You're ready to use DropzoneType in your forms.

Minimal Example

The shortest thing that actually works, end to end. Four files, nothing optional. The Quick Start below is the same story with the entity relationship spelled out.

1. The file entity. getId(), getFilename() and getSrc() are read by the widget. __toString() is required too: the widget renders the entity itself into a hidden field, and PHP raises a fatal error without it.

2. The form field.

3. The two routes. The upload handler must answer {"id": <int>}: that id is what the widget puts in the hidden field. The remove handler receives the id in the URL.

4. The template. Dropzone.js must already be loaded, see Step 2.

Quick Start

1. Define Your File Entity

2. Define Your Main Entity with Relationship

3. Create a Form Type

4. Create Upload/Remove Handlers

5. Use the Form in Your Template

That's it! The bundle handles everything:

• Dropzone.js widget rendering
• File upload via AJAX
• File ID storage in hidden fields
• Entity relationship transformation on form submission

Configuration Options

Every option is type checked when the form is built. Passing a value of the wrong type raises an InvalidOptionsException instead of being written into the page.

JavaScript Events

The widget dispatches DOM events on the dropzone element, so you can extend the behaviour without overriding the template or injecting JavaScript from PHP. Events bubble, so listening on document is enough.

The symfony-dropzone: prefix is not an accident. Dropzone.js 6 dispatches its own DOM events named dropzone:sending, dropzone:success and so on, with a detail of {args: [...]}. Those are still available and unaffected; the events above are the bundle's, with a named detail, and they work the same on Dropzone 5 which has no DOM events at all.

Sending an extra field with each upload

The formData option covers values known when the form is built, in PHP. It cannot carry anything the user types or picks on the page, because uploads are sent by AJAX long after the page was rendered. That is what symfony-dropzone:sending is for.

Say the same form has a category selector, and the upload handler needs to know which category was selected at the moment the file was dropped:

The handler reads it like any other posted field:

Treat that value as user input, exactly like the rest of the request. The browser decides what it sends, so validate it server side.

A value that has no field at all, computed in the browser, works the same way:

Reaching the Dropzone instance itself, for anything the options do not cover:

The symfony-dropzone:init listener has to be registered before the widget renders, typically in the page head or in a script loaded with defer. The other events fire on user interaction, so they can be bound at any time.

File Entity Requirements

Your file/attachment entity must implement:

• getId(): ?int: Returns the unique identifier
• getFilename(): string: Returns the filename for display
• Getter for choice_src property: By default getSrc(): string, returns the file URL/path for thumbnail display
• __toString(): string: Returns the identifier. The widget renders the entity itself into the hidden field, so an entity that is not stringable makes the form crash as soon as it holds existing files.

Example minimal entity:

How It Works

Architecture Overview

1. Form Type Registration: DropzoneType extends Symfony's form system
2. Hidden Fields: For multiple files: a CollectionType with hidden inputs; for single: an EntityType field
3. Twig Template: Renders Dropzone.js widget with JavaScript configuration
4. Upload Flow:
   • User drags files or clicks to select
   • Dropzone.js sends each file to your uploadHandler route via AJAX
   • Handler persists entity to database, returns {"id": <int>}
   • Bundle stores file ID in hidden form field
5. Form Submission: Hidden field values are collected
6. Data Transformation: DropzoneTransformer converts IDs back to entity objects via Doctrine
7. Persistence: Form submission handles OneToMany/ManyToOne relationships automatically

File Removal Flow

1. User clicks "Remove" link on file preview
2. Dropzone.js sends DELETE (or POST) to removeHandler route
3. Handler deletes entity, returns {"id": <int>}
4. Widget removes preview from DOM

Step 2 is what actually detaches the file, and your handler is expected to make the removal effective on its own. Do not count on the form submission that follows to finish the job: files that were already attached when the page was rendered are also listed in hidden fields written by Symfony, which the widget does not remove. Their ids are still submitted after the preview disappears. If your remove handler only unlinks the file instead of deleting it, that submission will link it back.

Examples

Basic Multiple File Upload

Single File Upload (ManyToOne)

Image-Only with Custom Dimensions

With Custom Headers (API Authentication)

Custom Preview Container

With Custom Form Data

Your upload handler receives this in $request->request->all():

Security

How the widget renders

The widget never builds JavaScript out of your data. Everything the browser needs, including stored filenames, is serialised to JSON inside an HTML attribute and read back with JSON.parse. The inline <script> is a constant block of code: it is byte for byte identical whatever your database contains.

This matters because filenames are supplied by whoever uploads a file. Versions up to and including 2.0.0 interpolated them straight into the script, where Twig's HTML escaping does not protect a JavaScript string context. See SECURITY.md for the details and for how to report an issue.

If you maintain a copy of dropzone.html.twig in your own templates/bundles/SymfonyDropzoneBundle/, that copy is what Symfony renders, and it is still on the old behaviour. Delete it or port your changes over.

What is still your responsibility

• maxFilesize and acceptedFiles are checked in the browser only. Enforce the real limits in your upload handler.
• Your upload and remove routes need their own access control. The bundle calls them, it does not protect them.
• The remove endpoint receives an id straight from the page. Check that the current user is allowed to delete that particular file.
• Values you pass through formData and headers are sent to your own upload route, so do not put anything there you would not put in a form field.

Upgrading from 2.0

No option was renamed or removed, and no application code has to change.

• The generated markup gained a <span hidden data-dropzone-config="..."> next to the widget. If you have CSS or JavaScript selecting on sibling position around the dropzone, check it.
• Options are now type checked. A value that used to be coerced, '5' instead of 5 for maxFiles for instance, now raises an exception at form build time.
• Custom behaviour that relied on editing the generated script should move to the events described above.

Upgrading from v1

If you're upgrading from the original emr-dev/symfony-dropzone:

• Bundle namespace changed: Ethsam\SymfonyDropzone (was EmrDev\SymfonyDropzoneBundle)
• Form type import: Update: use Ethsam\SymfonyDropzone\Form\DropzoneType;
• Option names: No changes; all options are backward compatible
• PHP requirement: Now requires PHP ≥8.1
• Symfony support: Now supports Symfony 5.4, 6.x, 7.x
• Data transformer: Automatic; no manual entity conversion needed

Migration example:

The API and functionality remain the same.

Differences from symfony/ux-dropzone

Summary: Use ethsam/symfony-dropzone for entity-driven file management; use symfony/ux-dropzone if you need tight Stimulus integration or prefer the UX paradigm.

Contributing

We welcome contributions! Please:

1. Fork the repository
2. Create a feature branch: git checkout -b feat/your-feature
3. Commit your changes: git commit -m "feat: add your feature"
4. Push to the branch: git push origin feat/your-feature
5. Open a Pull Request

For bug reports or feature requests, please open an issue.

License

This bundle is licensed under the MIT License. See LICENSE for details.

Originally forked from emr-dev/symfony-dropzone.

Credits

• Samuel Etheve: Current maintainer
• Emomaliev M.: Original author (emr-dev/symfony-dropzone)
• Nico Hiort af Ornäs: maxFilesize option, and the reports that led to the 2.1.0 security review
• Dropzone.js: File upload library