Lack of forced GROUP BY or DISTINCT in query.php causes duplicate posts when plugins JOIN on wp_posts.ID = wp_post2cat.post_id

[ajd777]

In version 2.0.x DISTINCT was automatically added to all queries that weren't in the admin panel (line 593 of classes.php). However, 2.1 took out this section and doesn't automatically us it or GROUP BY except when viewing single categories (lines 811 (808) and 845 (841) of query.php).

This is an easy fix just add a default filter or force it inside the function to either use GROUP BY ID or DISTINCT by default.

[ajd777]

Replying to ajd777:

In version 2.0.x DISTINCT was automatically added to all queries that weren't in the admin panel (line 593 of classes.php). However, 2.1 took out this section and doesn't automatically us it or GROUP BY except when viewing single categories (lines 811 (808) and 845 (841) of query.php).

This is an easy fix just add a default filter or force it inside the function to either use GROUP BY ID or DISTINCT by default.

As a temporary fix for plugin authors:

function force_groupby ( $groupby ) {

if ( $groupby == ) {

return ' ID';

}

}

add_filter('posts_groupby', force_groupby);

[markjaquith]

Does this need to be fixed in core, or is it reasonable to expect plugin authors to provide a GROUP BY ?

[ajd777]

I think it should be done automatically in the core, but allow it to be removed if needed: mainly because it is rather unexpected for multiple of the same posts to show up by default.

[ryan]

It's a back compat break, which sucks, but removing those speeds up our queries.

[ryan]

Maybe process the query after the filters have run and add GROUP BY (if not present) if a post/cat JOIN is done.

[foolswisdom]

Setting milestone, so ticket is in front of us, but based on most recent comments by Ryan this will be closed as WONTFIX.

[Nazgul]

There is a limit to how far you should take backwards compatibility.

I think I agree with Ryan that in this case the speed benefits outweigh the backwards compatibility issues.