Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images uploaded before activating this adapter return 404 #152

Open
jslvtr opened this issue Oct 13, 2022 · 1 comment
Open

Images uploaded before activating this adapter return 404 #152

jslvtr opened this issue Oct 13, 2022 · 1 comment
Labels
enhancement New feature or request plugin New plugin or plugin feature

Comments

@jslvtr
Copy link

jslvtr commented Oct 13, 2022

Hello!

I've been using the default Ghost storage adapter for a while, and have got a few year's worth of images in my content/images/ folder.

Recently though I've switched to using Cloudinary for my image storage, and I've activated this adapter.

However all my old images no longer work. Let's say I'm requesting image 2022/05/Untitled.png. This is what happens:

  • Ghost responds with 301 for {domain}/content/images/2022/05/Untitled.png, redirecting to {domain}/content/images/2022/05/untitled.png.
  • Ghost responds with 404 for {domain}/content/images/2022/05/untitled.png (makes sense, the image doesn't exist)

What I'm not sure about is why the original 301 response!

Deactivating this storage adapter and going back to the default one fixes the problem. No more 301s, and therefore no more 404s.

Looking through the code, I can't see anywhere in this storage adapter that would fall back to the filesystem (but also I don't know much about the code).

Should it fall back to the filesystem if the image is not found in Cloudinary? Or are we expected to migrate all our in-post images to Cloudinary before switching the adapter?

Looking at previous issues and PRs I found #90 which was closed without merging, seems like it adds this missing functionality.

@eexit
Copy link
Owner

eexit commented Oct 21, 2022

Hi @jslvtr,

Thanks for your comment. Indeed, there's no fallback designed with this adapter but as you pointed out, it should be rather easy to implement this as a plugin. You are more than welcome to build (and test) it :)

Thanks!

@eexit eexit added enhancement New feature or request plugin New plugin or plugin feature labels Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request plugin New plugin or plugin feature
Projects
None yet
Development

No branches or pull requests

2 participants