Can we have a couple of end to end examples please?
S-unya opened this issue · 16 comments
Hi,
I realise that this is not necessarily within the scope of the plugin, but it would be really helpful to have the kind of setup we'd need across the board when using this plugin because there are potentially many systems working across each other here - gatsby-source-filesystem
, gatsby-transformer-remark
, gatsby-remark-images
, your plugin AND whatever CMS/editing solution one is using.
I have found that there seem to be conflicting requirements (that may just reveal my incomplete understanding).
For example, I am using NetlifyCMS and I have a folder structure a bit like this:
src -
pages -
about -
index.md
static -
admin -
config.yml
uploads -
asset.jpg
and my gatsby-config.json
uses this:
plugins: [
{
resolve: `gatsby-source-filesystem`,
options: {
path: `${__dirname}/static/uploads`,
name: "uploads",
},
},
{
resolve: `gatsby-transformer-remark`,
options: {
plugins: [
// gatsby-remark-relative-images must
// go before gatsby-remark-images
{
resolve: `gatsby-remark-relative-images`,
options: {
// Set the name option to the same
// name you set for gatsby-source-filesystem
name: "uploads", // default
},
},
// Make responsive, blur-up images from markdown images
{
resolve: `gatsby-remark-images`,
options: {
maxWidth: 693,
wrapperStyle: ` flex: 1; margin: var(--pad-0) 0;`,
linkImagesToOriginal: false,
},
},
{
resolve: `gatsby-remark-responsive-iframe`,
options: {
wrapperStyle: `margin-bottom: 1.0725rem`,
},
},
"gatsby-remark-copy-linked-files",
],
},
},
]
and my static/admin/config.yml
has this in it: media_folder: static/uploads
. When I look at the built file structure, the content of the uploads
folder is moved into public/uploads
while imageSharp processed images are placed in public/static
.
The issue that I have is my md file (in src/pages/about/index.md
) needs the path to be ../../../static/uploads/asset.jpg
in order to be a reference from the filesystem plugin and thereby be able to use graphQL to create an imageSharp node. This presents me with an issue because netlify-cms translates the media_folder
to an absolute path (in my case that will become /static/uploads
) or I can insert a public_folder
parameter, which in my case I'd need to point at /img
because that is where the build process has copied my files... and therein lies the issue because netlify-cms will use the public_folder
as the path to insert into the markdown file, which then breaks the graphQL query because the path doesn't point at a path process by the filesystem plugin.
I should clarify that images that I don't want to explicitly manipulate with imageSharp work with the above setup.
@S-unya thanks for this issue, I'm experiencing the same issue, would like to submit a PR for this but not sure where to start. I'm not familiar with many of the dependencies in this code. @danielmahon
Hi @danielmahon, as far as I understand the issue (I would appreciate it if anyone has better info) it is that gatsby-remark-images and this one work against images within the main body of the markdown, but if you have images in the frontmatter, they do not apply. Consequently, if you want to apply some image processing, you have to to both set the path to the asset directly and query the node with the settings you require in graphQL... You will also have needed to point the gatsby-source-filesystem at the folder that contains your asset.
So, one option is to get these plugins to point at the frontmatter images (quite a hard thing because they are not marked up in a reliable way) or, take the course of action that I am busy trying out, which is to place assets in the root of the src
folder and I am making a plugin which you can use to move the folder into the public folder (or any other folder). I have it mostly working, i'm just trying to work out the last details now. If you think this might be useful to you, let me know and I will submit it to gatsby as a plugin - currently, I just assumed that I was making a work around and was using it as a local plugin.
EDIT: While it was fun building the plugin, I couldn't resolve the issues for frontmatter (that this plugin does well for assets within the md doc) just by brute forcing it - so next approach is to use the same approach as this plugin
@danielmahon that is great news! I was about to attempt it myself now that I've had a little experience making gatsby plugins. If you need help, please let me know - as far as I can tell, it is just that we need assets referenced in the frontmatter to have the path set in the same way as the main body of the md.
@S-unya @hennessyevan OK, I updated the plugin (3e043d8) to simplify everything a bit (I hope). You no longer need to define any options. Also, to convert frontmatter images you'll need to use the new fmImagesToRelative
function in your gatsby-node.js
file. See readme. Also, make sure your source plugins for your uploads/images are before your markdown files as I believe the order does matter. gatsby-remark-images
does not handle frontmatter images so that's why you need to convert them beforehand in your gatsby-node.js
.
@S-unya Do me a favor and give these changes a try from master
and let me know if they work for you. Ill push to npm after we verify this works better.
Ive tested this with NetlifyCMS single frontmatter images and image lists.
Heres my full gatsby-config.js
where this seems to be working:
require('dotenv').config({
path: `.env.${process.env.NODE_ENV}`,
});
const settings = require('./src/data/settings');
module.exports = {
siteMetadata: {
title: 'Gatsby Starter Procyon',
shortName: 'Procyon',
...settings,
},
plugins: [
'gatsby-plugin-react-next',
'gatsby-plugin-styled-components',
'gatsby-plugin-react-helmet',
{
resolve: 'gatsby-source-filesystem',
options: {
path: `${__dirname}/src/images`,
name: 'images',
},
},
{
resolve: 'gatsby-source-filesystem',
options: {
path: `${__dirname}/static/uploads`,
name: 'uploads',
},
},
{
resolve: 'gatsby-source-filesystem',
options: {
path: `${__dirname}/src/pages`,
name: 'pages',
},
},
{
resolve: 'gatsby-source-filesystem',
options: {
path: `${__dirname}/src/data`,
name: 'data',
},
},
{
resolve: 'gatsby-transformer-remark',
options: {
plugins: [
{
resolve: 'gatsby-remark-relative-images',
},
{
resolve: 'gatsby-remark-images',
options: {
maxWidth: 760,
},
},
'gatsby-remark-smartypants',
'gatsby-remark-widows',
],
},
},
'gatsby-transformer-sharp',
'gatsby-plugin-sharp',
{
resolve: 'gatsby-plugin-netlify-cms',
options: {
modulePath: `${__dirname}/src/cms/cms.js`,
},
},
{
resolve: 'gatsby-plugin-manifest',
options: {
get name() {
return module.exports.siteMetadata.title;
},
get short_name() {
return module.exports.siteMetadata.shortName;
},
start_url: '/',
background_color: '#fafafa',
theme_color: '#212121',
display: 'minimal-ui',
icon: 'src/images/icon.png',
},
},
// 'gatsby-plugin-remove-trailing-slashes',
'gatsby-plugin-offline',
'gatsby-plugin-netlify',
],
};
@danielmahon It's working for me! Thanks so much. I'm using https://github.com/AustinGreen/gatsby-starter-netlify-cms and I can confirm that putting the image source first is necessary.
@danielmahon awesome work, thanks! I installed the plugin locally and it works very well for images at the root of the front matter. It doesn't work on images nested within sections within the frontmatter, which is a common pattern I think at least for Netlify-CMS.
For example, I have a section called "Testimonials" that has a number or quotes and each quote has an image for the citation.
This change is already very helpful, because it allows one to process different images (such as hero images, etc), nevertheless, would it be much more work to get nested images included? And could I be of assistance in any way?
@S-unya can you show me your NetlifyCMS config.yml?
The products 'page' is constructed entirely of widgets in the frontmatter. This is all Proof of Concept exploration of what can be done.
@danielmahon that works perfectly. Thanks for responding so quickly as well. It is has really helped to have this.
Please let me know when you update the npm package so that I can switch.
@S-unya glad to hear! It's published.