blog: make meta image URLs stable

[shcheklein]

Right now when we change some libraries, setting, redeploy, etc, image URLs change and break our forum topics, for example:

https://discuss.dvc.org/t/dvc-heartbeat-feburary-20/318

We need to make some "proxy" URLs that will be stable and depend only on a post slug.

[julieg18]

This should be doable! Technically, we already have our blog images saved on a stable url. (December 2021 Community Gems Image) But we would want our meta images to be smaller than that... Two solutions I could think of so far:

• Running some kind of post build script that creates blog images with a fixed width (currently we have our meta blog images at 850) and saves them to a fixed place on a site. (/blog/DATE_OF_POST/IMAGE_NAME for example)
• Write some redirect code that redirects from a stable url to the image url (/blog/NAME_OF_BLOG_POST/main-img redirects to the unstable image link)

[julieg18]

Update! I looked into redirecting the meta image urls, but couldn't think of way to accomplish this with the way our app is set up. 🤔 But this solution doesn't involve recreating any images, so if anyone has any ideas for this, please let me know!

As for my other solution idea, I looked into editing the blog images and giving them fixed url paths. The only way to give an image a fixed path in Gatsby (as far as I know) is to place images in the static folder before gatsby starts. There are probably a couple ways to edit and save images in the static folder before a gatsby build, but I tried one way in my draft pr, #3161.

#3161 has a prebuild script that runs in production. When it runs it uses nodejs packages and a package that works with images called Jimp to take all images in the static/uploads/images, create a resized version with a fixed width (800px), and saves them in a /static/blog folder. Then gatsby copies over all the images in the static folder to public folder and our blog posts have access to 800px images with a fixed path. While this works, we are forced to edit and save a whole new set of blog images on our website.

What do you think, @iterative/websites? Any other ideas for easier solutions?

[iesahin]

How Gatsby determines the generated image URLs? If it's not random and can be customized, it may be easier to set a URL/pathname formatting option.

[julieg18]

How Gatsby determines the generated image URLs? If it's not random and can be customized, it may be easier to set a URL/pathname formatting option.

Unfortunately, Gatsby doesn't seem to have a way to set or customize image urls. All image urls are usually something like /static/RANDOM_NUMBER/RANDOM_NUMBER/image-name.png. This is recommended for most use cases but for certain edge cases (like this one), Gatsby offers the static folder. Anything in the static folder is copied over to the completed build with the exact path it had in the static folder.

[rogermparent]

The primary solution I'd think of is adding some post-bootstrap code that queries all blog post nodes and their images, then make the largest versions accessible at the slug-only URL we want. We could use some external solution like #3161 but I think it'd be best to avoid that if at all possible.

As far as that "somehow", there's a few options:

• Copying the files into public, which works everywhere at the cost of some disk space
• Redirecting the static url to our images, which don't take the extra disk space but will require us to improve our redirect logic a bit to accept redirects defined at build time
• Symlinks, which don't work on S3 so we can rule them out at least for now

There's also the issue of actually using those images in the pages, I assume we'll want to if any embed automatically pulls the image. My first guess is that we'll have to mangle the gatsby-plugin-image data a bit to replace that largest url with the new one in the meta tags which doesn't sound too hard in a vacuum, but anything could happen especially when trying to appease external sites' image fetching.

[julieg18]

The primary solution I'd think of is adding some post-bootstrap code that queries all blog post nodes and their images, then make the largest versions accessible at the slug-only URL we want.

I didn't think of that! I'll look into it!

Copying the files into public, which works everywhere at the cost of some disk space

I actually did this on my draft pr! It worked fine, but I think I saw an error somewhere which made me do things a different way. But I'm testing again and not seeing the error... If the error doesn't show up again, we should be able to do this just fine if we decide on this solution.

Redirecting the static url to our images, which don't take the extra disk space but will require us to improve our redirect logic a bit to accept redirects defined at build time

I looked into redirection, but I couldn't figure out a way to give our node backend access to the static urls that Gatsby gives images by default.

[rogermparent]

I looked into redirection, but I couldn't figure out a way to give our node backend access to the static urls that Gatsby gives images by default.

Maybe we could look into writing out a json file that contains the contents of the redirects created with Gatsby createRedirect, then have the server read that file and integrate them to our existing system? A bit kludgy and heavy-handed, but we can make sure a build is run before each hosting, bar caching issues.

It would also introduce the "happy path" Gatsby redirect API to our system and possibly allow us to transition the whole thing if it makes hosting our redirects more possible on other platforms.

[rogermparent]

Seems gatsby-plugin-netlify could serve as a decent reference implementation as it also writes out a redirects file.

key line const { redirects, pages } = store.getState() in onPostBuild

[julieg18]

Thanks for the ideas, @rogermparent! Copying the files into the public seems to be the easiest solution to implement... What do you think? Should I work on having the needed blog images be copied to the right place in the public folder or should I do further research on redirecting?

[rogermparent]

@julieg18 I'd say we should go for public copying, and hopefully in the future we can leverage most of that code to create redirects if we want to do so, as "blog image + slug = blog image at slug/image" is very similar to "blog image + slug = redirect from slug/image to blog image"

[julieg18]

I originally worked on a solution for just copying the images created by gatsby-plugin-image to public in a post build script, but I couldn't find a way for it to work. I ended up with a postBuild script that querys the source path for each main image and uses Jimp to resize and save to public. I commented out my solution, gave details in my pull request, and requested reviews. Any ideas for improving what I have?

[yathomasi]

@julieg18 I went through the code I tried fixing the part of the code you had commented on. ie using the gatsby-plugin-image. I also tried debugging that but yes some of the images are not fully converted at the time of moving so that error seemed to persist.
Also, another solution using Jimp is also a good way to go with. But, since we already have sharp as dependency and also sharp is faster I went ahead with sharp and replaced Jimp.

Actually, I did some comparisons around the solutions,

• First one using gatsby-plugin-image, it took around - 19151 ms for graphql query itself
• Current Jimp implementation took around, 26121 ms to complete
• Sharp implementation took around, 4039 ms to complete

I have kept the sharp changes and pushed to meta-image-path-contd branch.
EDITED:
Also, above metrics are only for post-build only
I have created a draft pull request #3206