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
{{ message }}
Repository navigation
Ensure edited image sources are backed up when restoring the original image #295
Follow-up to #228: When editing an image in WordPress core (related: #158), the original image's sizes are backed up. This is primarily to restore them later. If then the original image is restored again or another round of edits to the same image is saved, the edited image's sizes get backed up. There is no way to restore these via the WordPress UI, but WordPress intentionally does not delete any edits at any point, and it keeps their metadata backups as well.
Our WebP uploads module does not behave in the same way with our _wp_attachment_backup_sources storage: When restoring the original image, the edited image data is not included in that backup anymore, while it is included in core's _wp_attachment_backup_sizes. Note that this problem only concerns the full size in any case, because all sub-size sources are included in WordPress's own storage by definition. But it is a bug we need to fix.
This is probably not critical because there's no way to restore them, but it's still a bug in the WebP uploads module based on how WordPress core works. We do keep the files around as expected, but we don't keep the meta data backup around, which makes it even more inconsistent even with our own approach.
Steps to reproduce
Upload a JPEG image with the WebP Uploads module active. WebP versions are generated in addition to the JPEG versions.
Edit the image through the WordPress UI (e.g. crop, rotate, anything). Then save.
View the attachment's _wp_attachment_backup_sizes and _wp_attachment_backup_sources post meta values. Both have the necessary data stored, the first for all individual sizes (including sources for each size), the latter just the main sources, i.e. for the original image (under full-orig, for consistency with the backup sizes).
Now restore the original.
View the attachment's _wp_attachment_backup_sizes and _wp_attachment_backup_sources post meta values. You will now recognize that the previous edit's file paths etc are present in _wp_attachment_backup_sizes, but not in _wp_attachment_backup_sources - the latter still only has the full-orig data and is missing the hashed data with references to the previously edited image, which is the problem we need to fix here.
Hey! @felixarntz thanks for opening this issue, I did some tests and apparently looks like this behavior is the same as having IMAGE_EDIT_OVERWRITE defined to true would you mind double check that you have this constant not defined or set to false, not defined is the default state of this constant.
When the constant is defined and holds a truthy value, no additional edited images are stored in either the backup sizes and backup sources meta.
This is value when IMAGE_EDIT_OVERWRITE is not defined or when the value is a falsy value when running your steps with the latest changes from production 3bd51d1.
Backup sources after 2 edits
Backups sizes after 2 edits
When the constant is defined and holds a truthy value
Only the original values are stored in both backup sizes and sources when the constant is defined with a truthy value, which seems very closely to what you are describing on the ticket.
Please let me know what's the result once you run your tests on your end.
@mitogh The constant IMAGE_EDIT_OVERWRITE is not defined in my environment (I'm using the built-in testing environment from the Performance Lab plugin).
After further testing, I've verified the issue I originally reported is indeed valid. However, it only happens when restoring an image. It does not happen when doing multiple edits to an image, that all works fine.
Please review all of the following data. First I have the data for doing multiple edits, all of which looks right. Then, the data for doing one edit and restoring the original - that one is the problem. I've updated the issue name to clarify the bug is only about restoring.
Doing multiple edits
Here's what I'm seeing, after uploading a new image (ID 4).
After doing a single edit and saving that
File name with hash for the new edit
waffles-e1650305671682.jpg
Output of wp post meta get 4 _wp_attachment_backup_sizes
Here is where the problem lies. Compare backup sizes with backup sources. Backup sizes contains references to the edit made to the image (hash e1650306573387, stored under a random new hash per core behavior). But backup sources doesn't contain any reference to it, meaning that edit is now lost when it comes to our _wp_attachment_backup_sources storage.
changed the title [-]Ensure edited image sources are backed up when making further edits or restore[/-][+]Ensure edited image sources are backed up when restoring the original image[/+]on Apr 18, 2022
@mitogh I've updated the issue title and description based on my finding above. The bug is still valid, but it only happens when restoring the original.
Here is where the problem lies. Compare backup sizes with backup sources. Backup sizes contains references to the edit made to the image (hash e1650306573387, stored under a random new hash per core behavior). But backup sources doesn't contain any reference to it, meaning that edit is now lost when it comes to our _wp_attachment_backup_sources storage.
Oh got it this is only on the new meta added by this plugin. Thanks, let me take a look at this issue.
Activity
felixarntz commentedon Apr 14, 2022
FYI @adamsilverstein @mitogh
mitogh commentedon Apr 15, 2022
Hey! @felixarntz thanks for opening this issue, I did some tests and apparently looks like this behavior is the same as having
IMAGE_EDIT_OVERWRITEdefined totruewould you mind double check that you have this constant not defined or set tofalse, not defined is the default state of this constant.When the constant is defined and holds a truthy value, no additional edited images are stored in either the backup sizes and backup sources meta.
This is value when
IMAGE_EDIT_OVERWRITEis not defined or when the value is a falsy value when running your steps with the latest changes from production 3bd51d1.When the constant is defined and holds a truthy value
Only the original values are stored in both backup sizes and sources when the constant is defined with a truthy value, which seems very closely to what you are describing on the ticket.
Please let me know what's the result once you run your tests on your end.
felixarntz commentedon Apr 18, 2022
@mitogh The constant
IMAGE_EDIT_OVERWRITEis not defined in my environment (I'm using the built-in testing environment from the Performance Lab plugin).After further testing, I've verified the issue I originally reported is indeed valid. However, it only happens when restoring an image. It does not happen when doing multiple edits to an image, that all works fine.
Please review all of the following data. First I have the data for doing multiple edits, all of which looks right. Then, the data for doing one edit and restoring the original - that one is the problem. I've updated the issue name to clarify the bug is only about restoring.
Doing multiple edits
Here's what I'm seeing, after uploading a new image (ID 4).
After doing a single edit and saving that
File name with hash for the new edit
Output of
wp post meta get 4 _wp_attachment_backup_sizesOutput of
wp post meta get 4 _wp_attachment_backup_sourcesThis all looks right. The original sources data is saved within backup sizes and backup sources.
After doing another edit to the same image and saving that
File name with hash for the new edit
Output of
wp post meta get 4 _wp_attachment_backup_sizesOutput of
wp post meta get 4 _wp_attachment_backup_sourcesSo this actually all looks right. Both the original sources data and the first edit's data is saved within backup sizes and backup sources.
Doing one edit and then restoring
Here's what I'm seeing, after uploading a new image (ID 5).
After doing a single edit and saving that
File name with hash for the new edit
Output of
wp post meta get 5 _wp_attachment_backup_sizesOutput of
wp post meta get 5 _wp_attachment_backup_sourcesThis all looks right. The original sources data is saved within backup sizes and backup sources.
After restoring the original
File name (now back to the original)
Output of
wp post meta get 5 _wp_attachment_backup_sizesOutput of
wp post meta get 5 _wp_attachment_backup_sourcesHere is where the problem lies. Compare backup sizes with backup sources. Backup sizes contains references to the edit made to the image (hash
e1650306573387, stored under a random new hash per core behavior). But backup sources doesn't contain any reference to it, meaning that edit is now lost when it comes to our_wp_attachment_backup_sourcesstorage.[-]Ensure edited image sources are backed up when making further edits or restore[/-][+]Ensure edited image sources are backed up when restoring the original image[/+]felixarntz commentedon Apr 18, 2022
@mitogh I've updated the issue title and description based on my finding above. The bug is still valid, but it only happens when restoring the original.
mitogh commentedon Apr 23, 2022
Oh got it this is only on the new meta added by this plugin. Thanks, let me take a look at this issue.