@ukcw My 2cents here: With the “Embedded” type of integration used by this plugin, all providers will behave in a similar fashion. They will usually send a temporary placeholder for anything not already stored in THEIR cache (i.e. requested by someone else recently). When automatically saving “whatever” image is returned, this means the placeholder will be saved.
In the case of ShrinkTheWeb, we provide a few ways around this:
1. On queued or errors with a URL (invalid, broken, timed out, etc), our server will serve the placeholder image with an HTTP status code of 404. If Yannick adds a small check for this status code and DOES NOT cache that image, the correct image would be cached on the next attempt after successful capture. This is the simplest workaround, and this method “may” work for other providers as well (many have copied our API behavior over the past decade).
2. Using our sample code for the “Advanced” method would allow for inline status checking and more control over caching (already handled automatically in our sample code and fully tested).
3. We also provide a third way, using the “Notification Callback” feature (available with “Embedded” or “Advanced” methods) that will PUSH the captured image to the end-user storage/cache as soon as it’s captured, behind-the-scenes. This way will overwrite any prior cached image with the valid one being PUSHED.
For options 2 and 3, there is the additional requirement of putting a callback script on end-user servers, so that would add a bit of work to Yannick’s part.
I hope that insight helps. ??
Cheers!
