@r-a-y After a bit more debugging I’ve traced the route of the problem to the updated, “bp_filter_metaid_column_name” function in /bp-core/bp-core-filters.php. The updated function includes a new regex:
function bp_filter_metaid_column_name( $q ) {
/*
* Replace quoted content with __QUOTE__ to avoid false positives.
* This regular expression will match nested quotes.
*/
$quoted_regex = "/'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'/s";
preg_match_all( $quoted_regex, $q, $quoted_matches );
$q = preg_replace( $quoted_regex, '__QUOTE__', $q );
$q = str_replace( 'meta_id', 'id', $q );
// Put quoted content back into the string.
if ( ! empty( $quoted_matches[0] ) ) {
for ( $i = 0; $i < count( $quoted_matches[0] ); $i++ ) {
$quote_pos = strpos( $q, '__QUOTE__' );
$q = substr_replace( $q, $quoted_matches[0][ $i ], $quote_pos, 9 );
}
}
return $q;
}
The old function was simply:
function bp_filter_metaid_column_name( $q ) {
return str_replace( 'meta_id', 'id', $q );
}
If I swap out the updated version of this function for the old one everything works fine. Also, if I comment out the regex portion of ‘bp_filter_metaid_column_name’ it works fine as well.
I added some logging to this function and the output seems a bit strange to me. It’s a bit hard to follow, but here it goes:
[06-Feb-2015 18:40:43 UTC] $q First: SELECT activity_id, meta_key, meta_value FROM wp_bp_activity_meta WHERE activity_id IN (404095) ORDER BY meta_id ASC
[06-Feb-2015 18:40:43 UTC] $q Second: SELECT activity_id, meta_key, meta_value FROM wp_bp_activity_meta WHERE activity_id IN (404095) ORDER BY id ASC
[06-Feb-2015 18:40:43 UTC] $q First: SELECT meta_id FROM wp_bp_activity_meta WHERE meta_key = __QUOTE__ AND activity_id = 404095
[06-Feb-2015 18:40:43 UTC] $q Second: SELECT id FROM wp_bp_activity_meta WHERE meta_key = __QUOTE__ AND activity_id = 404095
[06-Feb-2015 18:40:43 UTC] $q Third: SELECT id FROM wp_bp_activity_meta WHERE meta_key = '_bp_akismet_result' AND activity_id = 404095
[06-Feb-2015 18:40:43 UTC] $q First: INSERT INTO <code>wp_bp_activity_meta</code> (<code>activity_id</code>,<code>meta_key</code>,<code>meta_value</code>) VALUES (__QUOTE__,__QUOTE__,__QUOTE__)
[06-Feb-2015 18:40:43 UTC] $q Second: INSERT INTO <code>wp_bp_activity_meta</code> (<code>activity_id</code>,<code>meta_key</code>,<code>meta_value</code>) VALUES (__QUOTE__,__QUOTE__,__QUOTE__)
[06-Feb-2015 18:40:43 UTC] $q Third: INSERT INTO <code>wp_bp_activity_meta</code> (<code>activity_id</code>,<code>meta_key</code>,<code>meta_value</code>) VALUES ('404095',__QUOTE__,__QUOTE__)
[06-Feb-2015 18:40:43 UTC] $q Third: INSERT INTO <code>wp_bp_activity_meta</code> (<code>activity_id</code>,<code>meta_key</code>,<code>meta_value</code>) VALUES ('404095','_bp_akismet_result',__QUOTE__)
[06-Feb-2015 18:40:43 UTC] $q Third: INSERT INTO <code>wp_bp_activity_meta</code> (<code>activity_id</code>,<code>meta_key</code>,<code>meta_value</code>) VALUES ('404095','_bp_akismet_result','false')
The SQL statement appended to the ‘$q Third:’ output is logged from inside the ‘$quoted_matches[0]’ for loop (line 744). I get the idea here is for backwards compatibility between ‘id’ and ‘activity_id’, but shouldn’t it still return the “SELECT’ portion of the SQL query?
Anyhow, I could be completely wrong here, but @r-a-y / @johnjamesjacoby, I’d love to know your thoughts. Sorry for the super long reply
