Everything lives under Components > Filedrop > Options, across five tabs.

Basic

Storage

Choose a storage driver: local filesystem, FTP, FTPS, or SFTP. Local storage can point anywhere on the server, including outside the web root. Remote drivers take a host, port, username, password, and remote folder, with an SFTP-only option to authenticate with a private key instead of a password. The storage folder field shows the path currently in effect underneath it, so you can see exactly what the default resolves to on your server.

Leave the folder empty and Filedrop uses its default. Since 1.0.1 that default is a filedrop_storage folder one level above your website folder, so on a new installation the stored files are out of the web server's reach from the start. A site that already has a filedrop_storage folder inside the website keeps using that one, so an update never moves or loses a transfer. Whichever applies to your site, the path shown under the field is the one that counts.

An optional storage quota (in MB, 0 = unlimited) and a warning threshold e-mail let you keep an eye on total usage.

Both the local storage folder and the remote folder accept placeholders to build your own structure instead of Filedrop's default layout: {username} (the uploader's Joomla username, empty for guests), {sender_name} (the "Your name" field, lowercased and hyphenated), and {year}/{month}/{day} (the transfer's own upload date). For example: uploads/{year}/{month}/{sender_name}. A configured path is used exactly as-is: the automatic year/month subfolders belong to Filedrop's default layout only, so files land directly in your configured folder unless you add {year}/{month} to the template yourself.

Keeping stored files out of reach

Filedrop writes a deny-all .htaccess, a web.config and an empty index.html into the storage folder. That stops Apache, LiteSpeed and IIS from serving the stored files directly, so every download has to go through Filedrop and past the transfer password, the expiry date and the download limit.

This section only matters when the storage folder sits inside your website root: an installation from 1.0.1 onwards already stores one level above it, and a folder you pointed outside the website yourself is fine too.

nginx reads none of those files. If your storage folder sits inside the website root on an nginx server, every stored transfer is downloadable straight from its own URL, which skips the password, the expiry date, the download limit and burn-after-reading. Download tokens are unguessable, so nobody stumbles onto a file, but anyone who received a link once can keep using it after the link should have stopped working.

On nginx, do one of these:

• Point the storage folder outside the website root. This is the better option on any server, not just nginx.
• Or add a deny rule to your server configuration, for example:

  location ^~ /filedrop_storage/ {
      deny all;
      return 404;
  }

The Options screen shows a warning under the storage folder field whenever the folder in effect is inside your website root, so you can see at a glance whether this applies to you.

The Connection check, step by step

The Connection check button at the bottom of the tab tests your storage settings before any visitor depends on them. How the test behaves:

• It uses the values as currently filled in on this tab, including changes you haven't saved yet - so you can test first and save once everything is green. Only an empty password field falls back to the last saved password.
• The checks run in order and stop at the first red result: fix that line, then run the test again.
• Nothing is changed on either server beyond one small, uniquely named test file, which is removed again at the end. Existing transfers are never touched.
• Placeholders in the folder fields ({username}, {year}, ...) are resolved with your own username and today's date for the test.

What each line checks, and what a red result means:

Green all the way down means a visitor's upload will store successfully with these settings.

Security

Upload Form Fields

Every field on the upload form - sender name, sender e-mail, recipients, message, expiry, download limit, password - can be set to Optional, Required, or Hidden (expiry only has Shown/Hidden, since it always has a value). Sender e-mail is the one field that defaults to Required rather than Optional, since it's normally needed to reply to the sender or let them know their file was downloaded; every other field defaults to Optional.

Hidden fields aren't just skipped - they use an admin-configured default value instead, enforced on the server so it can't be bypassed. Sender name, sender e-mail, and message all support {name}, {username} and {email} placeholders in their default, resolved to the currently logged-in visitor's own details (empty for guests) - useful for pre-filling or fully hiding these fields on sites where visitors are always logged in.

You can also add an info line under the upload dropzone itself, using {max_filesize} and {allowed_extensions} placeholders, e.g. "Max. {max_filesize} per transfer. Allowed: {allowed_extensions}." to tell visitors what's accepted before they try.

If a sender leaves their e-mail blank (only possible when that field isn't Required) or no recipients end up filled in, Filedrop still creates the transfer and shows the download link on-screen - it just skips whichever notification e-mail would have needed an address it doesn't have.

Per-page overrides

With more than one Filedrop - Upload menu item, each page can carry its own field settings. Open the menu item and go to its Upload Form Fields tab: the same settings as this tab, with every option starting on Use Global.

• Use Global means the page follows the component options above. Every existing menu item is already in that state, so adding a second upload page changes nothing until you say so.
• Change one option and only that page uses the new value. Whatever you leave alone keeps following the component options, so a page that needs a different message default overrides exactly that and nothing else.
• An empty text field also counts as Use Global, so a default value can be replaced per page but not blanked out. If you need a page where a default is genuinely empty, clear it in the component options and fill it in on the pages that do need it.

This covers the field states, the default values, the default expiry and the info text under the dropzone. It deliberately stops there: captcha, the guest access password, rate limiting, the recipient cap, the file extension lists, the storage settings and the maximum expiry stay site-wide, so a menu item can change how the form looks but never loosens a restriction. The per-page settings are enforced on the server exactly like the global ones, so hiding a field on one page cannot be bypassed by calling the upload endpoints directly.

The Filedrop - Upload module has no menu item of its own and always uses the component options, even when it sits on a page whose menu item has overrides.

Advanced

A free-form Custom CSS field, injected into the upload, download, and "My Transfers" pages, for fitting Filedrop's look to your site's own template beyond what its Bootstrap/UIkit-based styling already adapts to.

The < and > characters are stripped from this field before it reaches the page. They have no meaning in CSS, and leaving them in would let anyone who can edit these Options place arbitrary markup on your site's front end.