Unknown adapter behavior

[MCTaylor17]

Summary

R&D required to fully implement the storage adapter.

Problem

The official docs are pretty lacking. Of the five required methods, the descriptions don't offer any insights into when they're called.
This is complicated by the fact that none of the parameters are listed for any of the methods.

Of the 5 methods, I've only been able to successfully invoke the save method by adding images to a post.

Searching the Ghost codebase for the other method names has come up short. My best guess is the adapter is passed to plugins.

Impact

Removing images fails to trigger delete meaning they remain pinned indefinitely.

Solution

Unknown.

[MCTaylor17]

Current returning fully formed url from the save method. This might be bypassing the serve middleware as well as other methods.

[bmann]

Thanks @MCTaylor17 — did you look at the S3 Adapter to see how it’s done there?

[MCTaylor17]

I think I looked at every storage adapter 😂

It's pretty clear each of them emulates the others and I can't help thinking there's a little mythology at play.

I have some basic tests that I need to try. For example, I didn't try adding new posts or pages and I'm optimistic that returning just the CID will send it through the middleware.

Whatever my findings, I plan to post an issue with Ghost to clarify the documentation.

[bmann]

Yes only images and files use this. Pages / posts are stored in the database.

Adding an image to a post / page should trigger.

Also a post image (in the slide out drawer) and I think a few other places like background header.

[MCTaylor17]

Forum post expressing similar confusion regarding adapter behaviour

Forum post indicating delete as limited to theme storage and potential future implementations