Integration with EWWW Resize settings

Oh that’s a good thought, we certainly ought to be able to hook on there and remove those records from the ewwwio_images table. We already do something similar when an attachment is deleted from the media library, so it shouldn’t be terribly difficult to implement.

Hi
The new version is available, it includes the discussed changes.
Please test and let me know how it goes.

Regards,
Iulia

Hi Iulia,

I can see the setting to copy from EWWW, but I don’t see that it’s working.

Sorry,
Gal

You have to change one setting in either one of the plugins related to ignoring images and then check if the other plugin picked that up. The integration is more of a “listener” of changes in one of the two plugins

• This reply was modified 5 years, 5 months ago by Iulia Cazan.

Gotcha. Yeah, it synchronizes both ways. NICE!

You might want to do a sync when the setting is turned on, though, for completion.

• This reply was modified 5 years, 5 months ago by Gal Baras.

That’s fantastic, will be working on the filters next week in EWWW IO!

I was working on the sirsc_image_file_deleted hook and it wasn’t getting run during my testing.
Specifically, I’m going to the media library, clicking Image Details, and using the trash icon to remove individual sizes.

This calls the sirsc_ajax_delete_image_sizes_on_request function, which in turn calls execute_specified_attachment_file_delete. While the former has an action hook, it does not pass the filename, and the latter function does not run the sirsc_image_file_deleted action.

Just to try it out, I added that action into execute_specified_attachment_file_delete and our hook function (ewww_image_optimizer_file_deleted) runs properly.
If there are other ways that IRSC removes images (besides batch removing a particular size for ALL images), let me know and I’ll test those also.

I was just looking through the updated code with sirsc_image_processed and sirsc_attachment_images_processed hooks.
As mentioned, the latter is the one I would prefer to use, but it doesn’t seem to run in all cases.
Particularly, if someone just runs a regen for one size, it appears that sirsc_image_processed is the one which runs.

So, we could hook onto both, but it looks like when someone regenerates a particular size for ALL attachments, then both hooks run, and that would end up with duplicate effort and race conditions.

Since the batch/bulk processor runs both hooks, would it be acceptable to have both hooks run in the other case also, where it’s doing regen for one size for one attachment?
For reference, I’m specifically looking at the expose_image_after_processing() function. I’m also wondering if sirsc_image_processed needs to be run by the expose_image_after_processing() function, since it calls make_images_if_not_exists() which triggers that same hook via process_single_size_from_file().
Perhaps expose_image_after_processing() should ONLY be triggering sirsc_attachment_images_processed?

any thoughts on what I had posted? I’ll do a new thread if this one got lost somehow, but hopefully that’s not necessary.

It’s fine, I will take a look at this in the next few days and will get back to you. In the meanwhile, I saw changes after changes in the core for 5.3.

Ah good, just wanted to make sure it wasn’t forgotten since the thread was marked resolved ??
Also noticed some of your comments on a trac issue for 5.3 regarding finding the “original image” when WP scales it down.
If you need to get the path of that original image, it’s contained in the attachment meta at in the original_image array index.
Additionally, WP core added this function which will always return the “full-size/original” version of the image: wp_get_original_image_path()
If original_image exists, it returns that, otherwise it returns the full image.

Hi Gal & Shane,

I just released the 5.3 version, with the most recent changes that finalize the integration with EWWW IO.

Please upgrade and review. Let me know if all is working as expected.

Regards,
Iulia

Hi Iulia & Shane,

When regenerating a single thumbnail, the WebP version is not recreated, even if I delete it first.

When regenerating all the thumbnails for a single image, only some of the WebP versions were created.

In both cases, re-optimizing those images creates fresh WebP versions.

Something is still missing, I’m afraid.

Cheers,
Gal

Hi all, I will be looking into this eventually, unless @iulia-cazan beats me to it. Just been wrapped up in server migrations this week and have been getting way behind on things.

On a single size regen, I still don’t see sirsc_attachment_images_processed being triggered, so that explains that one.

But the full-attachment regen issue, is because IRSC doesn’t delete files during a regen (only overwrites them). Thus only those thumbs which are modified (or previously unoptimized) during the regen will get new .webp from EWWW IO.
On my test image, doing a regen of all the thumbs resulted in .webp versions created except the original, because the generated thumbs were all larger than the previously optimized thumbs.

Essentially, it all goes back to our email conversation about EWWW IO refusing to re-optimize an image unless the filesize is modified from what the plugin previously recorded in the db.

@iulia-cazan can we get sirsc_attachment_images_processed triggered on line 2920 of image-regenerate-select-crop.php? That would be right after a regen for a single thumb is completed, directly after do_action for sirsc_image_processed.