Ability to set a sub directory file paths on image or file fields, to keep the media browser clean and contextualised to each field

[toddpadwick]

The problem

I absolutely love Sanity. But one of the biggest blockers I've found so far, is that there is no ability to control structure or sub-directories in the media library. My clients have already mentioned that they are not happy about how messy the media library is which is a "huge mass of crap", from SVG logos, to big hero images, which are completely unrelated to one another. With my previous CMS – Craft, you could control the file path directory for uploading asset fields so that you could restrict them on a field-by-field basis.

I have adopted Sanity because of its many other fantastic benefits, but this problem really makes me miss using Craft, as I believe a CMS should be as simple and clean as possible for the end user and I am unable to offer such experience to my clients.

Here is an example of how messy the media library in Sanity gets

Here is an example the media library for an icon field used in one of our old sites on Craft CMS – only shows assets uploaded to the icon field. in the above example from Craft CMS, the image field, is configured to store files in the following file path, meaning when you open the asset browser you only see images in that folder /images/icons

Example of the issue on your own Sanity Featured projects studio

I've noticed your own Sanity featured project studio, where you allow users to add featured case studies on your website, is a great example of why this shortfall is a major issue. When you create a new featured project, and select images to display for your case study, you end up seeing all the images uploaded by other users for their case studies?? this seems crazy - you should never have to see the images uploaded for other users' case studies in the media browser - it should be restricted to only show images uploaded to that specific entry you are editing. or restricted to just your user.

Proposed solution

What would be fantastic is a simple 'path property' on the scheme, which has exposed access to the document data. Here are some examples of how that might be used for common use cases:

Proposed solution Use case 1

A hero image field for desktop images, which uploads and selects from images in a desktop folder, within a folder named by the document type, that is within a hero-images folder. This may result in an image located at cdn.sanity.io/images/say5yn59/production/hero-images/landing-page/desktop/23653c1fa6b303b2ba2f1de48b2fdeec9239fa19-524x524.jpg

   {
      type:'image',
      name:'heroImageDesktop',
      path:({document}) => `/hero-images/${document._type}/desktop`
   }

    {
      type:'image',
      name:'heroImageMobile',
      path:({document}) => `/hero-images/${document._type}/mobile`
   }

Proposed solution use case 2

An image field for SVG icons, which uploads and selects from images in a global icons folder, and the field restricts only svg's so that when browsing the media library from this field, you'll only see svg icons. This may result in an image located at cdn.sanity.io/images/say5yn59/production/icons/23653c1fa6b303b2ba2f1de48b2fdeec9239fa19-524x524.svg

   {
      type:'image',
      name:'icon',
      path: '/icons,
     options:{
         accepts:'image/svg+xml'
     }
   }

There are hundreds more use cases but essentially the main thing is to:

1. Prevent a messy cluttered media library
2. Make the CMS 'idiot proof' so that the user only sees media that is accepted by the related field and make it easy to select appropriate images.

Attempted workarounds

• I am aware I can use a third party S3 bucket for example, and use that as a custom asset source and combine it with a custom field. But this would mean I lose the benefit of using Sanity's image API which is great. The benefit of having asset hosting and content hosting all in one, was a big plus so losing this would be a big negative.
• I have tried using the media library plugin and tried to explain to the client how to use tagging to keep things a bit more tidy but this is bad UX and doesn't really solve the problem. I also don't like how 'hacky' and shoehorned in the third-party plugins are. I also don't generally believe plugins should be used for core functionality as it becomes risky further down the line if they are dropped or no longer maintained.
• I have considered creating a document type for images and then wrapping all images in an document so that I can determine how they are structured. But this is really clunky and time-consuming when a user needs to upload many assets to a gallery for example.

Additional context

I am aware many other headless CMS's lack this functionality too, and thus might be the reason why this feature was overlooked, or not prioritised. However, having offered this functionality to our clients and can say first-hand how much they loved it, I generally believe this is a high-value feature and will considerably boost the amount users will adopt Sanity over alternatives – or take the plunge into headless content management with sanity sooner than than they would have. I know I nearly didn't adopt it for this reason.

[pascalwengerter]

Any update from the core team here? Feels like an important topic to look into (or at least provide examples of how to resolve)

[toddpadwick]

Did you have any luck finding an interim solution @pascalwengerter ? This is becoming a real issue for my clients as it means they are uploading the same images over and over because the media library is just impossible to navigate with so much clutter, and that costs them more money in their usage quota.

[pascalwengerter]

Did you have any luck finding an interim solution @pascalwengerter ? This is becoming a real issue for my clients as it means they are uploading the same images over and over because the media library is just impossible to navigate with so much clutter, and that costs them more money in their usage quota.

@toddpadwick sadly didn't have time to look into it yet, but just yesterday deployed our Studio so...things are getting more serious here also. I can also already see a couple of other issues both with Sanity&Nuxt (3) coming in, so glad to eventually catch up and compare notes/approaches ;D

[toddpadwick]

@pascalwengerter Happy to catch up on Nuxt3+Sanity. We just launched our first project with both and despite Sanity's shortfalls, the performance benefits outweigh them. With very little effort we scored 100 in both performance and best practices in lighthouse scores. And the developer experience of using Sanity is so efficient. I just wish the UX was a little better in comparison with Craft CMS which was what we used to use.

[pascalwengerter]

@toddpadwick just saw https://www.sanity.io/plugins/sanity-plugin-media on the Sanity product demo, did you give it a try?

[toddpadwick]

Hi @pascalwengerter yes I have. I use it, but it doesn't do what I need and still leaves the user with a huge list of every image ever uploaded. The media plugin is just a basic wrapper for the existing media viewer, with the ability to add some meta data to images for filtering and so on. It doesn't give any ability to 'lock' where images are stored or how they are grouped on a field by field basis.

[toddpadwick]

Be great to get some input from the core team on this - is there a simple workaround, or whether this could ever be considered as a core feature? I've noticed your own Sanity featured project studio, where you allow users to add featured case studies on your website, is a great example of why this shortfall is a major issue. When you create a new featured project, and select images to display for your case study, you end up seeing all the images uploaded by other users for their case studies?? this seems crazy - you should never have to see the images uploaded for other users' case studies in the media browser - it should be restricted to only show images uploaded to that specific entry you are editing. or restricted to just your user.

[filipesmedeiros]

I believe you can create custom inputs that take the media's tags into account. Don't have the exact code here, but seems to be doable

[toddpadwick]

Ah I see @filipesmedeiros . That could work. However, as above, I really think this should be a core feature of the file and image fields. The media plugin is pretty cumbersome. I also do not think it's best practice to use plugins for anything other than minor features – for something as important as this, using a plugin can become a big risk further down the line.

[toddpadwick]

A year on, i still get frequent comments about this from clients. Any thoughts on possible updates to it?