danblaker

After some additional research, I can answer my own question. To get a key-value cache, you have to use something in addition to OPcache. I’ll install memcached and TOC should just work!

Indeed, AD Integration has stopped working in our environment since that change.

In 3.1.x, the syntax is different for managing custom columns for custom post types. You would use the following code to add a column for a custom taxonomy named “foo_skill” on the edit page for a custom post type named “foo_portfolio” (always namespace your custom post types and taxonomies using a unique prefix!):

add_filter('manage_foo_portfolio_posts_columns', 'manage_foo_portfolio_columns');
add_action('manage_foo_portfolio_posts_custom_column', 'print_foo_portfolio_column'), 10, 2);

function manage_foo_portfolio_columns($existing_columns) {
  $existing_columns['foo_skill'] = 'Skills';
  return $existing_columns;
}

function print_foo_portfolio_column($column_name, $post_id) {
  if( $column_name == 'foo_skill' )
  {
    global $typenow; // global WP post type variable
    $terms = get_the_terms($post_id, 'foo_skill');
		if ( !empty( $terms ) )
		{
			$out = array();
			foreach ( $terms as $term )
				$out[] = '<a href="edit.php?post_type=' . $typenow . '&foo_skill=' . $term->slug . '">' .
			    esc_html(sanitize_term_field('name', $term->name, $term->term_id, 'foo_skill', 'display')) .
			  '</a>';
			echo join( ', ', $out );
		}
		else
		{
			echo 'No Skills.';  //No Taxonomy term defined
		}
  }
}

Never mind my workaround. After investigating further, I discovered that one of my taxonomies was registered with ‘public’ => false. This was preventing multiple-taxonomy queries from working correctly, though single-taxonomy queries on the private taxonomy were working just fine.

Scribu, thanks for all your contributions to the WP platform! I am relatively new to WP, and I continue to be amazed by community and the platform.

You might want to update the plug-in page to reflect the current behavior—I just spent about an hour trying to figure out why QMT seemed to be adding taxonomy results as opposed to filtering out results. Then I found this thread.

Unfortunately, my current project is scheduled to go live next week so I can’t move to 3.1 right now. Instead, I’ve got a workaround inside the loop, which is a bit more complicated than my original multi-taxonomy query.

If anybody wants to do a similar workaround, here’s one approach. Note I haven’t tested it in the pasted format but it should give you the general idea.:

<?php
$listbody = '';
$product_line = "bumper-stickers";
$selected_location = 'portland';

$query_args = array(
  'post_type'         =>  $content_type,
  'posts_per_page'    =>  -1, // GET ALL POSTS, USE THE POST LIMIT INSIDE THE LOOP
  'taxo_product_line'  =>  $product_line,
  // 'taxo_locations'     =>  $selected_location // THIS WILL WORK IN WORDPRESS 3.1
);

$myloop = new WP_Query($query_args);
static $displaycount = 0; // USING A COUNTER OUTSIDE THE LOOP TO CHECK IF NO POSTS WERE RETURNED
if ( $myloop->have_posts() )
    {
        while ( $myloop->have_posts() ) : $myloop->the_post();
        static $post_count = 0;
        $post_limit = 10;
        if ($post_count == $post_limit) //
        {
            break;
        }
        // CUSTOM FILTERING FOR THE LOCATION TAXONOMY. THIS WILL BE MOVED TO WP_QUERY IN WORDPRESS 3.1
        $postlocation_objects = get_the_terms(get_the_ID(),'taxo_locations');
        $postlocations = array();
        foreach ($postlocation_objects as $term)
        {
          $slug = $term->slug;
          $postlocations[] = $slug;
        }
        if (in_array($selected_location, $postlocations))
        {
          // WE HAVE POSTS FOR THIS LOCATION
          $listbody .= get_the_content();
          $count++;
          $displaycount++;
        }
      endwhile;
      if ($displaycount == 0) $listbody .= 'No posts for you!'; // WORKAROUND TO CHECK IF NO CONTENT WAS RETURNED FOR THIS LOCATION
    }
else
  //  We don't have any content for this region
  {
    $listbody .= 'No posts for you!'
  }

echo $listbody
?>

Thanks for the reply, but that’s not really what I’m trying to do.

I don’t want to reuse the page template, because it is specific to this custom page content (i.e. there will only be a single Location Picker page on the site). Beyond that, I don’t want to store the page in the WP database for a variety of reasons (e.g., I want to enable the entire functionality by clicking “Activate” for this feature in the Plugins list).

I just finished implementing it using the lightbox approach I defined above—hooking into the ‘wp_footer’ action to insert a hidden location picker, which I display in a lightbox when the user clicks the link. But this adds an unnecessary “get_terms()” call to every page on the site; I’d prefer to only run that query when the user actually goes to change their location, i.e. only when they go to the Location Picker page.