Automattic/regenerate-thumbnails

Regenerating Images Edited by User.

Opened this issue ยท 12 comments

ddur commented

After function "wp_create_image_subsizes" scales or rotates original image on upload/regenerate, and file is then EDITED by user (cropped/resized/flipped etc), function "wp_get_original_image_path" will return ORIGINAL image path instead of EDITED/attached file path. Regenerate (again "wp_create_image_subsizes") using ORIGINAL image path, will destroy EDITED file metadata, and attach wrong (scaled/rotated) file as post attachment.

My proposal is not to use "wp_get_original_image_path" if get_attached_file( $this->attachment->ID ) is EDITED

Thanks.

Thanks for the report!

Could you add some clear steps for how to reproduce and see this issue? Here is what I am doing:

  • Upload an image.
  • Generate thumbnails.
  • Edit the image (rotate, flip, etc).
  • Regenerate the thumbnails.

It seems when I do that, the new thumbnails are fine, and the old files from before the edit are also still on the server with a different name.

ddur commented

That is correct, but you are missing one step mentioned above (scale or rotate) that will set $image_meta['original_image']. When $image_meta['original_image'] is set, "wp_get_original_image_path" will return uploaded image instead of currently attached image. Which is OK when image is not further edited by user. Original image will be again (optionally) scaled or rotated and attached image updated.

To trigger setting of $image_meta['original_image'], you have to upload JPEG image, either:

  1. Larger than 2560x2560 (see: /wp-admin/includes/image.php line 271) to scale
  2. With $exif_meta['orientation'] !== 1 (see: /wp-admin/includes/image.php line 311) to rotate

Thanks.

ddur commented

@alexsanford Feedback is here. Any question?

Hi. Thank you for the feedback, and sorry for the delay.

That is correct, but you are missing one step mentioned above (scale or rotate)

Can you elaborate clearly on how to do this, from the UI, in a way that causes this issue to be seen?

As per my steps above, I am editing the image, both scaling and rotating. I appreciate your description of what is happening in the code, as that will be helpful when coming up with a solution. But first, for the purpose of debugging, we need to have clear steps on how to see the issue happening.

When I follow the above steps, which include scaling and rotating the image, I see the original files and the edited versions on the server, and I see the edited version in the media library. This is what I expect, and so I do not yet see the problem.

Is this related to an image that is being displayed in a post? If so, I would suggest testing with the Regenerate Thumbnails plugin disabled to see whether that fixes the problem. When images are edited (scaled, rotated, etc) the thumbnails should be regenerated automatically without the use of this plugin. If the problem only exists when this plugin is installed, it would be very helpful to know the exact steps you took to see it, and exactly what you saw.

Thank you for your help in getting to the bottom of this!

ddur commented

@alexsanford

Here is the simpler version even for occasional programmers to understand:

Test case 1, Step 1

As first step, just upload JPEG image that is larger than your current setting for 'big_image_size_threshold' (default is 2560 pixels). That would trigger automatic SCALING of image, on upload (see function wp_create_image_subsizes() in image.php).
Make sure that your 'big_image_size_threshold' filter is not disabled or has value higher than your image pixel sizes.

Test case 2, Step 1

Another test would be to upload JPEG image with exif metadata [orientation] set to 2, 3 or 4. That would trigger automatic ROTATING of image on upload (see function wp_create_image_subsizes() in image.php), regardless of 'big_image_size_threshold'.

Further Test Steps for Cases 1 & 2

Step 2: Edit the image (resize, rotate or flip etc) to get new metadata [sizes] set with edited images (where names are changed by new dimensions (WxH) and suffixing base-name with '-e' + 13 numeric characters).

Step 3: Regenerate the thumbnails.

Result: As far as I can read the code, edited image won't be attached anymore and in attachment metadata, edited thumbnails will be replaced with original thumbnails as created at upload.

Preconditions to be met:

This case is related only to NOT PNG ( == JPEG and maybe more) images.

This case is related only to WordPress version 5.3 and above, which had substantially screwed up all regenerating image sizes plugins and WP-CLI media regenerate almost beyond repair.

Thank you. I was able to reproduce this with the following steps on a default WordPress 5.4.2 installation with the following steps:

  • Upload a large JPG image. One dimension must be higher than 2560. It must be a JPG, not a PNG (it's possible that other formats have the same problem).
  • Edit the uploaded image (rotate or flip will make it most obvious).
  • Regenerate thumbnails for the image using this plugin.
  • After regenerating, the image in the Media Library is reverted to the pre-edited version.

Note that I was also able to see this issue using wp media regenerate <attachment-id> to regenerate the thumbnails instead of this plugin. Because we use the same underlying code, I suspect the issue is in WordPress itself, and not this plugin. I'll leave this issue open to investigate more deeply, but it's possible we won't be able to fix it here. It may be worth reporting this issue on the wp-cli media-command repo.

ddur commented

Actually, WP code was designed only for upload, never actually designed to allow for regenerate, nor (re)designed be compatible with regenerate functionality plugins, or CLI.

WP version >= 5.3 just made it much worse & harder for regenerate function.

ddur commented

@alexsanford
@yscik

  1. I really doubt that this will be soon or ever fixed within WordPress code, because either of:
    a) Fixing would require removal of 'scaling' and 'rotating' functionality around "big_image_size_threshold" filter. Only disabling "big_image_size_threshold" filter for 'scaling' would be partial solution because won't fix same issue for 'rotating'. BTW, automatic 'rotating' is implemented for thumbnails too. I can't predict whether WP developers may come out with other creative solution.
    OR
    b) WP code would have to take care of regenerating images. Which would made obsolete all regenerate-plugins.

  2. As far as I can tell, you have at least two options to fix this:
    a) Skip preprocessed and then edited images (asap?). That would prevent further damage to users image data. At least until other solution is found (maybe this one below).
    b) Regenerate thumbnails from original-image, backup those sizes (same as image-edit.php does, see '_wp_attachment_backup_sizes' ) and then regenerate thumbnails using image edited by user.

Any update on this issue?

ddur commented

@vijayhardaha

Any update on this issue?

Regenerate images with Warp iMagick plugin installed and it will be OK.

There is another report about this issue in the forum, with a suggestion to skip edited images.

ddur commented

Hi @renatho

There is another report about this issue in the forum, with a suggestion to skip edited images.

Same as suggested at the post here, point 2.a), two years ago