• Hello,

    I believe I have found a reproducible issue in Image Watermark 2.0.11. Environment

    • WordPress 7.0
    • Image Watermark 2.0.11
    • WooCommerce

    The problem

    When uploading images from Media → Add New, everything works correctly:

    • Backup is created in wp-content/uploads/iw-backup/
    • Apply Watermark works
    • Remove Watermark works

    However, when uploading images directly from the WooCommerce product editor (“Set product image” / “Add product gallery images”) the behavior is different.

    The image is uploaded and automatically watermarked, but no backup file is created inside wp-content/uploads/iw-backup/.

    The attachment still receives:

    iw-is-watermarked = 1

    but there is no corresponding backup file.

    Because of this:

    • Remove Watermark returns:
    No watermark backup found for this image.

    and

    • Apply Watermark again returns:
    Watermark not applied because the original backup is missing.

    What we verified

    • backup_image is enabled (backup_image = true).
    • Backup folder exists and is writable.
    • Permissions are correct.
    • No PHP errors are generated.
    • The problem is reproducible only for uploads performed from the WooCommerce product editor.

    Source code observations

    do_backup() appears to be implemented correctly.

    If backup creation fails, the code returns before watermarking:

    $backup_result = $this->do_backup(...);
    
    if (!$backup_result['success']) {
        return $data;
    }

    However, in our case the attachment is already marked as:

    iw-is-watermarked = 1

    while no backup file exists.

    This seems inconsistent with the expected execution flow. Temporary workaround

    We implemented a temporary hook on:

    iw_before_apply_watermark

    which manually creates the backup before the watermark is applied.

    After adding this workaround:

    • Upload from WooCommerce product editor works correctly.
    • Backup is created.
    • Apply Watermark works.
    • Remove Watermark works.

    This suggests that the backup creation step is being skipped (or not executed) for uploads coming from the WooCommerce product media uploader.

    Could you please investigate whether this is a bug in the upload flow for WooCommerce product uploads?

    Thank you!

    The page I need help with: [log in to see the link]

Viewing 1 replies (of 1 total)
  • Plugin Support weiser

    (@weiser)

    Hi Andreas,

    Thank you for the detailed report and for describing your workaround.

    We tested the WooCommerce product-image upload flow locally with WordPress 7.0 and WooCommerce. The image was watermarked, the backup was created correctly, and the watermark could subsequently be removed. WooCommerce’s classic product editor uses the standard WordPress media uploader, so we have not yet been able to reproduce a separate WooCommerce upload path that bypasses backup creation.

    We have just released Image Watermark 2.0.12, which includes substantially improved diagnostics and per-attachment operation reporting. Could you please:

    1. Update Image Watermark to 2.0.12.
    2. Temporarily disable your workaround.
    3. Upload a new image from the WooCommerce product editor.
    4. Before attempting to apply or remove the watermark again, copy the diagnostic information for the affected attachment and the report from Watermark → Status.
    5. Send us the affected attachment ID and the complete code used by your iw_before_apply_watermark workaround.

    If possible, please also test once with only Image Watermark and WooCommerce active. Image optimization, media replacement, offloading, upload-directory filters, cleanup plugins, or custom code using the iw_watermark_options filter could affect the effective backup setting or remove/move the backup after it is created.

    One detail is particularly useful here: internally, backup creation happens before the iw_before_apply_watermark action. If backup creation fails, watermarking stops and that action is not executed. Therefore, the fact that your action-based workaround helps suggests that the backup may be skipped because of filtered settings, written to a different path, or removed later in the request.

    Please keep the affected image unchanged until you have the 2.0.12 installed, as the recorded last-operation details should help us identify exactly which path was taken.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.