Store Assets Relative to Content (Bundles)

[marcojakob]

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Currently, the Media Library is a single folder where every image is dumped. This doesn't allow assets to be organized, managed, and deleted properly.

What is the expected behavior?

There is work going on to add subfolders (see #1046) and provide further improvements to the Media Library (see #1321).

But I think we should go a step further than that and allow assets to be stored relative to its content (it's been asked for in various comments to media library issues). The paradigm for such asset handling is different, but I belive it is a very reasonable way to organize the content.

The Hugo SSG has been moving more and more towards this way of organizing its content and calls this Page Bundles (see Hugo Content Management with Page Bundles and Content Organization).

content/
├── posts
│   ├── my-post-1
│   │   ├── index.md
│   │   └── post-image.jpg
│   ├── my-post-2
│   │   ├── index.md
│   │   └── post-image.jpg
│   ├── _index.md
│   └── overview-image.jpg

In this example, there are two page bundles, one for /posts/my-post-1 and one for /posts/my-post-2. They each have their own assets stored in the same folder.

Then there is also a bundle for the overview site for posts (Hugo calls it a Branch Bundle).

Reason for Bundles

• Entire content for one page with its assets is stored in one folder. It is obvious which assets (images and also other resources) belong to a page.
• SSG's generally determine output placement based on the location of source files. So, we can just reference assets with a simple relative path or just the filename instead of using /assets/some-unique-filename.jpg or /assets/some/duplicated/path/to/image.jpg.
• The markdown content with relative images is rendered in the GitHub ui.
• Content editors don't need to browse through lots of unrelated assets.
• Assets can be optimized (sized/cropped) for its specific content.
• Assets can safely be deleted if a page is deleted. In a central assets folder we are never sure if some image is still referenced by some content.
• In my mind, images for a blog post are an integral part of the content. So, bundling it into one folder just makes sense.
• Content is also portable: I can zip markdown and images together and they work independent from the entire website.
• This might also improve an editorial workflow as the reviewer can focus on reviewing one folder containing everything related to the content.

[tech4him1]

Also see initial discussion in #325.

[CanRau]

would love that, too, i'm not yet using netlify cms but am considering it. as i'm managing my assets in an assets directory relative to the post it's not easy to migrate.
and by the way, to prevent duplicate assets for internationalized content i'm also storing all language versions in the same directory having one shared assets folder
would love to use this structure with netlify cms 👍

[alexito4]

Content editors don't need to browse through lots of unrelated assets

I would like to underline this. For people that uses Apps for markdown editing this is important. Usually these Apps can render images if they are in the same directory as .md file or with absolute path, which is not useful for later deployment. If the CMS supported this feature it means we can work on our posts in the same way from our local machines and from the CMS. ❤️

[arturogh]

I want this functionality and would like to lend a hand 😁. Design and possibly code help (front end).

[erquhart]

@arturogh that would be awesome - happy to support you in your efforts, too 👍🏼👍🏼

_{Sent with GitHawk}

[alexandernanberg]

Great! This is a feature I'd really want too so I'd be happy to help in any way 😄

[arturogh]

Do you guys have any design assets for Netlify CMS I could leverage? Someone working on the technical, backend side of this?

Also, a short 5-10 min chat would be great :).

[erquhart]

You can view assets in our design repository on the fabulous Abstract - here's the invitation link.

@Benaiah and I both work on the backend, and @talves also has a fair amount of familiarity. We generally field questions right here in the issue, or on the PR if you have one.

Finally, I'm happy to have a call with you to answer any questions, I'll email you with details.

[CanRau]

Any news on relative assets? Just to know where we are 🤓

[arturogh]

Really sorry...I still want to work on this but life got crazy. I'd like to help with design and front end possibly at some point.

[ahoward]

anyone interested should check out ro. it manages data just like that. we use it that way @ dojo4. https://github.com/ahoward/ro -- https://dojo4.com/blog/static-is-the-new-black

[talves]

Ok, I am going to pull the maintainer card here. The following is not directed at any one person:

Before a conversation gets out of hand, make sure to adhere to the Code of Conduct
Let's keep the conversation on track with the issue title ("Store Assets Relative to Content") as best possible.

Thanks.

[erodrig]

Any update on this, for me this feature is critical for any medium size site.

[erquhart]

Probably our next priority after we finish OSS Docs support (#2093).

_{Sent with GitHawk}

[erquhart]

Meant to add this after the last community meeting - here's the approach we discussed:

• allow the collection slug to contain a slash
• everything before the slash is processed as a directory name with variables

collections:
  - name: posts
    label: Posts
    create: true
    folder: content/posts
    slug: "{{title}}/index.md"
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: markdown }

This approach only allows a single directory level to be created dynamically per entry, which should be sufficient.

Thoughts? Use cases this wouldn't work for?

[robdodson]

I believe that would work for our use case on web.dev :)

[CanRau]

@mazdak78 Already in beta it seems https://www.netlifycms.org/docs/beta-features/#relative-image-paths 🎉

[mazdak78]

@mazdak78 Already in beta it seems https://www.netlifycms.org/docs/beta-features/#relative-image-paths 🎉

@CanRau : Oh, thanks, but I was mostly referring to feature about slug: "{{title}}/index.md" mentioned by @erquhart on Jun 19. :)

[jimmyangel]

@erquhart Thank you for a super useful product! Question: are you guys working on the slug: "{{title}}/index.md" feature you mentioned on Jun 19, referred to by @mazdak78 above? If so, is there a rough ETA? -- I am getting started on a big project right now and we are making content organization decisions, and this feature would make it so much easier to have a cleaner set up!

[tomrutgers]

@jimmyangel #513

[amine250]

Meant to add this after the last community meeting - here's the approach we discussed:

* allow the collection `slug` to contain a slash

* everything before the slash is processed as a directory name with variables

collections:
  - name: posts
    label: Posts
    create: true
    folder: content/posts
    slug: "{{title}}/index.md"
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: markdown }

This approach only allows a single directory level to be created dynamically per entry, which should be sufficient.

Thoughts? Use cases this wouldn't work for?

Hi @erquhart, do you have an ETA for this feature? Thanks.

[jimmyangel]

What about images? Can they be stored in the same location, i.e., content/posts/{{title}}

[goulvenclech]

Hi everyone !
Does anyone know if this feature is implemented? This is the only thing preventing us from using Netlify CMS in our project... and the documentation is not clear on what the option media_folder_relative: true allows to do.
Thanks for the help :)

[erquhart]

It’s in progress, watch here for updates

_{Sent with GitHawk}

[erezrokah]

Latest code on master branch (not published yet to beta) lets you do:

slug: 'index'
path: '{{title}}/{{slug}}'

to save a file under title/index.md for example.

Next step will be to store images with the content.

[heejongahn]

Thanks a ton for implementing this feature!

[KesleyDavid]

ficaria muito melhor mesmo para gerenciarmos as postagens

[Ir1d]

Hi, I think the doc could be updated right?

https://www.netlifycms.org/docs/gatsby/#get-to-know-gatsby

[erezrokah]

Good catch @Ir1d! removing that part will also require updating the config.yml yaml to support the starter directory structure. Do you mind opening an issue for that?

[nidhi-wgl]

hi what would happen if title has space will the folder be created with spaces or hyphen?

[erezrokah]

@nidhi-wgl, sanitisation is still applied but only to template variables.

[theredwillow]

@erezrokah This is still listed under beta features in the docs. Is that the case or should this be moved to the permanent docs?

[erezrokah]

@erezrokah This is still listed under beta features in the docs. Is that the case or should this be moved to the permanent docs?

Yes we should. Opened a new issue to track this #4608

[BasixKOR]

Hi! Just found this issue. Is there any progress on uploading images to bundle paths? For now this featue is supported on not only Hugo, but also Zola and Hexo.

[erezrokah]

Hi @BasixKOR this is supported via https://decapcms.org/docs/beta-features/#folder-collections-media-and-public-folder