With relative media folder page bundles, an option to not save image widget to frontmatter

[xelivous]

Assuming i've set up relative media folders in my collection, and have an image widget as a field with a default set to "cover.jpg", then the image widget will typically store "cover=cover.jpg" in the frontmatter. My templates check for the existence of a "cover.*" (where * is jpg, png, etc) and if it exists it will display it automatically. Having the frontmatter field exist or not doesn't particularly matter for the template itself and is just extra noise. The existing frontmatter stored fields are largely useful for where you're storing images in a /static/ folder at the root of the site with shared images everywhere but doesn't really make too much sense for relative page bundles.

Likewise if I were to have a bulk subfolder of miscellaneous "screenshots" that would be displayed in a gallery, the templates would just find all image types in the screenshots folder, and any information written into the frontmatter field would be redundant.

Ideally it would be nice to have an image widget (option?) that finds images in the media folder based on a pattern (or default name) and automatically display them in the GUI, and allow uploading/removing based off of the normal workflow. It would respect the multiple:true/false setting and return the first item in the case of "false" (based off of alphabetical by default).

It's not totally necessary to implement since it is still possible to just throw all of the filenames into the frontmatter regardless.

Thanks

[kyoshino]

I’m not sure what you mean... maybe you can use the hidden widget for embed cover.jpg in your front matter?

[xelivous]

I guess i'll try to explain it a different way. Using an actual example of a config yml.

Suppose you have posts using "page bundle" format, with subfolders and an index file. The image widget specifies a filename to be used (could be the default key, depending on if you want to overload the meaning), along with telling it to not write into the frontmatter:

- name: "post"
  label: "Posts"
  folder: "content/posts"
  media_folder: ""
  public_folder: ""
  create: true
  path: "{{slug}}/index"
  fields:
  - name: "title"
    label: "Title"
    widget: "string"  
  - name: "cover"
    label: "Cover Image"
    widget: "image"
    write_frontmatter: false
    filename: "cover"

If someone goes to create a new entry, enters in "Post 1" as the title, and uploads a cover image, the file structure will then be:

content/
  posts/
    post-1/
      index.md
      cover.jpg

At present this would preserve the filename of the uploaded file (which could be 2024-10-09_wefwef.jpg) and then write cover="2024-10-09_wefef.jpg" into the front matter. However the proposed format would instead just not write cover={} at all, and instead just write cover.jpg into the media_folder.

This could be extended to something like "screenshots" with:

- name: "screenshots"
 label: "Screenshot Gallery"
 widget: "image"
 write_frontmatter: false
 filename: "screenshot/*.*" #turns into a pattern when multiple:true is set?
 multiple: true

The image preview/cover.jpg would still show up in the interface itself, and allow replacing/deleting/uploading images into that "image slot" still. It just wouldn't bother writing anything to the markdown file for any of the changes, and instead operate on the files themselves.

[kyoshino]

Thanks for the clarification. So it looks like there are some different things involved.

• Predefined file name (in this case cover) — it’s rather straightforward
• Not writing to front matter — it’s probably possible, but needs to automatically find cover.jpg
• Multi-file support — it’s being tracked in Support multiple image selections with default media library #10.

Will figure out how difficult it is overall.