robert_k

Well, it’s a search feature so there’s a couple of possibilities. I’ve renamed the post type, but this is the gist of the code:

$params = array(
	'posts_per_page' => -1,
	'post_type'      => 'mycpt',
	'post_status'    => 'publish',
	'meta_key'       => 'type',
	'orderby'        => array('meta_value' => 'DESC', 'date' => 'DESC')
);

if (empty($_GET)) {
	$params['meta_query'][] = array(
		'key'   => 'featured',
		'value' => 1,
		'type'  => 'NUMERIC'
	);
} else {
	if (!empty($_GET['type'])) {
		$params['tax_query'][] = array(
			'taxonomy' => 'mycpt_type',
			'terms' => array_map('intval', (array) $_GET['type']),
		);
	}

	if (!empty($_GET['filters'])) {
		$params['tax_query'][] = array(
			'taxonomy' => 'mycpt_cat',
			'terms' => array_map('intval', (array) $_GET['filters']),
		);
	}

	if (!empty($_GET['search'])) {
		$params['s'] = $_GET['search'];
	}
}

$query = new WP_Query($params);

if (!empty($params['s']) && function_exists('relevanssi_do_query')) {
	relevanssi_do_query($query);
}

The searches that failed were against the “s” parameter only. But I’m wondering if the meta_key and order-by meta_value configuration could be the issue?

You can play with the search form on this page to see what happens. The search box doesn’t respect the category/type taxonomies though the search logic supports it (that was requested). The only other thing I can think of is the fact we use the same query to loop twice: once for map pins, and a second time for the entries below the map.

Sorry guys, as far as I can tell the plugin owner never even attempted to contact me and has not dealt with the security issues I pointed out. The archive I posted has fixes for these security holes, but it isn’t an official update for the plugin.

Thanks Michael, that’ll come in handy in the future. We scoped the placeholder fallback script to the one form that needed it (so it wouldn’t create those fields).