For a particular project, I needed WordPress to do something based on a custom post type’s custom taxonomy. WP didn’t have a built in function for checking custom taxonomies so I googled for an answer.

After looking for ways to have WordPress do a conditional test for custom taxonomies I was unsatisfied with what I found since most of the solutions involved making functions. While they do work, it was a bit too much for my use since I really only needed to check the custom post against only one custom taxonomy. And mostly because I know that there is always more than one way to skin a cat… and sometimes I really do want to find “my own solution“.

So here’s my version of the one-time, non-function way to test for a conditional taxonomy on a conditional post type, which admittedly may not be so efficient, but it works! (and if you cache, then it doesn’t really matter) First, you need to put this bit of PHP somewhere before where you need to do your conditional test:

<?php
$tempvar = urldecode(http_build_query(get_the_terms($post->id, 'custom_tax_name')));
if(strpos($tempvar, '[term_taxonomy_id]=101') !== false) {$customtaxis = 'y';}else{$customtaxis = 'n';}
?>

Line 2 puts all the post’s taxonomy information as a string into the $tempvar variable. Line 3 checks whether the a taxonomy with ID of 101 is in $tempvar and sets the $customtaxis variable appropriately.

To make this work for you change the following :

• custom_tax_name to the name of your custom taxonomy (the $taxonomy variable in the register_taxonomy function)
• 101 to the ID of the custom taxonomy you want to test
• $tempvar and $customtaxis to whatever variables you want, if you want

Then, where ever you want to test for your custom taxonomy, use this:

if($customtaxis  == 'y') {
// if yes, whatever you want
}else{
// if not, whatever you want
}

And that’s it!

Note: This must be used inside the loop. Tested in WP version 3.1 – 3.1.3

WordPress version 3.1 has just been released. Yeah!!!!

I’ve only been excited about one other WP release, which was for 3.0′s custom post types (now one of my favorite features to use in WordPress).

So, why am I so excited about 3.1? Mostly because of one fix: The Password Reset Redux.

This fix greatly simplifies the WP lost password process by replacing the two email process with a single email process.

So why would I be so happy about this?

At work I manage a membership only blog with (currently) a little over 2,000 members/users and I am tired of having to answer customer support emails from members that can’t figure out how to reset their passwords. A number of the site’s members experience PEBKAC errors because they either don’t understand the WP-generated passwords provided, they don’t read the emails carefully, they don’t wait to receive any email, or they just really are technologically challenged.

So, to the WordPress open source community, a big THANK YOU!!!!!

Recently at work, there was a need to ask for additional data in the comments section of a WordPress site. A checkbox needed to be added to the comments form asking a question.

This sounded like a good use for WordPress comments meta data. There isn’t a lot of information out on the interwebs about how to use it, so I had to more or less figure this out…

So, what needed to be done was:

• add a check box to the comments form
• show in the WordPress comments admin whether or not the checkbox was selected
• indicate in the comment notification email whether or not the checkbox was selected

Adding the checkbox to the comments form is the easiest part. To add the checkbox to the comments form open up your themes comments.php file and paste this into the area where you need it:

<p><label><input name="publishc" type="checkbox" id="publishc" value="this is the value I want to capture" tabindex="90" /> Whatever sentence that you want commenters to use the checkbox for</label></p>

Now that the checkbox is in place, we need to make sure that the data (the checkbox value) is saved to the database. We also want that data to be visible when viewing the comments from within the WordPress admin. So, paste this in your theme’s functions.php file:

// allow the saving of comment meta data
function fpo_allow_show_comment ( $post_id ) {
$allow_show_comment = $_POST['publishc'];
if ( $allow_show_comment ) {
add_comment_meta( $post_id, 'publishc', $allow_show_comment, true );
}}
add_action( 'comment_post', 'fpo_allow_show_comment', 1 );

// display meta in the edit comments admin page
function show_commeta() {
if (is_admin()) {
   echo get_comment_text(), '<br/><br/><strong>', get_comment_meta(get_comment_ID(), 'publishc',1), '<strong>';
   }}
add_action('comment_text', 'show_commeta');

The first function will allow comments meta data to be collected and to save it to the database. The second functions will show it in the comments admin pages.

Adding the comments meta data to the notification email proved to be the hardest to figure out – I couldn’t figure out a way to do it via plugin or editing functions.php. So, I decided to do this the least desirable way, which is to edit the WordPress core files, namely wp-includes/pluggable.php.

So find the function wp_notify_postauthor and look for the part that says if (‘comment’ == $comment_type) {. Paste these lines of code in whatever area of the notification email where you would like the comment meta to be included:

$notify_message .= __('Comment meta: ') ;
$notify_message .= sprintf( get_comment_meta($comment->comment_ID, 'publishc',1)) . "\r\n\r\n";

And that is that, hours and hours worth of trial and error. Hope you find it useful!

Test and works in WordPress versions 2.9 through 3.0.4.