You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Ensure that Cloudinary only is set in your settings.
Open the WordPress app
Create a new post
In the post, use the image block to upload a new file.
Click Publish
Observe the broken image URL
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.
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.
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:
The text was updated successfully, but these errors were encountered: