update_meta_cache() fails for 'term' meta type

[doublesharp]

After the update to WordPress 4.4 I began seeing lots of error messages in my logs like the following:

[10-Dec-2015 13:41:14 America/Los_Angeles] WordPress database error Unknown column 'meta_id' in 'order clause' for query SELECT term_id, meta_key, meta_value FROM wp_termmeta WHERE term_id IN (6) ORDER BY meta_id ASC made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/themes/my_theme/page.php'), dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, LocationBased_Featured_Listings_Widget-
widget, get_permalink, get_the_category, get_the_terms, wp_get_object_terms, update_termmeta_cache, update_meta_cache, W3_Db->query, W3_DbCache->query, W3_DbCallUnderlying->query, W3_Db->query, W3_DbProcessor->query, W3_Db->default_query

Looking at the update_meta_cache() method it looks like the new "term" meta type is not using the correct "$id_colum". From line 820 in meta.php

// Get meta info
$id_list = join( ',', $ids );
$id_column = 'user' == $meta_type ? 'umeta_id' : 'meta_id';
$meta_list = $wpdb->get_results( "SELECT $column, meta_key, meta_value FROM $table WHERE $column IN ($id_list) ORDER BY $id_column ASC", ARRAY_A );

The error is fixed by changing the "$id_column" to "term_id", however "meta_id" does exist on this table, it just isn't part of the select, so I'm not sure if this is the right way to fix the issue.

$id_column = 'user' == $meta_type ? 'umeta_id' : ( 'term' == $meta_type ? 'term_id' : 'meta_id' );

[boonebgorges]

Hi @doublesharp - Thanks for the report. It appears that you're using a database dropin, perhaps provided by w3-total-cache. In my initial tests using w3-total-cache's dropin, I'm not able to reproduce your error. But it's possible that you're using a different version of the library that is not forward-compatible for some reason. I recommend you contact the plugin author for support.

(For what it's worth, SELECT term_id FROM wp_termmeta ... ORDER BY meta_id should not cause MySQL errors, as long as the wp_termmeta table does indeed have a meta_id column. This is another thing to check.)

Going to close this on the assumption that it's not a core issue, but if you boil it down to something that core is doing so as not to play nicely with your dropin, please feel free to reopen with details.

[doublesharp]

Some valid points for sure... I did a bit more research (your mentioning the query being able to work with meta_id in the select reminded me that I thought about that earlier) and it turns out the real issue is that somehow the "meta_id" column" ended up being named "tmeta_id". The other sites that I host all have the correct "meta_id" column name (with similar plugins installed) so I'm not sure what's different. Renaming the column fixed the issue.

Thanks!

[coke4all]

interesting: I have the same problem and the same invalid "tmeta_id" column name. Any idea, how this happened?

Kind Regards,
Björn