@dillon To be clear, are you saying that taxonomy meta is not saving? Please provide more details if you can and how to reproduce. Thanks!

Ok, I see what you’re looking for. There’s two ways you could do this:

1. Split your field into three add-more group fields: one for Platinum, one for Gold, one for Silver. Then you simply pull in the meta for each one and they’re grouped how you want them.

2. Sort the group results yourself and then loop through them:

<?php
$groups = get_post_meta($post->ID, 'summit_sponsor_group', true);
$sorted_groups = array();
foreach($groups as $group) {
  if ( !isset($sorted_groups[$group['sponsor_level']] ) {
    $sorted_groups[$group['sponsor_level']] = array();
  }

  $sorted_groups[$group['sponsor_level']][] = $group;
}
?>

<?php if ( !empty($sorted_groups['Platinum']) ): ?>
  <?php foreach($sorted_groups['Platinum'] as $group): ?>
    Platinum groups here
  <?php endforeach; ?>
<?php endif; ?>

<?php if ( !empty($sorted_groups['Gold']) ): ?>
  <?php foreach($sorted_groups['Gold'] as $group): ?>
    Gold groups here
  <?php endforeach; ?>
<?php endif; ?>

<?php if ( !empty($sorted_groups['Silver']) ): ?>
  <?php foreach($sorted_groups['Silver'] as $group): ?>
    Silver groups here
  <?php endforeach; ?>
<?php endif; ?>

You have a few different ways you could accomplish this, but they’ll look somewhat similar like that. This is more efficient than looping through the array multiple times as well.

Hope this helps!

I just noticed something.. in the piklist field you have the 'field' => 'sponsor_level', but then in the template you’re doing $sponsors = get_post_meta($post->ID, 'summit_sponsor_group', true);, which is then what you’re using to compare against the value to determine which section to show. I assume you mean summmit_sponsor_group to be sponsor_level?

When in doubt, dump the value of the variable having the issue and see what value you’re getting. 🙂

Hey @mandelkind!

You should be able to accomplish the API check using the piklist_pre_option_update hook. As far as the notice text goes, however, I’m honestly not sure if you can change that. I’ll do a bit more digging, but Piklist may be using built-in WordPress functionality for that, and I’m not sure there’s a way to change the message. Not saying there isn’t for sure, though. You can, however, add your own notice to display in addition to the other.

Hope this helps!

Hey!

No problem. You’re obviously digging into it more than most and we’re glad to help clarify things.

You’re correct when you say only a single object gets the relation row added to reflect a relationship — in fact it’s the object that belongs to the other that gets the row in its meta table. But, that doesn’t mean the relationships aren’t bidirectional. When you use the 'post_has', 'post_belongs', etc. query vars Piklist internally splits the query into two queries, using the former to determine the object’s relationships (given the direction has/belongs). So either the owner object is in the object’s meta, or the belonging object will have the object’s id in the meta — it works either way and is quite fast.

This would be an example of a multiple select field that relates two posts:

<?php
/**
 * Title: Services Provided
 * Post Type: doctor
 * Context: side
 * Priority: low
 */

piklist('field', array(
  'type'      => 'select',
  'template'  => 'field',
  'choices'   => piklist(get_posts(array(
    'post_type'   => 'service',
    'numberposts' => -1,
    'orderby'     => 'title',
    'order'       => 'ASC'
  )), array('ID', 'post_title')),
  'relate'    => array(
    'scope'     => 'post'
  ),
  'attributes'=> array(
    'multiple'  => 'multiple'
  )
));

Let me know if that clears things up!

Hey @stemuedendron

I believe you’re running into a change between 0.9.5.x and 0.9.9.x. Between the two versions we made it possible to turn any field into a relate field, so long as it ultimately provided an object ID, as well as opening relationships from just posts to all objects (e.g. user to post, as you’re doing).

In 0.9.5.x it was possible to have a field with 'type' => 'relate' and 'field' => 'my_field' which would both store the value as meta and store the relationship. This wasn’t an intended feature, but I admittedly used it a couple times myself and it’s even something we’re considering bringing back.

Now, in 0.9.9.x, relationships work different internally, which is why you’re not limited to the relate field type and can simply add the relate parameter to the field (as you’re doing). This did unfortunately “break” being able to relate and store meta at the same time, but seeing as it wasn’t something that was intentionally supported, it was considered acceptable. All that to say, keeping the 'field' parameter on a relate field now confuses things as relational fields are special. You shouldn’t need the meta as you can simply use the 'user_has','user_belongs', etc., parameter in your queries.

Hope this helps!

Hey @stemuedendron

You shouldn’t need the field parameter on either of them. Try removing that and see if it fixes it.

Hey @friendlyfire3

I would say via configuration no, but via convention yes. 🙂

The relationships within Piklist are really pretty informal, working by a quick and simple convention via the meta tables to determine which object has another. Rather than trying to make Piklist a configuration monster that tries to have a formal way of defining every element of a relationship (i.e. one-to-one, hierarchical, etc.) we went simple and allow developers to take it however they’d want.

All that being said, I’ve done similar sorts of relationships and simple break my overall query into multiple queries, and since I just want the id of the relationship, I limit the query to that (via the wp_query ‘fields’ => ‘ids’ parameter).

$state = get_posts(array(
  'suppress_filters' => false,
  'post_type' => 'state',
  'numberposts' => 1,
  'has_post' => $city->ID,
  'fields' => 'ids'
));

$country = get_posts(array(
  'suppress_filters' => false,
  'post_type' => 'country',
  'numberposts' => 1,
  'has_post' => $state
));

Hope this helps!