Enable Media Replace does not submit a new image optimization request (7.8)

Hello LiteSpeed Team,

I believe I found a regression in LiteSpeed Cache 7.8 related to Image Optimization after replacing an image using Enable Media Replace.

Environment

• WordPress
• LiteSpeed Cache 7.8
• Enable Media Replace
• QUIC.cloud Image Optimization enabled

Steps to reproduce

1. Upload an image.
2. Optimize it successfully (WebP is generated).
3. Replace the image using Enable Media Replace.
4. The optimization data is reset correctly.
5. The new image is never automatically submitted to QUIC.cloud.

Investigation

I traced the Image Optimization process and added several debug logs to the plugin source.

The following functions are executed correctly during image replacement:

• wp_update_attachment_metadata()
• _append_img_queue()
• _save_raw()

The replaced image is successfully inserted into the database table:

wpif_litespeed_img_optming

The debug log also shows:

Image replaced, resetting optimization data [pid XXXXX]

However, during the image replacement process, new_req() is never called.

I added a debug line at the beginning of new_req(), but it never appeared in the LiteSpeed debug log during the entire replacement process.

To verify this, I added the following debug line at the beginning of new_req():

self::debug(‘>>> new_req start <<<‘);

This message never appears in the debug log.

As a result, the image remains in wpif_litespeed_img_optming and is never submitted to QUIC.cloud unless I manually click “Send Optimization Request” from the Image Optimization page.

Expected behavior

After an image is replaced, LiteSpeed Cache should automatically submit a new optimization request to QUIC.cloud.

Actual behavior

The optimization queue is created successfully, but the automatic submission step never occurs.

Additional information

The optimization data is correctly reset and the image is added to the working queue, so the issue appears to occur after _save_raw(), where the request should normally be submitted.

I can consistently reproduce this behavior on my staging site.

Could you please confirm whether this is an intended behavior or a regression introduced in LiteSpeed Cache 7.8?

If needed, I can also provide the LiteSpeed debug log and additional screenshots.

Thank you for your time.