Would you like to add new custom fields to your WordPress posts, pages, and categories? Now you can easily do this with the WordPress custom taxonomy system. For example, if you have a blog on movie reviews, you may want to add the fields Actors and Genre to each of your posts.
What is less clear, however, is how you can expand your WordPress admin interface, so that users can easily enter in these new custom fields. WordPress 2.8+ will only include an input interface for custom taxonomies associated with posts. In addition, this input interface is the standard tag interface, where you must type in the new fields as plain text.
If you are looking for a drop-down menu, or a radio button list, you are out of luck.
Here, we consider how you can flexibly expand your WordPress post interface and style your custom taxonomy input panel however you want.
1. Create Your WordPress Custom Taxonomy
First, we create a simple test attribute called theme and we associate it with our WordPress posts. We add three initial terms to our new theme attribute – Beauty, Halloween, and Dragons.
Note that the hierarchical argument simply refers to whether your new theme attribute is a hierarchical structure, such as your WordPress categories, or whether it is flat, such as your WordPress tags.
The hierarchical argument does not currently affect the input interface of your new attribute. As of WordPress 2.8, the normal tag input interface will be used for all custom taxonomy attributes. To restyle the custom taxonomy input interface, you must use the add_meta_box command.
add_action( 'init', 'create_theme_taxonomy', 0 );
function create_theme_taxonomy() {
if (!taxonomy_exists('theme')) {
register_taxonomy( 'theme', 'post', array( 'hierarchical' => false, 'label' => __('Theme'), 'query_var' => 'theme', 'rewrite' => array( 'slug' => 'theme' ) ) );
wp_insert_term('Beauty', 'theme');
wp_insert_term('Dragons', 'theme');
wp_insert_term('Halloween', 'theme');
}
}
2. Styling Your Custom Taxonomy Input
To add input menus to your WordPress post interface, you want to use the WordPress add_meta_box command. In the example code below, we add a new custom field called Theme into our WordPress post interface. Simply include the code into your functions.php theme or plugin file.
function add_theme_box() {
add_meta_box('theme_box_ID', __('Theme'), 'your_styling_function', 'post', 'side', 'core');
}
function add_theme_menus() {
if ( ! is_admin() )
return;
add_action('admin_menu', 'add_theme_box');
}
add_theme_menus();
The add_meta_box function adds your_styling_function to the WordPress blog system so that it gets called whenever the Edit Post screen is rendered. You can use the same function to add input code to Edit Page and Edit Link screens.
The example your_styling_function below will add a drop-down menu to your blog Edit Post screen, containing all the current terms on your theme custom taxonomy.
// This function gets called in edit-form-advanced.php
function your_styling_function($post) {
echo '<input type="hidden" name="taxonomy_noncename" id="taxonomy_noncename" value="' .
wp_create_nonce( 'taxonomy_theme' ) . '" />';
// Get all theme taxonomy terms
$themes = get_terms('theme', 'hide_empty=0');
?>
<select name='post_theme' id='post_theme'>
<!-- Display themes as options -->
<?php
$names = wp_get_object_terms($post->ID, 'theme');
?>
<option class='theme-option' value=''
<?php if (!count($names)) echo "selected";?>>None</option>
<?php
foreach ($themes as $theme) {
if (!is_wp_error($names) && !empty($names) && !strcmp($theme->slug, $names[0]->slug))
echo "<option class='theme-option' value='" . $theme->slug . "' selected>" . $theme->name . "</option>\n";
else
echo "<option class='theme-option' value='" . $theme->slug . "'>" . $theme->name . "</option>\n";
}
?>
</select>
<?php
}
Lines 4-5 – Add security nonce check.
Line 9 – We use the hide_empty=0 argument for the get_terms function so that all theme choices will be returned, even the ones that have not yet been assigned to any post.
Line 15 – We use the wp_get_object_terms function to get the theme currently associated with our post so that we may pre-select it in our drop-down menu.
Lines 17-25 – Render our drop-down menu, populating it with our theme names.
Note – On lines 22 and 24, we are now setting the theme-option value to $theme->slug. As pointed out by Adam in the comments section, the taxonomy object slug is unique (unlike its name), and this will prevent duplicate taxonomy terms from being created.
Note that when you add your new drop-down menu box, the old tag input box will still appear. To only include one input box, use the remove_meta_box command as suggested by Leo Mysor in the comments section below.
remove_meta_box('tagsdiv-theme','post','core');
Note – For non-hierarchical taxonomies (like tags) you want to use tagsdiv-{$taxonomy_name}, e.g. tagsdiv-theme. For hierarchical taxonomies (like categories) you want to use {$taxonomy_name}div, e.g. themediv.
You can add the remove_meta_box command before your add_meta_box statement.
Alternatively, you can register your custom taxonomy attribute to something other than ‘post’. In the code example below, we register our theme custom taxonomy to shiba_post, which gets rid of the standard tag input box in the Edit Post screen.
register_taxonomy( 'theme', 'shiba_post', array( 'hierarchical' => false, 'label' => __('Theme'), 'query_var' => 'theme', 'rewrite' => array( 'slug' => 'theme' ) ) );
However, as pointed out by Leo, this also removes your taxonomy tab from the Posts menu and makes it difficult for others to add new items to your taxonomy.
3. Saving Your New Inputs
Now, we can insert any input panel we want for our custom taxonomy, however, we still need a way to save those input values. This can be achieved with the save_post WordPress hook. This hook allows you to execute a function of your choice when a WordPress post gets saved. There are similar hooks for saving pages and links.
Just add the save_post hook to your existing add_theme_menus function. For example, the code below registers the save_taxonomy_data function with the WordPress blog system so that it gets executed whenever a WordPress post is saved or updated.
function add_theme_menus() {
if ( ! is_admin() )
return;
add_action('admin_menu', 'add_theme_box');
/* Use the save_post action to save new post data */
add_action('save_post', 'save_taxonomy_data');
}
Now, you just need to specify your save_taxonomy_data function. We can adapt our own save function from the add_meta_data example on WordPress.org.
function save_taxonomy_data($post_id) {
// verify this came from our screen and with proper authorization.
if ( !wp_verify_nonce( $_POST['taxonomy_noncename'], 'taxonomy_theme' )) {
return $post_id;
}
// verify if this is an auto save routine. If it is our form has not been submitted, so we dont want to do anything
if ( defined('DOING_AUTOSAVE') && DOING_AUTOSAVE )
return $post_id;
// Check permissions
if ( 'page' == $_POST['post_type'] ) {
if ( !current_user_can( 'edit_page', $post_id ) )
return $post_id;
} else {
if ( !current_user_can( 'edit_post', $post_id ) )
return $post_id;
}
// OK, we're authenticated: we need to find and save the data
$post = get_post($post_id);
if (($post->post_type == 'post') || ($post->post_type == 'page')) {
// OR $post->post_type != 'revision' $theme = $_POST['post_theme'];
wp_set_object_terms( $post_id, $theme, 'theme' );
}
return $theme;
}
Lines 4-6 – First we do a nonce check to ensure that the function is being called by our very own your_styling_function. Make sure that the taxonomy_noncename and taxonomy_theme terms match those that were created earlier, on lines 4-5 in your_styling_function.
Lines 9-10 – Take no action for auto-saves.
Lines 14-20 – Check that the current user has proper permissions to edit posts.
Lines 23-28 – Associates our post with the new theme taxonomy data. It is important to do a post_type check here, because this function will also get called on post revision objects.
As pointed out by Angelia, this results in double counting the newly added taxonomy relationship.
4. Getting a Taxonomy Term Count
If you want to get the count of a particular taxonomy term, i.e., the number of objects that it is associated with, you can easily extract that figure from the WordPress term_taxonomy database.
Just add the count code into the foreach $themes loop.
global $wpdb;
foreach ($themes as $theme) {
$count = $wpdb->get_var( $wpdb->prepare( "SELECT count FROM $wpdb->term_taxonomy WHERE term_taxonomy_id = %d", $theme->term_taxonomy_id) );
/* Your code here to display the count ... */
}
While registering your custom taxonomy, you can link an update_count_callback function to it. This function will get called every time any term in your taxonomy gets a count update. This allows you to control what actually gets stored in the count column of your custom taxonomy terms.
$args = array( 'hierarchical' => false,
'update_count_callback' => 'test_taxonomy_count',
'label' => __('Theme'),
'query_var' => 'theme',
'rewrite' => array( 'slug' => 'theme' ) )
register_taxonomy( 'theme', 'post', $args);
// This test count function just does the default WordPress operations
function test_taxonomy_count($terms) {
global $wpdb;
$terms = array_map('intval', $terms);
foreach ( (array) $terms as $term) {
$count = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM $wpdb->term_relationships WHERE term_taxonomy_id = %d", $term) );
$wpdb->update( $wpdb->term_taxonomy, compact( 'count' ), array( 'term_taxonomy_id' => $term ) );
}
}
5. All Done!
You can use the same code to style your custom taxonomy input panels for pages and links. Just change the post attribute to page or link when calling add_meta_box and use the save_page, edit_link, and add_link hooks instead of save_post.
You can also add new fields to your WordPress blog categories using a similar system.
Hi,
This has been really helpful for me since I am designing a site for a college newspaper which needs a lot more cms functionality and a lot less of the blog feel. I made two drop down menus within my article taxonomy for the section and the issue but it will only register one (the lower one on the screen). Is there any way to get both of them to work? I am also looking into having the issue selection be separate since I will most likely be posting all articles from the same issue at once and maybe having it at the top of the admin screen but I am guessing that I might have a similar problem. Any help would be greatly appreciated!
You can add as many drop-down menus as you want. Just make sure that the HTML names associated with each of them is different (line 12), and when you save the results, make sure you are getting the values from the right drop-down menu.
Well the problem that I am having isn’t making the boxes it is saving two separate boxes when I press the publish (or save draft) button to save the changes. With all of the other settings you normally don’t have to do them one at a time so I would think that there should be a way to do this. I tried switching the order of the buttons physically by moving the boxes and it only registers the lower down button. The part I am really having trouble with is that it doesn’t seem to be a problem with the code of a specific button since they both work separately and it is only when together that one doesn’t work. Also it didn’t seem to matter where on the page they were, only that one was above the other. Maybe I could combine them into the same box… Any thoughts?
this is a beautiful tutorial. very useful. i am trying to add radio buttons though, rather than a drop-down list. i know you say: “If you are looking for a drop-down menu, or a radio button list, you are out of luck.” but on an introductory page you say, “Substitute the default tag interface with a drop-down menu, radio button list, or something else.” do you give directions on this anywhere? thank you.
You can do something like this for your styling function (from lines 8-28) –
// Get all theme taxonomy terms $themes = get_terms('theme', 'hide_empty=0'); $names = wp_get_object_terms($post->ID, 'theme'); ?> <input type="radio" name='post_theme' value="" > Noneslug, $names[0]->slug)) echo "<input type='radio' name='post_theme' value='{$theme->slug}' checked> {$theme->name}
n"; else echo "<input type='radio' name='post_theme' value='{$theme->slug}'> {$theme->name}
n"; }
Instead of echoing the HTML for a drop down list just echo the HTML for radio buttons.
Thanks for this, Shiba. It answered a lot of questions.
I’m designing a small real estate site and decided to used custom taxonomies for the property listing data: price, bedrooms, etc. Of course the standard taxonomy checkbox interface was useless as I need a variety of inputs. This article was a big help.
But since I need a lot of meat boxes for my data inputs, I guess the best solution is to set up a master array containing the parameters for each meta box and then loop through a constructor function?
Else I end up with a very long script.
Yeah that makes a lot of sense. It is what I normally do in my plugins.
in part 2, your code on line #22, I had to change
theme->nametotheme->slugfor use with a hierarchical taxonomy. Otherwise it kept creating new terms.Thanks for the fix Adam. I have included it in the article above.
I’ll give that a go and see how I get on
How would you add numbers to a drop down box so that they are sorted correctly and not as strings? eg 1,2,10,11,20 rather than 1,10,11,2,20
One way to do this would be to create an array of taxonomy_id -> count, and then just run PHP asort on the array. Then you can loop through the elements in the sorted array to display them in your drop down box.
Me again. Okay, so, I thought I was in the clear with that solution, but, alas, no bueno again. Turns out that using the code for the custom dropdowns is doing something wonky with the post counts in the taxonomy. When I clear out all taxonomy terms etc., fire up this code in functions file and go to admin, all looks good, 0 posts for term, but, when I add a term to a post, save and then go to the taxonomy menu, it says that there are 2 posts under that term when there is only one. When I then delete the term, it says there is 1, when there is now 0. If I remove the custom styling/saving from functions file and repeat process using default meta box, the count is correct, 0,1,0. Any clues on this one?
Thanks for uncovering this bug.
The reason why count is incremented twice is because a taxonomy relationship gets saved for the post and another gets saved for the post revision.
To fix this count problem, do a post_type check in your save_taxonomy_data function, e.g.
$post = get_post($post_id); if (($post->post_type == 'post') || ($post->post_type == 'page')) { // OR $post->post_type != 'revision' $theme = $_POST['post_theme']; wp_set_object_terms( $post_id, $theme, 'theme' ); }I will update the article tomorrow. Now I am off to bed.
I’m really struggling to figure out where to add in the show_option_none in this code so that there is an option to remove the taxonomy from a post if assigned in error. I see that it is available in the image example of your code, so, perhaps you could enlighten us?? Would be greatly appreciated. I believe your example here is the only one on the internet at present discussing how to customize the administrative inputs for custom taxonomies, so, thank you very much for that. I would love to see this elaborated on even more by those in the know. I’ve been wrecking my brain trying to work out how to provide multiple input options on a site I’m currently developing. I know things are about to change considerably in WP3.0, so, I want to be sure that the methods that I am using initially will be easily converted to take advantage of the new core functions once they are implemented.
Hello Angelia,
One way to do it is to add an additional “None” option to the drop down menu, [I have added it to the article above] e.g.
Thanks so much for the help Shibashake! I’ve just about been driving myself batty with all of this 😉 I have a client site that I’m building currently, and the main thing that they provide is lesson plans for teachers. My goal is to construct a backend admin that makes it easy for teachers to create the plans in the post editor ( taxonomy non-hierarchical modules ( dropdown ) for grade level, subject etc., custom taxonomy heirarchical for a gigantic ( dropdown ) listing of applicable state standards ), custom taxonomy default selection for general things like materials and the default post tags for other searchable descriptions … you get the point. Of course, then I have to have all of those same modules provide for in-depth searchability of the plans for the front end user. The new taxonomy, custom post types, and admin hooks are absolutely perfect for implementing all of this, but, my goodness, not only is there very little info out there at the moment, I’ve been watching the trac to see how things are coming along, and just about everything that I need to custom code to make this happen, is going to be implemented in 3.0. I’m pulling my hair out to work out how I should implement this stuff now, without having to redo everything in a month from now. I’ve scoured the available plugins ( simple taxonomies, custom taxonomies and gdtaxonomy tools ) in an attempt to put something custom together for my client to be able to use now, but, they all fall short in one way or another. Custom Taxonomies creates its own table, and I experienced some duplicate counts with it, not to mention there is a bug with not being able to deselect a selected term in the custom checkbox metabox. Simple taxonomies is really really simple, providing a nice start, but, doesn’t take into account hierarchical, or custom post type. I tried implementing them in there myself, but, no bueno. GD tools is mostly fluff, and the one feature that I was interested ( deletion ) doesn’t work. I checked the database twice, and the terms were still there. I’ve never written my own plugin from scratch, I mostly just do customizations of existing code ( self-taught … what can I say ), so I’m not really confident yet in my ability to put a beast like that together properly myself, especially after looking through the trac at all of the customizations that are having to be made on so many levels of core files just to implement these big changes.
It seems that in the trac, they are extending Walker to deal with dropdowns for hierarchical terms.
I’m rambling. My conclusion is to 1. remove any plugin attempts ( my custom ones or otherwise ) for now, 2. stick to the basics ( with your style inclusions ) 3. keep it all in the functions file and 4. hold off on implementing the hierarchical taxonomies until the 3.0 release. Then I’ll just hold my breath that along with the 3.0 release comes a taxonomy column in edit.php, singular and plural terms, easy styling of meta boxes, and the ability to transition what I’m doing in my functions file, to the core without screwing anything up in the database, ie unregister_taxonomy. Ha! Wish me luck. Should be fun explaining all of this to my client … always is.
Thanks Leo – that is very good advice. I have added it to the article 🙂
Not at all. Also thank you for teaching me with the custom taxonomies. 🙂
Hello, I got error with your_styling_function
Says “Warning: strcmp() expects parameter 2 to be string”.
I just copy and paste your code, nothing modified. ❓
Thanks for pointing that out Leo. The strcmp command should actually read –
There should be a ‘->name’ after $names[0]. Please let me know if you run into any more problems.
Thank you for quick reply. It works!
I think it’s better to use remove_meta_box to remove the original input taxonomy box, rather than register it to “shiba_post”. In this way the “Theme” tab will still appear in the admin menu, as a submenu under “Posts”, this lets other webmasters easily add more taxonomies.
Thanks again.
Sorry, I mean add more terms in that taxonomy, actually.