RFC: Payload DAM improvements

[paulpopus]

This RFC covers improvements to Payload’s open source features around digital assets management (DAM). Think file uploads, image manipulation and organization.

As part of the wider 4.0 redesign we will also be enhancing the UI around file uploads

Proposed changes

• Move storage adapters to their own property instead of plugins (pr)
• Video previews with controls

• PDFs preview
• Video and PDF thumbnails
• Support localized files (eg. upload one file in english, another for french)
• Support file versioning
• Updated documentation
  • New /docs/digital-assets-management overview covering all features top level
  • New DAM starter template
• Add support for on-demand resizing
• Add dynamic link sharing with expiration dates
• Usage references, eg. track where an image is used

We’d like to hear about your experience, your feedback and suggestions for improvements we can make to the DAM.
There’s also a million things that we could build, so for the things that matter most to you please 👍 them below so we can best prioritise them.

[linus-ha]

We have a custom implementation of "sizes". We define an upload doc type. Based on that type, a different set of sizes is created in a post-processing step. Having something like this out of the box would be great. (Example: Article picture vs. logo)

Post processing is done via a custom background job system, more capable than the one the payload includes. In the future we are adding, for example, video post-processing to this - just another upload doc type in the same collection.

If there is interest in this, ping me, and I could share more details.

[michaelshowes]

I mentioned aspect ratio lock for image cropping the Community Call, but instead of rewriting here, I'll link to the discussion from 2.5 years ago 😂

#3557

[swheeler7]

aspect ratio lock would be the biggest improvement imo

[robinvangestel21]

Hi team.

We are experiencing some issues with cropping images with an EXIF orientation bigger than one (this affects all photos taken in portrait mode on iOS, for example). I've created an issue and PR (#16350) with unit tests for this (against V3). Would be amazing if this issue could be resolved in V3 already or in V4.

If the PR needs to be made against V4, I'd be happy to do so!

[AaronClaes]

These changes look very promising already!

It would be great to be able to register our own custom preview components for specific file types.
We work a lot with 3D files (.glb and .gltf), I wouldn't expect Payload to have previews for formats that niche, but having an extension point to plug in our own would be perfect.

(we currently solve this by having a custom UI field in our upload collection)

Also +1 on usage references & file versioning!

[paulpopus]

Great idea, looking into it!

[cyphernetsecurity]

This looks very promising One area that might become increasingly important as DAM workflows evolve is security validation during the upload lifecycle itself.
A lot of teams already handle storage, transformations, previews, versioning and organization, but security checks often happen later in the pipeline or outside the CMS entirely.
Having clear extension points around upload processing and validation hooks could open up some interesting possibilities for custom security, compliance and content verification workflows.

Looking forward to seeing how the DAM architecture evolves in v4.

[V-iktor]

I like where Payload 4 is heading, a lot of quality of life improvements.

For large sets of media like images, we need to be able to force the user to select a folder for the uploaded image.

Uploading and selecting media should have the same view.

The first thing the user should see when he decidees to Select from existing is a list of folders.

Clicking a folder should expand it and display the contents.

Not having this ability makes Payload basically useless for large websites with a lot of media.

[cbratschi]

We use Payload upload collections for both images and MP4 videos and generate VideoObject structured data from the resulting media documents.

The new video previews are a great improvement, but we also need server-side video metadata and a persistent poster image outside the Admin UI:

• Detect and persist video width and height.
• Ideally persist duration as well.
• Generate a poster/thumbnail as a managed derived file.
• Expose a stable poster URL through the API.
• Ensure derived files follow the normal storage, replacement, and deletion lifecycle.

A browser-generated canvas thumbnail is useful for the Admin UI, but it cannot be used by frontends, APIs, email rendering, or structured data.

I also reviewed the file-transformer work in #17827. Its current public upload contract is one file in / one file out, so a custom video transformer cannot return extracted metadata or additional derived files. Would the planned DAM architecture support either:

1. Transformer results containing metadata and named derived files, or
2. Separate media-analysis and derivative-generation capabilities?

This would allow video and PDF support without requiring Payload core to depend directly on FFmpeg or a particular processing service. We would be interested in helping implement or test this against a real video workflow.

[paulpopus]

The transformers API is purely for modifying the source file itself, I have another API planned to handle metadata in general, that's where EXIF extraction, thumbnail generation and other things are expected to happen

[linus-ha]

Having a pluggable post-processing pipeline in general would be useful. Our workflow as briefly described in #16681 (comment) would be adaptable to that. If every processor in that pipeline were able to produce one or many outputs (multiple image sizes / video variants / etc.), that would be very flexible and adaptable to many workflows.

[cbratschi]

That separation makes sense, and the planned metadata API sounds like the right place for our use case.

For the MP4 workflow, the important part would be allowing a processor to return structured metadata and zero or more named derived files, with derived files using the configured storage adapter and the normal replacement/deletion lifecycle. Supporting asynchronous or external processors would let implementations use FFmpeg or another service without adding that dependency to Payload core.