Support » Plugin: Image Regenerate & Select Crop » Integration with EWWW Resize settings

  • Resolved Gal Baras

    (@galbaras)


    When Image Regenerate & Select Crop is installed together with EWWW Image Optimizer, it seems to ignore thumbnail sizes disabled by EWWW (Resize tab).

    Can you please make the two plugins work together well? This may just be a matter of hook priority, but at the very least, look for these settings and copy them during activation, unless that’s already been done once (I hope this is clear).

Viewing 14 replies - 16 through 29 (of 29 total)
  • 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.

    Plugin Author Iulia Cazan

    (@iulia-cazan)

    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

    Plugin Author Iulia Cazan

    (@iulia-cazan)

    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 1 month, 2 weeks 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 1 month, 2 weeks 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.

    Plugin Author Iulia Cazan

    (@iulia-cazan)

    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.

    Plugin Author Iulia Cazan

    (@iulia-cazan)

    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.

Viewing 14 replies - 16 through 29 (of 29 total)
  • You must be logged in to reply to this topic.