Closed alexstandiford closed 10 months ago
Hi @alexstandiford,
Thank you for your input. We will review your request and we will keep you posted.
Regards, Wissam
Hi @alexstandiford ,
I saw that you have sent us the following comment, but I don't see it in the thread here:
It seems that the issue is somehow related to my cache. When I flush the cache, the site works as-expected again. I'm getting ns_binding_aborted as a response on the image request until I flush the cache.
What is the current status? Is the issue fixed?
We would like to understand better how the caching layer interferes with our logic.
Regards, Wissam
Hi @alexstandiford ,
I saw that you have sent us the following comment, but I don't see it in the thread here:
It seems that the issue is somehow related to my cache. When I flush the cache, the site works as-expected again. I'm getting ns_binding_aborted as a response on the image request until I flush the cache.
What is the current status? Is the issue fixed?
We would like to understand better how the caching layer interferes with our logic.
Regards,
Wissam
I added that, but realized it was untrue. This is a separate issue I'm having, and removed hoping it wouldn't cause confusion. Please disregard this. The issue remains as I described originally, where a post created using the app does not properly update to use the Cloudinary URL.
Hi! I love the problem this plugin solves, and appreciate y'alls work!
Bug Description
When I upload media via the WordPress app, and then publish a post using that uploaded image using the block editor, it uses the local WordPress URL instead of the Cloudinary URL. In my case, I'm using "Cloudinary only", so that URL doesn't work because the file gets forward to Cloudinary right away.
It seems like the actual image has the correct URL, however, the image data inside the image gallery block is not bound to the image ID, and is instead has a hardcoded href that's generated on-upload. I think this is the source of the problem.
I am able to resolve the problem by manually going onto the site through a web browser and re-building every image block. Doing so forces the URLs to be updated.
Expected Behaviour
I expect to be able to freely upload media from the app, it forward it to Cloudinary, and when published the post uses the correct URLs.
Steps to reproduce
Additional context
I want to stress that I think the issue here isn't that the image ID is disassociated with the Cloudinary URL. I was able to prove that's correct by checking the admin interface for the image URL, and also cross-referencing it with the REST API image URL that's provided. The issue is that when the post is saved, the href value in the blocks seems to be stored as an attribute, which is used instead of looking up the image URL by the ID. This results in the app providing the incorrect URL in this data, thereby causing the issue.
A potential solution could be to do a find/replace in post content after an image is moved to Cloudinary, looking for these hardcoded references.
I understand that this may be something that's not always easy to implement, so if it's going to be difficult to solve this problem directly, I would really appreciate a little guidance on how I could potentially hook into the moment Cloudinary uploads these files. If one doesn't exist, I think a do_action would be really helpful if it happened just after the file is migrated to Cloudinary, ideally with the image ID, the old URL, and the new URL to enable this change to be made for people who are able to make this customization on their own sites.
Here's my system report: