Folder View in List

[zubricks]

Design + Build a folder view for all collection types (not just Media collections).

[PP-Tom]

We would love this feature, it's the only thing I miss from Storyblok. It's a great way to organise content.

[TechSynthesis]

Yup! same here 💯

[SalahAdDin]

How is this going on?

[danpii]

we would love this feature as well!
@zubricks any update on this?

[luochuanyuewu]

Any news on this one?

[Adaphath]

There seems to be branch with last commit in October and one of the latest betas integrated.
Seems to be close...

[SalahAdDin]

@Adaphath which branch?

[Adaphath]

@SalahAdDin https://github.com/payloadcms/payload/tree/feat/beta/folders

[SalahAdDin]

@SalahAdDin https://github.com/payloadcms/payload/tree/feat/beta/folders

Let's check it!

Thank you

[nachomglz]

updates on this?

[exymax]

This feature will be a great win, i will start a few new projects with Payload after it's released

[brightonmike]

A big, big plus one on this.

[cgilly2fast]

Sounds like it will be released soon

[SalahAdDin]

Any news about it?

[immotus]

Did you hear that sound from a reliable source, e.g., from a core team member? It seems to be hanging in here for years now with little input from the core team 😕

[cgilly2fast]

A large commit was pushed today: #10030 probably still a couple weeks out

[rjay-hb]

@zubricks, is there any update on this feature?

[luochuanyuewu]

Can't wait to try it out!!!

[thanhnd1o2]

Great

[rxtsel]

Awesome!!!

[jmikrut]

moving a media item inside a folder change it's absolute URL (for example when using with next/image)

Yes! You will be able to configure prefixes based on folder structure for sure, but this will be optional. You will be able to opt in to that behavior if you want to

[luochuanyuewu]

Can't wait to try it out!!! Again

[alexrah]

Do you guys have a reliable ETA for this release? Thanks

[cgilly2fast]

I have been following the branch #10030 it looks like they are working out the kinks on merging to main so I am hoping for soon.

[alexrah]

yeah me too, the problem with "soon" comes after saying it for months now. As I said, I need a reliable ETA to plan, unfortunately keep saying soon isn't helping. I've been cornered by my CEO who won't accept "soon" as an answer anymore.

[jmcapra]

Can't wait to try this feature out

https://x.com/jarrodmflesch/status/1894508882837315933

[MartinHaun]

Eagerly awaiting this feature on clients behalf :)

[jmcapra]

Folder View has been released!

https://github.com/payloadcms/payload/releases/tag/v3.39.0

[hatsumatsu]

This is amazing! Does this mean we also get the option to switch between list and grid view for regular (non-upload) collections? 🥹

[SalahAdDin]

This is amazing! Does this mean we also get the option to switch between list and grid view for regular (non-upload) collections? 🥹
I guess not.

Did you check it?

[swheeler7]

The folders feature is amazing huge thanks to payload team for creating this and just continually shipping such high quality features! Amazing job. I had some time to play around with it and I really love how the ui works and the level of polish feels like google drive or similar which is a huge achievement @JarrodMFlesch

I do have some comments that I hope can be taken into consideration. The overall implementation is a bit surprising to me and wasn't quite what I was expecting - but not in a bad way at all. When I heard folder view I was basically expecting an alternative to the current list view but which would have been an alternative ui scoped only to the specific collection. What you actually ended up building seems far more powerful than that, however the added complexity does mean that there is some functionality that I was hoping for that is missing, but I think could be added in at some point based on the design pattern you implemented

1. Folder collection scoping - It would be really nice if there was some pattern for specifying collections that folders should be scoped to, rather than all folders being enabled globally. Currently, if I have two folder enabled collections (such as idk - trees and cars for example), and wanted to organize the content of those collections into folders then any folders I create that are specific to the trees collection would also show up in the cars collection and users could end up seeing a "Evergreens" folder in the cars collection. Maybe this feature could be achieved by adding a 'collection-slug' hasMany text field to the 'payload-folders' collection, and when creating folders or editing folders users could choose which collections the folder applies to.

2. UI based access control - This might be a can of worms, but it would be kind of cool to have the ability to limit access to items in folders to specific users, similar to how google drive has folder sharing options. I'm thinking that this access control would only apply in the folder view in the UI and wouldn't replace the stronger code-based access control as it could open up a lot of issues (like if a folder gets deleted who has permissions to move items into specific access protected folders). The new query-presets feature has this functionality, maybe similar logic could be used for folders?

3. payload-folders collection access control - This could already be an option and maybe I missed it in the docs, but it would be helpful if, when enabling folders in the config, we could add some access control functions to limit who can do what with folders, so that maybe only specific users can create folders, others can just add items to folders.

4. Option to disable the "Browse by Folder" view - while this view and overall pattern of being able to view content from multiple collection in one unified view is really powerfull, it might not be appropriate for all applications.

Again, amazing job with this feature it's definitely a game changer. Currently the only thing that makes me hesitant to use it heavily in my application is the collection scoping. I would push for globally scoped folders to be opt-in vs being the default. The the other features I mention would be nice to have but wouldn't stop me from using the folders and could be added down the line based on the way that the folders are structured

[alexrah]

I'll check this out pretty soon but for now someone who tried can confirm that this implementation allow to upload assets in sub-folders? I already asked for this few times getting an affirmative response from the team but it doesn't look like so reading the docs.

And from what I remember this folder discussions started from here Extending Upload to have nested folders (closed discussion because marked as duplicate of this one) which is a critical feature for any CMS aiming to host a lot of content.

Besides uploads, I second what said by @swheeler7 especially on folder collection scoping, I didn't expect global folders and honestly I don't have a use case for that atm, it could be cool, but in most cases folders can be useful for a collection and useless for another.

[SalahAdDin]

You can chose any image from the folder from any entity.

[takayumi]

Moving around objects does not change their location in the bucket.
(Can't say for local storage, as I only use s3 storage for assets)

Yeah, but what happens when you move the file to a different folder? How would you update the S3 bucket's prefix then?

[jxh0414com]

You would probably need to write some hooks using @aws-sdk/client-s3 package to do some copy command to the new location and delete the old asset. Feel like too much place for bug so I give up on this

    // 1. Copy the object
    const copyParams = {
      Bucket: destinationBucket,
      CopySource: `${sourceBucket}/${sourceKey}`, // Format: bucketName/objectKey
      Key: destinationKey,
    };
    await s3Client.send(new CopyObjectCommand(copyParams));

    // 2. Delete the original object
    const deleteParams = {
      Bucket: sourceBucket,
      Key: sourceKey,
    };
    await s3Client.send(new DeleteObjectCommand(deleteParams));

[SalahAdDin]

You would probably need to write some hooks using @aws-sdk/client-s3 package to do some copy command to the new location and delete the old asset. Feel like too much place for bug so I give up on this

    // 1. Copy the object
    const copyParams = {
      Bucket: destinationBucket,
      CopySource: `${sourceBucket}/${sourceKey}`, // Format: bucketName/objectKey
      Key: destinationKey,
    };
    await s3Client.send(new CopyObjectCommand(copyParams));

    // 2. Delete the original object
    const deleteParams = {
      Bucket: sourceBucket,
      Key: sourceKey,
    };
    await s3Client.send(new DeleteObjectCommand(deleteParams));

What about the Cloudinary plugin?

[jxh0414com]

maybe that too but I haven't really look into it. Not say for sure