Relative URL conversion on unwanted frontmatter properies
megant opened this issue · comments
OK, let me draw up the problem. When I call fmImagesToRelative(node) in the onCreateNode hook of gatsy-node.js, the node argument of the function contains all the node data. Let's say I create a page dynamically according to the markdow below:
`---
title: Title
image: /content/images/image_name.jpg
slug: /my/multilingual/slug`
When this markdown data passed to fmImagesToRelative function, in the inside at row 233. the image validation is like:
if (!file.dir) return;
It means everything that looks like image path is surely an image path. This approach is wrong, because in this way every path will be converted to relative path instead of only paths related to the plugin's settings, eg:
plugins: [... { resolve: 'gatsby-remark-relative-images', options: { name: 'only-this-named-source', }, }, ...]
You should handle this somehow, otherwise we've to face lot of unwanted issues at build process.
@megant I can see the issue here. I believe adding a "field" option to filter by would solve this. That way you could specify something like:
{
resolve: 'gatsby-remark-relative-images',
options: {
fmFields: ['image'],
},
},
}@megant I can see the issue here. I believe adding a "field" option to filter by would solve this. That way you could specify something like:
{ resolve: 'gatsby-remark-relative-images', options: { fmFields: ['image'], }, }, }
I tried something similar (I used exceptions instead of fmFields and in contained fields which don't have to be converted), but my problem was fmImagesToRelative runs before plugin options initialization.
@danielmahon Has there been any movement on this?
@danielmahon I'm having a similar issue. Having a filter would solve it.
I could give it a go if it's still needed?
add options in fb63dd3