Perform updates on secondary image mime types when original image is edited

[mitogh]

Scenario

When an image is uploaded into WordPress at least 2 mime types would be created according to with:

• When uploading, generate both WebP and jpeg format images by default #142

After the image completes the update into the media library, the image would be stored using at least 2 mime types, for this scenario let's use:

• image/webp
• image/jpeg

For simplicity, we are going to call webp the primary image format and jpeg the secondary image format.

After an image is uploaded edits can be performed against this image, when using the image editor (see attached image) or from within the Gutenberg editor.

• rotation
• flip
• crop

After an edit is performed in the original image the original sizes are stored inside of _wp_attachment_backup_sizes and the files preserved to allow a restore of the files in case required. Subsequent edits (if more than a single update is performed) would be stored in the _wp_attachment_backup_sizes keeping _wp_attachment_metadata data with the last edit so the image always reflect the last action performed by the user.

Recreate image in secondary image format for every edit

For every edit performed on the original image, a primary image format would be stored (WordPress default behavior).

So the questions come into place: Should the secondary image format recreate the same edit format and keep the original secondary format the same way it happens with the primary image format.

This behavior is consistent with the primary image format. In case an image is requested with the secondary format the image would be displayed in the same way as the primary image format.(with the edits applied to the original image)

Notes

• Image edits should include the suffix e-$id where $id is a 13 digit number specifically time() . rand( 100, 999 ) created by WP to reference any additional edit that is no longer relevant, the file name is important so WP can identify images that reference to edits and can be removed accordingly based on the definition and value of IMAGE_EDIT_OVERWRITE This suffix is also included as part of the image size name.

[adamsilverstein]

Thanks for opening this @mitogh - we absolutely need to make sure all these function work as expected with the additional mime types. It makes sense that we would want to create crops for each mime format the image was stored in.

I'm interested in investigating how editing interacts with the idea of storing the additional mime types as backup images, once your POC is further along I will test that.

[mitogh]

Thanks, @adamsilverstein just updated the original PR to address this use case as well:

• Store the backup JPEG images in _wp_attachment_backup_sizes #154

Let me know in case you have any additional feedback.

[mxbclang]

@mitogh Checking in here – it looks like #154 was closed in favor of #147, which has now been merged. Is there additional work needed for this issue?

[mitogh]

Great question @bethanylang yes #154 was closed due we are using a different mechanism now, the work for this ticket still needs to be implemented as the previous #154 was using an approach that at the end was not used. #147 only has a foundation when an image is uploaded, the work remaining for this ticket is to make sure the same structure is followed when an image is edited.

I've updated the labels for this ticket to indicate the correct status and removed my assignment in case someone else wants to take over it, in case no one has the allocation to work on this I can try to get it back next week.

[mxbclang]

Noting that @kirtangajjar is taking this one on, but we've having some permissions issues that aren't letting me assign him. I'm working with the meta team to clear this up.

[mxbclang]

Noting that this has been split into two issues: this issue, to generate secondary images with edits; and #228, to update restore and backup image sizes with sources for edited images.

[kirtangajjar]

@mitogh I've created a WIP PR at - #235

[mitogh]

Thank you @kirtangajjar for getting this draft PR and for your work on this one.

Let me take a quick look so I can provide some earlier feedback.

[felixarntz]

@mitogh You were mentioning you already started a follow-up PR to better support the individual targets for editing images. Could you also create a separate follow-up issue for that? So we can consider this one complete? Particularly because this here is gonna go in the upcoming release, while the other one probably won't be ready in time.