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
First, thanks for this plugin. I found a restriction that, at this point, I'm not sure is a unimplemented feature or something that broke in recent Wordpress, so any guidance would be appreciated to see how/if I can help fixing this :
When using the built in edit feature of Wordpress's media library to edit an image, the result after it is saved is not uploaded to Azure Storage.
Furthermore the filename doesn't update to the newly generated image, making the image object still pointing to the previous version of the object.
Steps to Reproduce
Go to Media Library, upload a file, the file gets correctly uploaded to Azure Storage
Click on the newly uploaded image and press Edit Image
Crop the image and press save
After saving, the thumbnail will be blank in the editor and the file url will still point to the previous version of the file
Expected behavior
The edited version of the image should be uploaded to Azure Storage and correctly reference in the file url.
Additional context
At this point it's not clear to me if this ever worked or is a recent bug. I tried looking at the code and I don't think there are any hook specific to the image editor in place.
What I noticed is that the new files get created locally (with a suffix), but there doesn't seem to be anything hooking with the plugin code to handle the upload of the assets or to fix the url. What's intriguing is that the URL never changes to the newly suffixed one (with or without the azure path).
From what I was able to dig on the topic, it's possible to hook on the file save with a filter on wp_save_image_editor_file. This may or may not be the optimal place to handle this as there may be a more appropriate hook further down the line.
There was a slightly similar issue that used another crop function here : #143 however the fix (which is part of the branch mentionned above that I tried) does not solve this.
Any chance I can get some guidance on if this ever worked or not, and if you have any tip on how I can help fix that. Thanks !
The text was updated successfully, but these errors were encountered:
@glouel thanks for the detailed issue! We're working on a large update (see #136) and once that's complete we'll assess if your issue is resolved in that work or needs additional handling.
Just to give you a bit more details, the reason I asked if this was possibly a recent issue is that I found a couple of recent reports of the same issue on wordpress.org, see :
I quickly looked at how other plugins handled the image editor but my understanding of wordpress internals is a bit limited.
I did notice however something that you may want to take into account at some point, because the editor uses GD locally to edit the files, you might have to "bring back" the image locally from Azure in case you don't keep a local copy, or eventually the edit will fail too. The S3 plugin does this.
I did not fully understand however how they detect the edit and save it back but wasn't able to spend much time looking it up.
This is independent of this main issue though, as even with a copy stored locally, the editor is not taken into account at all. Thanks for your support of this plugin in any case!
I'm facing the same issue - is there a workaround available? Would downgrading to some older issue solve the problem (assuming the bug was introduced at some point) or the editor has never been supported?
This is a lovely plugin that otherwise works nicely!
Describe the bug
Hey all,
First, thanks for this plugin. I found a restriction that, at this point, I'm not sure is a unimplemented feature or something that broke in recent Wordpress, so any guidance would be appreciated to see how/if I can help fixing this :
When using the built in edit feature of Wordpress's media library to edit an image, the result after it is saved is not uploaded to Azure Storage.
Furthermore the filename doesn't update to the newly generated image, making the image object still pointing to the previous version of the object.
Steps to Reproduce
Expected behavior
The edited version of the image should be uploaded to Azure Storage and correctly reference in the file url.
Environment information
Additional context
At this point it's not clear to me if this ever worked or is a recent bug. I tried looking at the code and I don't think there are any hook specific to the image editor in place.
What I noticed is that the new files get created locally (with a suffix), but there doesn't seem to be anything hooking with the plugin code to handle the upload of the assets or to fix the url. What's intriguing is that the URL never changes to the newly suffixed one (with or without the azure path).
From what I was able to dig on the topic, it's possible to hook on the file save with a filter on
wp_save_image_editor_file
. This may or may not be the optimal place to handle this as there may be a more appropriate hook further down the line.There was a slightly similar issue that used another crop function here : #143 however the fix (which is part of the branch mentionned above that I tried) does not solve this.
Any chance I can get some guidance on if this ever worked or not, and if you have any tip on how I can help fix that. Thanks !
The text was updated successfully, but these errors were encountered: