[Waiting for user feedback] Some images are being deleted by WPML after translation

Hello,

Your debug backtrace shows the delete call originates in WPML Media Translation’s duplication/cleanup flow, specifically through WPMLMediaTranslation\PostWithMediaFiles and WPML_Media_Attachments_Duplication when WPML thinks an attachment is a duplicated copy to be cleared.

Please try the following:
- Go to WPML → Support → Troubleshooting.
- Run (in this order): Set language information, Fix post type assignment for translations, Assign translation status to duplicated content. Clear caches and retest ATE.

If this does not help, although the backtrace points to WPML it's worth to try the following test. Many times what triggers the problem is a compatibility issue:
**IMPORTANT:** Please try this in a staging environment or at least with a backup of your site files and database before continuing.
Disable all plugins except WPML-related and temporarily change the theme to a default WordPress such as Twenty Twenty-five.
Is the issue resolved with these settings? If so, please reactivate one by one to see which conflicts.

Best Regards,
Otto

Hello,

Yes, I understand how hard and frustrating these kinds of issues are 🙁

You said that it took 22 attempts before you could reproduce the problem. You mean that you saved 22 times the same translation, or you saved 22 different translations until you were able to see the problem?

What kind of images are deleted from the post? I mean, are those regular image attachments or added in a custom field or as a gallery?

In the last version, WPML changed how media is handled:
https://wpml.org/download/wpml-media/?section=changelog
https://wpml.org/changelog/2025/08/wpml-4-8-human-quality-ai-translations/#improved-media-translation

So, which type of media is being deleted can give us a clue.

Did you enable automatic detection in WPML > Settings > Media Translation?

About your questions:

- When does WPML decide to delete an image?
The cleanup runs from the Media module after media auto-handling queues a post for “copied” images. For each image that was duplicated into a translation, WPML checks if the translated attachment still looks redundant (same caption/description/alt as the source). If so, it deletes the translated attachment record.
This deletion is performed by a direct SQL path (not wp_delete_attachment) inside PostWithMediaFiles::delete_duplicated_copied_media → delete_duplicated_attachment. The intent is to remove only the attachment post/meta, not necessarily the physical file.

133:161:/Users/ofwald/Local Sites/for-cursor/app/public/wp-content/plugins/sitepress-multilingual-cms/classes/media-translation/PostWithMediaFiles.php
public function delete_duplicated_copied_media() {
  ...
  if (
    $texts['caption'] !== $translation_texts['caption'] ||
    $texts['description'] !== $translation_texts['description'] ||
    $texts['alt'] !== $translation_texts['alt']
  ) {
    continue;
  }
  $this->delete_duplicated_attachment( $translation->element_id );
}

190:231:/Users/ofwald/Local Sites/for-cursor/app/public/wp-content/plugins/sitepress-multilingual-cms/classes/media-translation/PostWithMediaFiles.php
private function delete_duplicated_attachment( $post_id ) {
  global $wpdb;
  ...
  // Deletes terms/meta, fires delete_post/deleted_post, then:
  $result = $wpdb->delete( $wpdb->posts, array( 'ID' => $post_id ) );
  ...
  return $post;
}

The above focuses on the attachment post/DB. In some environments, other processes can remove files once attachments disappear or if they share paths, but the core cleanup uses SQL (not wp_delete_attachment).

- Will unchecking “When deleting a post, delete translations as well” stop image deletes?
No. That setting affects cross-language post deletion, not the media-duplication cleanup. The media cleanup runs independently under the Media module’s logic.
- If you need an immediate mitigation, try turning off automatic media handling (WPML → Settings → Media Translation → “Automatic image and media detection”).

- Was there an Advanced Translation Editor (ATE) update too?
- ATE is SaaS and gets frequent updates, but the behavior change relevant here is in WPML 4.8’s core/media layer (“automatic image and media detection” and the subsequent duplicate cleanup). So the likely trigger is the WPML core/media update, not ATE itself.

Best Regards,
Otto

Hello,

Thanks for the detailed explanation.

About rolling back. It’s generally safe—but do it carefully and in lockstep.

- What “safe” rollback means
- Roll back WPML core (sitepress-multilingual-cms) and all WPML add‑ons together to versions that were compatible with 4.7.6 (String Translation, Media Translation, WooCommerce Multilingual, ACFML, etc.).
- Always back up database + uploads first and test on staging before touching production.

- Compatibility notes
- WPML 4.8.x added “automatic image/media detection” and some new options/meta. Rolling back to 4.7.6 will simply ignore those extra options; no schema downgrade is required.
- The Advanced Translation Editor (ATE) is SaaS and unaffected by plugin rollback (jobs/translations remain intact).

- Recommended rollback steps
- Staging: restore a backup or snapshot → downgrade WPML core and its add‑ons together via the Commercial tab (OTGS Installer) or zips from your WPML account → clear caches.
- WPML → Support → Troubleshooting: run “Clear the cache in WPML”, “Set language information”, and “Fix element_type collation” to refresh internal state.
- Verify media, translations, and ATE saves work normally; only then mirror the change on production.

- Will this help with the image deletions?
- Likely yes, if the issue started with 4.8.x media changes.

Back to this weird and random issue:

- What actually deletes the file
- The “duplicate cleanup” WPML runs after ATE saves is designed to delete only the translated attachment record (database row), not the physical file. It does this via a direct SQL delete, not WordPress’s wp_delete_attachment.
- However, if any code path ends up calling wp_delete_attachment on that attachment (Core or another plugin/theme reacting to attachment deletion), WordPress will remove the physical file and its sizes. Since your backtrace shows wp_delete_attachment, we need to pinpoint which hook calls it. That’s not the intended cleanup path in current WPML core.

- Why cleanup might incorrectly classify “duplicates”
- WPML evaluates duplicate-ness using the attachment’s own texts (caption, description, and the attachment’s alt meta), not the alt/caption you see inside blocks. If you translate alt in the block only (not in the media library/attachment), the attachment-level texts may still look identical to the source, and the cleanup may consider the translated attachment redundant.
- Your default language is Danish but you create in English. That can increase mapping edge cases (TRIDs/“duplicate-of” links), especially with the automatic media handling introduced in 4.8. That, plus ATE’s asynchronous saves, can make this feel intermittent.

- Why turning off “Automatically detect best options for translating image texts” didn’t stop it
- That toggle doesn’t fully disable the duplicate cleanup.

- On ATE updates
- ATE (the editor) is hosted and updated independently. The behavior change most relevant here came with WPML 4.8’s media/cleanup logic (“automatic image and media detection”). That’s the likely factor, not an ATE change per se.

Best Regards,
Otto

Hello,

You can get previous versions going to wpml.org/downloads, expand "Download manually" and the click on the changelog icon for each plugin. Check the screenshot attached, please.

Yes, the behavior is correct, with the latest version attachments are not duplicated until it's needed.

About, creating content in non-default language. It's supported, I meant that in a complex setup it may increase the chance of failure. But we need to understand how it's failing.

Yes, the ticket will remain open for 2 weeks without activity.

About the code you are pointing as the root cause of the problem. I am not sure... As far as I know, when dealing with attachments, WPML does not handle physical files, it handles them at the DB level. But I'd like to take a better look at the issue. Is it possible for you to provide me with a copy of the site? You can use Duplicator or just a DB dump and the wp-content folder. I am enabling a private reply in case it's OK, so you can share a download link safely. If not, I'd try to reproduce it on a test environment.

Best Regards,
Otto