Hey @wpmusketeer !

Sorry you’re having issues with the relate code. I use it all the time in my projects, so I can assure you it does work. I also wrote a lot of the internal Piklist relate code by this point, so hopefully I can help you get this sorted. 🙂

To help you debug, how the relate works is that when you perform a query is grabs all the IDs that the object is related to and limits the results to those IDs. It’s pretty straightforward, so every other aspect of the queries (e.g. post_status) should work as expected. I have very complex queries using post_has and post_belongs, so I’m confident it’s working correctly.

Also, to help you understand, you only need a single relate field to establish a bi-directional relationship. Whatever (in this case) post has the field also has the other post, conversely the other post belongs to the post.

All that being said, I believe your issue is that, in your field, you have:

'relate' => array(
  'scope'   => 'contact'
)

The scope should be post not contact. I assume contact is your post type, but understand that the object relationships don’t care what the post type is, they just care whether it’s a post, user, or comment. So the scope would only ever be one of those three, depending on what you’re relating to.

Hope this helps!

@jivedig: Sorry, you’re just fine with the custom scope. Steve was thinking of a feature that was discussed for the future to support custom tables via scope. But custom scopes for manual processing have been supported for quite a while. You’re not in dangerous territory. 🙂

Unless I misunderstand you, that’s already happening.

Let’s say I have two posts types, the standard blog post type, and an event post type. Now let’s say I want to be able to mark related blog posts whenever I create an event. What we have now is that for every event it has one or more posts; conversely, a given post belongs to one or more events.

So given that, you would retrieve in each direction like this:

// Note: suppress_filters needs to be false as by default get_posts suppresses custom filters

$related_posts = get_posts(array(
  'suppress_filters' => false
  'post_type' => 'post',
  'post_belongs' => $event_id
));

$related_event = get_posts(array(
  'suppress_filters' => false
  'post_type' => 'event',
  'post_has' => $post_id
));

Is this what you’re talking about?

Hey friendlyfire3!

Hmm.. I’m afraid this puts you into a bit of a more complicated issue. You see, the GET endpoint you’re using uses the wp_query, which Piklist hooks into. So it’s a simple matter of using the post_has/belongs arguments in the query, and you’re good to go.

Creating a relation, on the other hand, is unfortunately more complicated, and in more than one way. Like I said earlier, in the version you’re using Piklist stored the relationships in a wp_relationships table. But, since then, it’s changed to the respective meta tables. Now, if you upgrade from one to the next, there’s an upgrade script that runs and stores all your existing relationships into the new form — nothing lost.

So here’s your options to get this working:

• First, keep your current version of Piklist and create a custom POST endpoint that receives two post ids — the owner and one being owned, and have it use the Piklist_Form::relate function to make the relationship. The biggest downside here is that when you do upgrade to a newer version of Piklist, you’ll have to change your code to the next option.
• Second, upgrade to the latest in trunk (which is in beta), and use the post meta endpoint to add the relationships (until we’re able to add some of our own custom endpoints). To create a relationship, you simply add a meta value to the post that <u>belongs</u> to the other. The key would be __post_relate and the value would be the id of the owner. Simple as that.

Glad to see that you’re pushing Piklist to what it can do. Sorry we’re not quite caught up with API stuff, yet. 😀

Hey friendlyfire3!

Awesome! I’m glad that worked! That code won’t be necessary in the next version of Piklist, so let’s modify it so you don’t have any issues when upgrading Piklist in the future:

add_filter('rest_query_vars', function($valid_vars) {
  return in_array('post_has', $valid_vars) ? $valid_vars : array_merge($valid_vars, array('post_has', 'post_belongs');
});

@friendlyfire3: I’m sure about the endpoint. Try using a standard wp_query argument (e.g. post__in) in the filter to make sure filter is working as expected. If another argument is working fine, let me know.