Hi, and thanks for files.gallery — the single-file approach combined with the upgrade-safe _files/ customization layer is a genuine pleasure to build on.

I'd like to request JavaScript callbacks that fire after file-manager operations, in the same spirit as the existing on_click, on_select and login.on_logout hooks in the Advanced JavaScript config.

Why this matters

Any integration that needs to react to file changes currently has no clean hook. Today the only options are:

Wrapping window.fetch / XMLHttpRequest to detect the internal action requests, or
Polling the filesystem on a schedule (cron).

Both are brittle: they depend on internal request shapes and parameter names that can change between releases — which directly undermines the upgrade-safe philosophy of the custom.js layer. An official event API would let integrations survive updates instead of breaking on them.

Concrete use case

I'm building a global search across all folders (the built-in filter is per-folder), backed by an external SQLite/FTS index. To keep it in sync in real time I need to know when a file is uploaded, deleted, renamed, moved, etc. — including the affected path(s). Right now I have to monkey-patch fetch/XHR to catch these, which is exactly the fragile pattern I'd love to avoid. The same need applies to DAM/CMS integrations (e.g. ProcessWire), audit logging, cache invalidation, regenerating derivatives, and outgoing webhooks.

Proposed callbacks

Fired after the server confirms success, consistent with the existing (e, item) convention:

• on_upload(items)
• on_delete(items)
• on_rename(item, old_path, new_path)
• on_move(items, from_path, to_path)
• on_copy(items, from_path, to_path)
• on_duplicate(item)
• on_new_folder(path) / on_new_file(path)
• on_zip(items, archive_path) / on_unzip(archive_path, to_path)

For every event, the essentials would be: operation type, path(s) relative to root, old/new path on rename/move, and the existing item object(s) for consistency.

Even better: one generic catch-all

If a full set is too much surface area, a single future-proof hook would cover almost everything:

• on_task(task, data) — where task is the operation name and data carries normalized info: affected path(s) relative to root, old/new path where relevant, the item object(s) you already pass to on_click, and a success flag.

Optional nice-to-haves

• A cancelable "before" variant (e.g. return a falsy value to abort) for validation/guards.
• A matching server-side PHP hook in config.php (e.g. an on_task callable), for integrations better handled server-side — DB writes, webhooks — without relying on the browser being open.

If on_task(task, data) alone is the least effort on your side, that single hook would already unlock the vast majority of these use cases. Happy to help test.

Thanks for considering!