Filtering a multi selct list

I tried this a couple different ways and checked with Scott.

The WHERE clause can’t be used for relationships that are in the process of being created —?the interface doesn’t provide a way to reference back to the originating post before the relationship exists.

The workaround is to filter the relationship field with PHP.

Here’s an example in the form of a plugin, based on https://docs.pods.io/code-snippets/multiple-fields-pick-list/

<?php
/**
 * Plugin Name: Filter Events Relationship
 * Description: Filter Pods meta field "events" relationship field to instances where "official_name" is equal on building and event.
 */

add_filter(
	'pods_field_pick_data',
	function ($data, $name, $value, $options, $pod, $id) {
		if ( 'pods_meta_events' === $name && 'building' === get_post_type( $id ) ) { // Field name: "events", post type "building"

			$building = pods( 'building', $id );
			
			foreach ( $data as $dataid => &$value ) {
				if( $dataid ){
					$event = pods( 'event', $dataid );

					if ( $event->display('official_name') !== $building->display('official_name') ) { // Field name: "official_name"
						unset( $data[ $dataid ] );
					}
				}
			}
		}
		return $data;
	},
	1,
	6
);

The post types above are “event” and “building”. The meta fields are “events” and “official_name”.

• This reply was modified 3 years ago by Paul Clark.

Thank you!

I messed up in my explanation. I listed the field name wrong (It’s actually “building_event”) and I had building as plural instead of singular for the pod name, but, with your code, I was able to figure out what needed to be renamed and install the “plugin” via Pluginception. I even kind of understand what the code is doing. I’m not ready to raise myself up to the level of PHP “novice” yet, that’s probably still too lofty, but this works, and I think I can adapt it should a similar situation arise (my long term plans indicate this will happen!)

I assume If I want to do something similar later, I need to make sure I rename the fields, the pod names, and assign new variable names, so that there is no conflict between the mini plugins?

Great!

Should be enough to rename the field and pod names; variable names are scoped within the anonymous function.

Here’s rewritten version of the plugin that generates the appropriate function with a class:

<?php
/**
 * Plugin Name: Filter Pods Relationships
 * Description: Filter Pods meta fields with a generic <code>Filter</code> class.
 * Version: 2
 */

namespace Filter_Pods_Relationships;

add_action(
	'plugins_loaded',
	function(){
		new Filter([
			'relationship_field_name' => 'events',
			'source_post_type' => 'building',
			'filter_post_type' => 'event',
			'source_meta_key' => 'official_name',
			'filter_meta_key' => 'official_name',
		]);
	}
);

class Filter {
	function __construct( array $args ) {
		add_filter(
			'pods_field_pick_data',
			function ( $data, $name, $value, $options, $pod, $id ) use ( $args ) {
				if ( 'pods_meta_' . $args['relationship_field_name'] === $name && $args['source_post_type'] === get_post_type( $id ) ) { 

					$source_pod = pods( $args['source_post_type'], $id );

					foreach ( $data as $data_id => $value ) {
						if( $data_id ){
							$filter_pod = pods( $args['filter_post_type'], $data_id );
							if ( $filter_pod->display( $args['filter_meta_key'] ) !== $source_pod->display( $args['source_meta_key'] ) ) {
								unset( $data[ $data_id ] );
							}
						}
					}
				}
				return $data;
			},
			1,
			6
		);
	}
}

Using this method, a new filter of the same type can be instantiated with the signature:

new Filter([
	'relationship_field_name' => 'events',
	'source_post_type' => 'building',
	'filter_post_type' => 'event',
	'source_meta_key' => 'official_name',
	'filter_meta_key' => 'official_name',
]);

So with your field names, it’d likely be:

new Filter([
	'relationship_field_name' => 'building_event',
	'source_post_type' => 'buildings',
	'filter_post_type' => 'events',
	'source_meta_key' => 'official_name',
	'filter_meta_key' => 'official_name',
]);

Or something very close depending on whether your post type IDs are plural or not.

Multiple filters can be instantiated by duplicating the new Filter([...]); block.

(If it doesn’t load with Pluginception, try changing plugins_loaded to init.)

I’m afraid the new version is going over my head! What is the advantage of using the class?

It’s a slight advantage of separating configuration from code.

Version 1 and version 2 do the exact same thing.

In version 1, each new filter would result in duplicating the entire code block.
In version 2, each new filter would result in duplicating only the new Filter([...]); portion.

It could be written without a class.

Here’s version 3 with a function instead of a class:

<?php
/**
 * Plugin Name: Filter Pods Relationships
 * Description: Filter Pods meta fields with <code>add_pods_field_relationship_filter()</code> function.
 * Version: 3
 */

namespace Filter_Pods_Relationships;

add_action(
	'plugins_loaded',
	function(){
		add_pods_field_relationship_filter([
			'relationship_field_name' => 'events',
			'source_post_type' => 'building',
			'filter_post_type' => 'event',
			'source_meta_key' => 'official_name',
			'filter_meta_key' => 'official_name',
		]);
	}
);

function add_pods_field_relationship_filter( array $args ) {
	add_filter(
		'pods_field_pick_data',
		function ( $data, $name, $value, $options, $pod, $id ) use ( $args ) {
			if ( 'pods_meta_' . $args['relationship_field_name'] === $name && $args['source_post_type'] === get_post_type( $id ) ) { 

				$source_pod = pods( $args['source_post_type'], $id );

				foreach ( $data as $data_id => $value ) {
					if( $data_id ){
						$filter_pod = pods( $args['filter_post_type'], $data_id );
						if ( $filter_pod->display( $args['filter_meta_key'] ) !== $source_pod->display( $args['source_meta_key'] ) ) {
							unset( $data[ $data_id ] );
						}
					}
				}
			}
			return $data;
		},
		1,
		6
	);
}

So then each new filter would be a variation of:

add_pods_field_relationship_filter([
	'relationship_field_name' => 'events',
	'source_post_type' => 'building',
	'filter_post_type' => 'event',
	'source_meta_key' => 'official_name',
	'filter_meta_key' => 'official_name',
]);

All three versions do the same thing —?it’s just a matter of configuration / maintenance.

The new code works great. I have not added another field filter yet, but it is clear how to do that, so I am looking forward to the chance!

Just wanted to add one last update. Today I added an extra set of filtering criteria to the code, and it works perfectly. Fantastic work, thank you!