scarekrow76

Hi. No, I haven’t found any guidelines yet – although, I must admit, I haven’t looked lately.

My approach has been to view the source HTML for admin pages and follow the structure of the core metaboxes as closely as I can. I like to make mine as vanilla as possible, so that they look just like the pre-existing boxes.

Pages like this and this can be useful for reference, but it would be nice to have some ‘official’ guidelines.

Its a standalone function, so can be used in or outside of the content loop. This is how I’m using it within my functions.php file…

$subterms = get_associated_terms( 'tasks', $term->term_id );

if ( $subterms ) {
	$item_output .= '<div><h5>' . __( 'Tasks' ) . '</h5><ul>';
	foreach ( $subterms as $subterm ) {
		$item_output .= '<li><a href="' . $term_link . 'tasks/' . $subterm->slug . '">' . $subterm->name . '</a></li>';
	}
	$item_output .= '</ul></div>';
}

Try removing the WHERE clause from my SQL string and print_r() the resulting Object to your page. Is it returning anything?

@fune : Once added to your functions.php file or a plugin, its used in the same way you’d use a built-in function like get_terms() (except my function accepts fewer parameters).

http://codex.ww.wp.xz.cn/Function_Reference/get_terms

It returns an object that can be looped through.

$terms = get_associated_terms( 'tax1', 256 );
foreach($terms as $term) {
	echo "<a href='/tax1/" . $term->slug . "'";
	echo "class='" . $term->taxonomy . "'>";
	echo $term->name;
	echo "</a>";
}

If only it were that simple. At the insistance of the client, there are two seperate taxonomies. A Post should always be assigned atleast one term from each taxonomy.

I *think* I have it now. Just slotting it into a plugin and will then test it.

Does anyone have a better suggestion than this?

SELECT DISTINCT $wpdb->terms.term_id, $wpdb->terms.name, $wpdb->terms.slug
FROM $wpdb->terms
INNER JOIN $wpdb->term_taxonomy ON $wpdb->terms.term_id = $wpdb->term_taxonomy.term_id
INNER JOIN $wpdb->term_relationships ON $wpdb->term_taxonomy.term_taxonomy_id = $wpdb->term_relationships.term_taxonomy_id
INNER JOIN $wpdb->posts ON $wpdb->term_relationships.object_id = $wpdb->posts.ID
INNER JOIN $wpdb->term_relationships tr2 ON $wpdb->posts.ID = tr2.object_id
INNER JOIN $wpdb->term_taxonomy tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id
WHERE $wpdb->posts.post_status = 'publish' AND $wpdb->posts.post_type = 'post' AND $wpdb->term_taxonomy.taxonomy = 'tasks' AND tt2.term_id = 592
ORDER BY $wpdb->terms.name

Interesting. If I choose the “All content” option during the export stage, and then try to import the XML document into the new site, everything appears as it should – posts, comments and media.

Well, I found one alternative – but not sure if its reccommend…

I added a hook to the the_post action which appended an extra value to the $post object.

add_action('the_post', array(&$this, 'the_post'));

function the_post($post)
	{
		global $post;

		$custom = get_post_custom($post->ID);
		$building = $custom['building'][0];
		$street = $custom['street'][0];
		$city = $custom['city'][0];
		$county = $custom['county'][0];
		$postcode = $custom['postcode'][0];

		$address = new AircooledBugsAddress($building, $street, $city, $county, $postcode);

		$post->post_event_address = $address->get_formatted_address();

		return $post;
	}