Skip to content Skip to sidebar

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 17:00 10:00 – 17:00 10:00 – 17:00 10:00 – 17:00 10:00 – 17:00 -
- 18:00 – 19:00 18:00 – 19:00 18:00 – 19:00 18:00 – 19:00 18:00 – 19:00 -

Supporter timezone: Asia/Kathmandu (GMT+05:45)

This topic contains 1 reply, has 0 voices.

Last updated by Shekhar Bhandari 3 weeks, 4 days ago.

Assisted by: Shekhar Bhandari.

Author Posts
April 1, 2026 at 12:37 pm #17943136

jonathanG-26

WPML Version: 4.9.2 (also present in 4.8.5)
Environment: WordPress 6.x, WooCommerce, WPML Multilingual CMS + WooCommerce Multilingual

Steps to Reproduce:

1. Have a published product with a translation (e.g. English + French)
2. Edit the English product — change the product name and URL slug
3. Save the product
4. The translation becomes unlinked from its English source in WPML
5. Attempting to reconnect via "Connect with translations" fails — WPML flags a conflict

Root Cause:
The method maybe_retrive_trid_again() in inc/actions/wpml-tm-post-actions.class.php (line 211) has two issues:

private function maybe_retrive_trid_again( $trid, $post ) {
global $wpdb, $sitepress;
$element_type_from_trid = $wpdb->get_var(
$wpdb->prepare(
"SELECT element_type FROM {$wpdb->prefix}icl_translations WHERE trid=%d",
$trid
)
);
if ( $element_type_from_trid && $post->post_type !== $element_type_from_trid ) {
$trid = $sitepress->get_element_trid( $post->ID, 'post_' . $post->post_type );
}
return $trid;
}

Issue 1 — Type comparison mismatch (line 214):
$post->post_type returns e.g. product, but $element_type_from_trid returns e.g. post_product. These will never match, so the condition is always true when a trid exists. The comparison should be: 'post_' . $post->post_type !== $element_type_from_trid

Issue 2 — Unfiltered SQL query (line 213):
The query SELECT element_type FROM wp_icl_translations WHERE trid=%d returns the first row for that trid without filtering by element_type. If a trid has been corrupted (e.g. contains both a post_product and a post_page entry), the returned element_type is unpredictable and can cause cascading unlinking.

Suggested fix:

private function maybe_retrive_trid_again( $trid, $post ) {
global $wpdb, $sitepress;
$element_type = 'post_' . $post->post_type;
$element_type_from_trid = $wpdb->get_var(
$wpdb->prepare(
"SELECT element_type FROM {$wpdb->prefix}icl_translations WHERE trid=%d AND element_type=%s",
$trid,
$element_type
)
);
if ( ! $element_type_from_trid ) {
$trid = $sitepress->get_element_trid( $post->ID, $element_type );
}
return $trid;
}

Impact:
- Translation links are silently broken after a slug rename
- Cannot be fixed from the WPML admin UI — requires direct SQL correction

April 3, 2026 at 6:56 am #17947387

Shekhar Bhandari
WPML Supporter since 03/2015

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

Thank you for contacting WPML support. I'd be happy to assist you on this issue.

To help you further on this issue, I would need further information, so could you please go to WPML > Support > Debug Information and give me the information in the next reply. You can read the detailed instruction here: http://wpml.org/faq/provide-debug-information-faster-support/

I tried the same steps as you mentioned and I couldn't reproduce the issue, is English secondary language on your site?

Further, Have you tried disabling all non-WPML plugins, switching to one of the default themes, and checking whether the issue still persists or not?

Please remember to create a backup of your site (both files and the database) before making any updates or changes. This is always a good practice.

Look forward to your reply.

Thanks

The topic ‘[Closed] trid collision in maybe_retrive_trid_again() causes translation unlinking after slug rename’ is closed to new replies.