Fix “element_id and type do not match for table ‘icl_translations’” in WPML

Getting a blank screen and, in your error log, something like “element_id and type do not match for table ‘icl_translations’”? In plain English, WPML found a translation record in icl_translations that doesn’t match the real content it belongs to. It throws a fatal error to avoid further corruption. The good news: you can usually fix this by cleaning up a few bad rows and letting WPML rebuild them.

WPML is throwing “element_id and type do not match for table 'icl_translations'” and my site goes white. What does this mean, and how can I fix it safely?

If you’re wondering what’s broken: WPML is trying to set language data for a piece of content, but the matching row in icl_translations says it’s a different kind of thing.

Why this error shows up

The full error usually looks something like this (in your log or on screen):

PHP Fatal error: Uncaught InvalidArgumentException: element_id and type do not match
for element_id: 33991 the database contains post_attachment while this function was
called with post_product in .../class-wpml-set-language.php

In plain English:

“For this element_id, icl_translations says it’s one type, but WPML was called with another.”

For example:

  • The database says post_attachment but WPML is treating it as post_product.
  • The database says tax_nav_menu but WPML is treating it as tax_category.

That usually happens because of:

  • A corrupt or “ghost” row in icl_translations.
  • Changing post types or taxonomies (themes/plugins) after content was translated.
  • Imports/migrations from other multilingual plugins (like qTranslate X) or manual DB edits.
  • Older WPML versions that wrote bad data and now expose it after an update.

WPML made this a hard failure on purpose so you notice the problem and fix the bad data instead of letting it grow.

Before you touch anything

  • Take a full backup (files + database).
  • Make sure you’re running a recent WPML version (4.6.7 or newer) where this fatal is better handled. You can see it mentioned in the WPML 4.6.7 changelog.

Then pick the path that matches your situation.

If you can still access your WP admin

If the admin loads (or loads after a refresh), use WPML’s built-in repair tools first. They fix most mismatches without touching the database directly.

Step 1: Run WPML’s “Fix post type assignment” tool

Do this:

  1. Go to WPML → Support.
  2. Click the Troubleshooting link.
  3. Scroll down to the Clean up section.
  4. Click Fix post type assignment for translations.

Wait for it to finish. This goes through icl_translations and fixes rows where the element_type doesn’t match the actual post type/taxonomy.

Step 2: Remove “ghost” translation rows

If the fatal still happens after Step 1, try cleaning orphaned records.

Do this:

  1. On the same Troubleshooting page, click Remove ghost entries from the translation tables.
  2. Let it run to completion.
  3. Test the page/action that was triggering the error again.

Sometimes you’ll need to run these tools more than once, especially on older or heavily migrated sites. If the error goes away, you can stop here.

If you can’t access WP admin (white screen)

If the fatal error blocks your dashboard completely, you’ll need to touch the database directly just long enough to get back in.

Step 1: Find the offending element_id

Check your error log or the error output. You’re looking for a line like this:

element_id and type do not match for element_id: 777
the database contains post_attachment while this function was called with post_product

Make a note of the element_id number (in this example, 777).

Step 2: Remove the bad row from icl_translations

Only do this with a backup in place.

Do this:

  1. Open your database in phpMyAdmin (or a similar tool).
  2. Open the wp_icl_translations table (or your custom prefix).
  3. Search for rows where element_id equals the ID from the error (for example, 777).
  4. Delete that row (or rows, if there are multiple with that exact element_id).
  5. Save/confirm the change.

Now load your site again.

  • If the dashboard loads, immediately go to WPML → Support → Troubleshooting and run:
    • Fix post type assignment for translations
    • Remove ghost entries from the translation tables
  • If a new fatal appears with a different element_id, repeat the same process for that ID as well, then run the tools again.

Deleting a bad row won’t delete the actual post/page; it only removes the broken translation link so WPML can recreate it correctly.

If the error keeps coming back with lots of IDs

If every refresh just shows a new element_id, you may have widespread corruption (for example, after a broken migration or failed install).

At that point, you have two realistic options:

  • Keep removing individual rows and running the Troubleshooting tools until things stabilize.
  • Consider a WPML reset and re-setup if this is a new install with no real translation work yet.

For a full reset, you can follow the approach documented by WPML users in the official errata: reset language data from WPML → Support → Troubleshooting, deactivate, then reactivate and reconfigure WPML.

If you migrated from qTranslate or another multilingual plugin

This error is common after importing from plugins like qTranslate X using an importer.

What happens is:

  • The importer creates WP content (posts, events, taxonomies).
  • WPML then tries to link them in icl_translations.
  • A few entries are created with the wrong element_type (for example, treating an attachment as an event).

If you see this only during or right after an import:

  1. Note the offending element_id from the error.
  2. Clean that entry from icl_translations as described above.
  3. Re-run the import or re-save the affected content so WPML can create the translation link correctly.

If every re-run hits different IDs, stop and consider reaching out to WPML support with your import logs so they can check the mapping logic.

Verification: how to know it’s fixed

You’re in good shape when:

  • The site loads without a fatal error, both on the front-end and in WP admin.
  • WPML pages (Languages, Translation Management, etc.) open without crashing.
  • No new “element_id and type do not match” entries appear in your error log when you:
    • Save posts/pages.
    • Sync menus.
    • Run translations or imports.

Still stuck?

For AI help

Hit Continue Chat and paste:

  • The full fatal error message (including the element_id and types mentioned).
  • Whether you can access WPML → Support → Troubleshooting or not.
  • Whether you recently migrated from another multilingual plugin or changed post types/themes.

I’ll help you pick the safest next step.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.

Need human WordPress help?

WP Assistant is a free tool created by Atiba Software, a WordPress design and development company located in Nashville, TN. If you need more personalized WordPress assistance let us know, and we’ll get back to you ASAP!