Yes, this is true: the relationship is one way. This is the way most databases and frameworks work, e.g. hierarchy is inferred by setting the parent, and that lets you calculate the children.
So you have a couple options: one way to sort of side-step the issue is to use taxonomies… that’s not the same thing as a relation, but at the database level, the structure is very different — it’s outsourced to external tables, so each side of the relationship is treated the same.
The 2nd option would be to do what you’ve done already, but on the 2nd post (the target of the relation), you’ll build something that says “Posts that link here”, and you’ll rely on this template function: http://code.google.com/p/wordpress-custom-content-type-manager/wiki/get_posts_sharing_custom_field_value
Note that this will only work if your relation is a singular field — the multi-relation fields operate differently, so you’d need to do a more complex query.
Thank you for this informative reply. I notice from you’re profile you are a developer and I wonder if you would be interested in implementing one of these solutions for me on the site in question? Would this be something you might attempt, and if so. Do you have an idea of the approximate cost of doing so?
Thanks again for your reply!
Better contact me at http://fireproofsocks.com/contact/ and we can discuss details and deadlines.
Though I like CCTM, this time I would recommend you in this case “Posts to posts” plugin.
It does exactly what you need. It lets you create connection both ways. It creates separate tables for each connection type. So no matter how many post/pages you have it only searches through the connection table.
I feel like this is the proper way how to do such thing..
Hi,
I had a similar problem, and ended up writing a function based on get_posts_sharing_custom_field_value(), but for repeatable fields. it actually turned out to be pretty straightforward. Since they’re stored in the post meta as comma-separated, quoted values, the SQL is a little less performant, but for me it’s well worth the tradeoff.
I’ve pasted the code below FWIW. I also added an option to filter by post_type, as I’m often looking only for one type of post when I use this.
// based on CCTM's get_posts_sharing_custom_field_value(),
// but returns the posts that match anywhere in a repeatable field
// (stored in the db as comma-separated, double-quoted strings)
// - also added a param for filtering by post_type, since it's so common
function get_posts_containing_custom_field_value($fieldname, $value, $post_type = '') {
global $wpdb;
$query = "SELECT DISTINCT {$wpdb->posts}.ID
FROM {$wpdb->posts} JOIN {$wpdb->postmeta} ON {$wpdb->posts}.ID = {$wpdb->postmeta}.post_id
WHERE {$wpdb->posts}.post_status = 'publish'
AND {$wpdb->postmeta}.meta_key = %s
AND {$wpdb->postmeta}.meta_value LIKE %s ";
if ($post_type) $query .= " AND {$wpdb->posts}.post_type = %s ";
$query_prepped = $wpdb->prepare( $query, $fieldname, '%"' . $value . '"%', $post_type );
$results = $wpdb->get_results( $query_prepped, OBJECT );
$completes = array();
foreach ( $results as $p )
{
$completes[] = get_post_complete($p->ID);
}
return $completes;
}
Thanks for posting your code. You could do something equivalent with the GetPostsQuery arguments too.
Re Posts to Posts — yeah, that’s the traditional normalized way of handling this, it just requires new database tables, and the search criteria for choosing the relations aren’t as rich.
