Resolve the issue that relative paths are unproperly handled

[Spr-Aachen]

Issue

When having a post (e.g. "xxx/blob/main/src/content/posts/post.md") with relative image path (e.g. "./cover.jpg" referring to "xxx/blob/main/src/content/posts/cover.jpg") set inside frontmatter, the image fails to display in pages-cms.

By clicking View On GitHub button you'll find it pointing to an incorrect url (e.g. "xxx/blob/main/cover.jpg").

Solution

Add entryPath prop to make sure the relative paths can be properly handled

[Spr-Aachen]

If there's anything I got mistakened, please let me know:)

[hunvreus]

The PR touches on way too many files

More importantly, I think you misunderstand the way media paths work: https://pagescms.org/docs/configuration/media/

We define 2 paths:

media:
  input: src/media
  output: /media

The idea is that input is the relative path (from the root of the repo) to the folder. This is what we use to find and display the media in our interface (e.g. src/media/my-image.png). We swap the input prefix for output when we write the file: src/media/my-image.png → /media/my-image.png

The output form is what you get in your file, so you need to adjust based off of what you expect.

I know that a lot of Astro users have media collocated with their media. Most other setups (Next.js, Hugo, 11ty, etc) tend to have all media in a single folder.

I've discussed before adding support for collocated media, but for now I would just recommend you use a central folder for all of your media.

[Spr-Aachen]

The PR touches on way too many files

More importantly, I think you misunderstand the way media paths work: https://pagescms.org/docs/configuration/media/

We define 2 paths:

media:
  input: src/media
  output: /media

The idea is that input is the relative path (from the root of the repo) to the folder. This is what we use to find and display the media in our interface (e.g. src/media/my-image.png). We swap the input prefix for output when we write the file: src/media/my-image.png → /media/my-image.png

The output form is what you get in your file, so you need to adjust based off of what you expect.

I know that a lot of Astro users have media collocated with their media. Most other setups (Next.js, Hugo, 11ty, etc) tend to have all media in a single folder.

I've discussed before adding support for collocated media, but for now I would just recommend you use a central folder for all of your media.

Thank you for your patient answer, I do know the way media works, and this is how my config looks like

media:
  - name: posts
    input: src/content/posts
    output: /src/content/posts

content:
  - name: posts
    path: src/content/posts
    fields:
      - { name: cover, type: image, options: {media: posts} }

The problem is, the media files in my project stored in the same folder as the markdown content, which is a common pattern in Astro.
When I write cover: "./cover.jpg" in frontmatter (relative to the markdown file), the View on GitHub link in the editor incorrectly points to xxx/blob/main/cover.jpg instead of xxx/blob/main/src/content/posts/guide/cover.jpg.
I understand your documentation says to use a central folder, but many users prefer colocated media and that actually works with Decap CMS. So I still hope this could be supported.
If permitted, I'm willing to offer a better solution with minus changes to the code files. I've rebased my branch to clear all the conflicts so you can reopen this PR anytime if wanted.

[hunvreus]

Sure. Can you describe how Decap CMS actually handle that?

The main issue for me is for new content creation: if you don't have an entry yet for your post, how can we know where to upload images?

[hunvreus]

Feel free to rework a new PR

[Spr-Aachen]

Feel free to rework a new PR

Hi, yesterday I've opened a new PR

[Spr-Aachen]

Sure. Can you describe how Decap CMS actually handle that?

The main issue for me is for new content creation: if you don't have an entry yet for your post, how can we know where to upload images?

How Decap CMS Handles This
If media_folder is not specified, it defaults to the content folder. When you upload an image, it gets uploaded there and the relative path is written to frontmatter.

Solution for Pages CMS
During config normalization, the system checks each media configuration. If media.input is empty/null and a matching content collection exists, it copies the content.path to media.input. Now the image field knows where to upload files and how to construct correct GitHub URLs.

My co-mate has pushed a commit solving this issue via modifying lib/config.ts to automatically fill media.input from the corresponding content.path

[hunvreus]

OK, but how do we handle uploading media if the file hasn't been uploaded yet? Also, we need to enforce that the entry has creates a subfolder (e.g. /my-collection/my-post/index.md and not /my-collection/my-post.md).

[Spr-Aachen]

OK, but how do we handle uploading media if the file hasn't been uploaded yet? Also, we need to enforce that the entry has creates a subfolder (e.g. /my-collection/my-post/index.md and not /my-collection/my-post.md).

I think the new PR has resolved the first concern by adding logic to fill media.input from the corresponding content.path when it's empty, which allows the image field to know where to upload files (and construct correct GitHub URLs). As for the new posts, the current collection's path would be used as the default upload location.

For the second concern (subfolder requirement), I think it might be able to handle in two ways:

1. Add validation in the content configuration to enforce that entries must use subfolder structure
2. Automatically create subfolder when users create new entries through the CMS

I'll try implementing this in the new PR if you give me a direction.

[Spr-Aachen]

Ok I found a issue with higher priority and I've opened the PR

After solving that issue can we start adding features like creating subfolders