CPT-onomies Screenshots

CPT-onomies Documentation

A new version of CPT-onomies has joined the ranks but don’t get too excited. It’s just a few bug fixes that have been brought to my attention since I released 1.2 back in December.

I hope you’re enjoying CPT-onomies and, as always, please let me know if you find any bugs, or have any feature requests, by posting to the CPT-onomies support forum.

Thanks for being such awesome users!

CPT-onomies Screenshots

CPT-onomies Documentation

To say my life has been crazy the past 6 months would be a very large understatement but CPT-onomies 1.2 is finally here! On top of a few minor bug fixes, here’s what 1.2 brings to the table:

• Create custom CPT-onomy archive pages with just a few simple lines of code!
• Added the ability to set a CPT-onomy term description using ‘term_description’ or ‘{$taxonomy}_description’ filter’.
• Non-public custom post types can now be used as CPT-onomies.
• Exclude CPT-onomy terms from being listed in the “Assigning CPT-onomy Terms” admin meta box and, therefore, from being assigned to a post.
• Added numerous filters, allowing you to:
  • Remove “Assigning CPT-onomy Terms” meta boxes from admin
  • Remove CPT-onomy dropdown filters from admin
  • Remove the CPT-onomy column and/or it’s sortability
  • Customize settings by removing options and setting default property values
• I changed the cpt_onomy.php filename to cpt-onomy.php to match cpt-onomies.php (I’m not really sure why I gave it an underscore to begin with).
• I, like many others, fixed the $wpdb->prepare() issue.
• If you use the following CPT-onomy settings, be sure to re-save your settings to fix potential bugs:
  • Capability Type
  • Capabilities -> Read Private Posts

I hope you enjoy the update! And, like always, please let me know if you find any bugs. If you need me anytime soon, I’ll be the one drinking some damn scotch. Until next time, keep up the awesomeness!

Download CPT-onomies

CPT-onomies Screenshots

CPT-onomies Documentation

It took me long enough but the next version of CPT-onomies has finally shipped out! And, with it, some pretty cool new features:

• Programmatically register your CPT-onomies
  • Much kudos and thanks to Travis Smith for the assist with this one!
• When assigning CPT-onomy terms on the “edit post” page, choose from three different formats:
  • a checklist (same ole, same ole),
  • an autocomplete box (a pretty cool one, I might add),
  • and a select dropdown (for when you only want to select one term)
• Customize the CPT-onomy archive page slug
  • Before, you were pretty much stuck with “{post type}/tax/{term slug}” (which is still the default) but now, via the settings panel, you can use your own keywords with a little help from the variables $post_type, $term_slug and $term_id. Don’t forget to flush/reset your rewrite rules once you’re finished!
• Tell the CPT-onomy tag cloud widget whether you want the terms to link to their archive page or to their custom post type post page
• When you’re using wp_get_object_terms() to request term information, you can now specify term ids to exclude from your results
• The CPT-onomy class has a new function! Introducing get_term_ancestors(). I think it’s a little self-explanatory =)
• CPT-onomies now supports Internationalization (can’t believe it took me so long!)
• I also tweaked the UI and fixed a few bugs

I hope everyone enjoys the update as much as I do. Sorry it took me so long. My life has been a little crazy but I’m glad to be on the other side of the hiatus!

Please let me know if you have any questions or find any bugs! Thanks for being such awesome users!!

This is an interesting WordPress problem that could span several scenarios. But let’s say you have a custom post type named ‘songs’ and you defined its slug as ‘songs’ so its archive page URL is http://www.mysite.com/songs.

This is fine and all but a slug used for a custom post type archive page, i.e. ‘songs’, is not saved in the database and is, therefore, not available when you’re creating/editing posts to tell WordPress “NO! The slug ‘songs’ is taken!”. With that said, a user could come along and create a post (or page) with the slug ‘songs’ which would therefore have the same URL as your custom post type archive page: http://www.mysite.com/songs.

So how do you keep users on your site from creating posts with particular slugs, a.k.a. reserve slugs?

It’s pretty simple, actually. Use one, or both, of the following two filters. They hook into WordPress when it’s checking a post’s slug, allowing you to return “true” which tells WordPress that the post slug is bad. If you return “true”, WordPress adds on a suffix, just like it would do if you were trying to use a slug that is already taken.

The first filter, ‘wp_unique_post_slug_is_bad_hierarchical_slug’, is for hierarchical posts and the second filter, ‘wp_unique_post_slug_is_bad_flat_slug’, is for non-hierarchical posts. While both filters provide the post’s $slug and $post_type, the hierarchical filter also provides the ID for the post parent so if the $post_parent is 0, you know this is a “base” post.

add_filter( 'wp_unique_post_slug_is_bad_hierarchical_slug', 'rachel_carden_is_bad_hierarchical_slug', 10, 4 );
function rachel_carden_is_bad_hierarchical_slug( $is_bad_hierarchical_slug, $slug, $post_type, $post_parent ) {
   // This post has no parent and is a "base" post
   if ( !$post_parent && $slug == 'songs' )
      return true;
   return $is_bad_hierarchical_slug;
}

add_filter( 'wp_unique_post_slug_is_bad_flat_slug', 'rachel_carden_is_bad_flat_slug', 10, 3 );
function rachel_carden_is_bad_flat_slug( $is_bad_flat_slug, $slug, $post_type ) {
   if ( $slug == 'songs' )
      return true;
   return $is_bad_flat_slug;
}

These filters can be found in the WordPress function wp_unique_post_slug() in the wp-includes/post.php file.

While “Quick Edit” and “Bulk Edit” are not widely used, and are kind of hidden, features, they are no less powerful and time-saving. So when a user requested they be added to CPT-onomies, I got busy learning all I could.

At first glance, it may seem like a lot of work but I’m just trying to cover all the details. If “Quick Edit” and “Bulk Edit” is what you’re after, then you’ll be glad you stuck around ’til the end.

If you’re familiar with my CPT-onomies plugin, you know that I use a Movies database in all of my examples. So for this tutorial, I will be adding a field for “Release Date”, which is post meta for my custom post type “Movies”, under “Bulk Edit” and “Quick Edit”.

1) Add your custom columns

Since the “Bulk Edit” and “Quick Edit” hooks are triggered by custom columns, you must first add custom columns for the fields you wish to add, which are setup by ‘filtering’ the column information.

There are 3 different column filters: ‘manage_pages_columns’ for pages, ‘manage_posts_columns’ which covers ALL post types (including custom post types), and ‘manage_{$post_type_name}_posts_columns’ which only covers, you guessed it, the columns for the defined $post_type_name.

The ‘manage_pages_columns’ and ‘manage_{$post_type_name}_posts_columns’ filters only pass $columns (an array), which is the column info, as an argument, but ‘manage_posts_columns’ passes $columns and $post_type (a string).

Note: Don’t forget that it’s a WordPress filter so you HAVE to return the first argument that’s passed to the function, in this case $columns. And for filters that pass more than 1 argument, you have to specify the number of accepted arguments in your add_filter() declaration, following the priority argument.

The first example adds our new column at the end. Notice that we’re specifying a post type because our function covers ALL post types:

add_filter( 'manage_posts_columns', 'rachel_carden_managing_my_posts_columns', 10, 2 );
function rachel_carden_managing_my_posts_columns( $columns, $post_type ) {
   if ( $post_type == 'movies' )
      $columns[ 'release_date' ] = 'Release Date';
   return $columns;
}

The second example adds our new column after the “Title” column:

add_filter( 'manage_posts_columns', 'rachel_carden_managing_my_posts_columns', 10, 2 );
function rachel_carden_managing_my_posts_columns( $columns, $post_type ) {
   switch ( $post_type ) {
      case 'movies':
         $new_columns = array();
         foreach( $columns as $key => $value ) {
            $new_columns[ $key ] = $value;
            if ( $key == 'title' )
               $new_columns[ 'release_date' ] = 'Release Date';
         }
         return $new_columns;
   }
   return $columns;
}

2) Populate your custom columns

Now that we have a column, we need to fill our column with data. The filters to populate your custom column are pretty similar to the ones that added your column: ‘manage_pages_custom_column’, ‘manage_posts_custom_column’, and ‘manage_{$post_type_name}_posts_custom_column‘. All three pass the same 2 arguments: $column_name (a string) and the $post_id (an integer).

Our custom column data is post meta so it will be a pretty simple case of retrieving the post meta with the meta key ‘release_date’.

Note that we are wrapping our post meta in a div with an id of “release_date-” plus the post id. This will come in handy when we are populating our “Quick Edit” row.

add_action( 'manage_posts_custom_column', 'rachel_carden_populating_my_posts_columns', 10, 2 );
function rachel_carden_populating_my_posts_columns( $column_name, $post_id ) {
   switch( $column_name ) {
      case 'release_date':
         echo '<div id="release_date-' . $post_id . '">' . get_post_meta( $post_id, 'release_date', true ) . '</div>';
         break;
   }
}

3) Add to the “Bulk Edit” and/or “Quick Edit” Row

Now that you have your custom column, it’s bulk/quick edit showtime! The filters are ‘bulk_edit_custom_box’ and ‘quick_edit_custom_box’. Both filters pass the same 2 arguments: the $column_name (a string) and the $post_type (a string).

Your data’s form fields will obviously vary so customize at will. For this example, we’re using an input. Also take note of the css classes on the <fieldset> and <div>. There are a few other options like ‘inline-edit-col-left’ and ‘inline-edit-col-center’ for the fieldset and ‘inline-edit-col’ for the div.

add_action( 'bulk_edit_custom_box', 'rachel_carden_add_to_bulk_quick_edit_custom_box', 10, 2 );
add_action( 'quick_edit_custom_box', 'rachel_carden_add_to_bulk_quick_edit_custom_box', 10, 2 );
function rachel_carden_add_to_bulk_quick_edit_custom_box( $column_name, $post_type ) {
   switch ( $post_type ) {
      case 'movies':

         switch( $column_name ) {
            case 'release_date':
               ?><fieldset class="inline-edit-col-right">
                  <div class="inline-edit-group">
                     <label>
                        <span class="title">Release Date</span>
                        <input type="text" name="release_date" value="" />
                     </label>
                  </div>
               </fieldset><?php
               break;
         }
         break;

   }
}

4) Populate Your “Quick Edit” Data

When you click “Quick Edit”, you may have noticed that your form fields are not populated. WordPress adds one “Quick Edit” row which moves around for each post so the information cannot be pre-populated. It has to be populated with JavaScript on a per-post “click Quick Edit” basis.

WordPress has an inline edit post function that populates all of their default quick edit fields so we want to hook into this function, in a sense, to make sure our JavaScript code is run when needed. We will “copy” the WP function, “overwrite” the WP function so we’re hooked in, “call” the original WP function (via our copy) so WordPress is not left hanging, and then run our code.

Remember where we wrapped our column data in a <div> in Step 2? This is where it comes in handy, allowing our Javascript to retrieve the data by the <div>’s element ID to populate our form field. There are other methods to retrieve your data that involve AJAX but this route is the simplest.

Don’t forget to enqueue your script and make sure it’s dependent on WordPress’s ‘inline-edit-post’ file. Since we’ll be using the jQuery library, we need to make sure ‘jquery’ is loaded as well:

add_action( 'admin_print_scripts-edit.php', 'rachel_carden_enqueue_edit_scripts' );
function rachel_carden_enqueue_edit_scripts() {
   wp_enqueue_script( 'rachel-carden-admin-edit', get_bloginfo( 'stylesheet_directory' ) . '/quick_edit.js', array( 'jquery', 'inline-edit-post' ), '', true );
}

Now let’s create our JavaScript file:

(function($) {

   // we create a copy of the WP inline edit post function
   var $wp_inline_edit = inlineEditPost.edit;
   // and then we overwrite the function with our own code
   inlineEditPost.edit = function( id ) {

      // "call" the original WP edit function
      // we don't want to leave WordPress hanging
      $wp_inline_edit.apply( this, arguments );

      // now we take care of our business

      // get the post ID
      var $post_id = 0;
      if ( typeof( id ) == 'object' )
         $post_id = parseInt( this.getId( id ) );

      if ( $post_id > 0 ) {

         // define the edit row
         var $edit_row = $( '#edit-' + $post_id );

         // get the release date
	 var $release_date = $( '#release_date-' + $post_id ).text();

	 // populate the release date
	 $edit_row.find( 'input[name="release_date"]' ).val( $release_date );

      }

   };

})(jQuery);

5) Save Your “Quick Edit” Data

Saving your “Quick Edit” data is exactly like saving custom data when editing a post, using the ‘save_post’ hook. With that said, you may have already set this up. If you’re not sure, and your “Quick Edit” data is not saving, odds are you need to hook into the ‘save_post’ action.

The ‘save_post’ action passes 2 arguments: the $post_id (an integer) and the $post information (an object).

add_action( 'save_post','rachel_carden_save_post', 10, 2 );
function rachel_carden_save_post( $post_id, $post ) {

   // don't save for autosave
   if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE )
      return $post_id;

   // dont save for revisions
   if ( isset( $post->post_type ) && $post->post_type == 'revision' )
      return $post_id;

   switch( $post->post_type ) {

      case 'movies':

         // release date
	 // Because this action is run in several places, checking for the array key keeps WordPress from editing
         // data that wasn't in the form, i.e. if you had this post meta on your "Quick Edit" but didn't have it
         // on the "Edit Post" screen.
	 if ( array_key_exists( 'release_date', $_POST ) )
	    update_post_meta( $post_id, 'release_date', $_POST[ 'release_date' ] );

	 break;

   }

}

6) Save Your “Bulk Edit” Data

Saving the “Bulk Edit” data is a little trickier because we have to get JavaScript involved. WordPress saves their bulk edit data via AJAX so, guess what, so do we.

Add the following code to your JavaScript file:

$( '#bulk_edit' ).live( 'click', function() {

   // define the bulk edit row
   var $bulk_row = $( '#bulk-edit' );

   // get the selected post ids that are being edited
   var $post_ids = new Array();
   $bulk_row.find( '#bulk-titles' ).children().each( function() {
      $post_ids.push( $( this ).attr( 'id' ).replace( /^(ttle)/i, '' ) );
   });

   // get the release date
   var $release_date = $bulk_row.find( 'input[name="release_date"]' ).val();

   // save the data
   $.ajax({
      url: ajaxurl, // this is a variable that WordPress has already defined for us
      type: 'POST',
      async: false,
      cache: false,
      data: {
         action: 'rachel_carden_save_bulk_edit', // this is the name of our WP AJAX function that we'll set up next
         post_ids: $post_ids, // and these are the 2 parameters we're passing to our function
	 release_date: $release_date
      }
   });

});

Now we need to setup the WordPress AJAX function that will handle and save our data:

add_action( 'wp_ajax_rachel_carden_save_bulk_edit', 'rachel_carden_save_bulk_edit' );
function rachel_carden_save_bulk_edit() {
   // get our variables
   $post_ids = ( isset( $_POST[ 'post_ids' ] ) && !empty( $_POST[ 'post_ids' ] ) ) ? $_POST[ 'post_ids' ] : array();
   $release_date = ( isset( $_POST[ 'release_date' ] ) && !empty( $_POST[ 'release_date' ] ) ) ? $_POST[ 'release_date' ] : NULL;
   // if everything is in order
   if ( !empty( $post_ids ) && is_array( $post_ids ) && !empty( $release_date ) ) {
      foreach( $post_ids as $post_id ) {
         update_post_meta( $post_id, 'release_date', $release_date );
      }
   }
}

7) Download the Code

See? That wasn’t too bad. I’ll even give you the code all nice and neat. Go nuts, buddy.

CPT-onomies Screenshots

CPT-onomies Documentation

CPT-onomies is a WordPress plugin that allows you to create, and use, taxonomies powered by your custom post types, using the post titles as the taxonomy terms. The best part about CPT-onomies is that they work just like regular taxonomies and therefore use the same functions!

Unfortunately, not every taxonomy function works right now but don’t worry, I’ve created CPT-onomy functions to help bridge the gap between WordPress and the plugin. The CPT-onomy functions even mirror the WordPress functions, using the same parameters and return values.

Use the CPT-onomies Documentation to see which WordPress taxonomy functions work and when you’ll need to use a CPT-onomy function. The documentation also includes function parameters, return values, examples, and other helpful information.

If you notice a mistake, or have a function request, feel free to leave a comment or contact me.

Introducing “CPT-onomies: Using Custom Post Types as Taxonomies“:

Humble beginnings

When I was first building http://eng.ua.edu, I knew that custom post types would play a huge role (and basically take over my life). With numerous post types, I wanted to establish a dynamic “People” directory that would connect each person to the “Departments” they worked for, the “Buildings” they worked in, the “Capstone Engineers” they were featured in (our research magazine), and any other content available.

In came custom taxonomies. I created taxonomies that “mirrored” each custom post type (using the post title as terms) and, voila, a dynamic and easily filtered people directory was born! But while managing the “Buildings” taxonomy was easy (buildings don’t exactly come and go on a daily basis), imagine managing a list of 200+ people and having to make sure the “People” taxonomy always matched the “People” custom post type. It’s more than just managing the titles, you have to make sure the slugs match too! Let’s just say that system didn’t last long.

From Idea to Plugin

While the premise of being able to use custom post types as taxonomies, and not having to duplicate information, was always the root of the project, “CPT-onomies” has taken several forms. At first, it wasn’t even a plugin, it was in my theme. When it progressed to a plugin, it was just for personal use and was very rough around the edges, using all kinds of WordPress hacks in a devil-may-care manner. To give me some credit, I had only been using WordPress for a few months and was on a strict redesign schedule. “Behind the scenes” was not a high priority.

But the website launched, my WordPress skills grew, and before I knew it I was saying things like “I bet I’m not the only one who could use this setup” and “This system of using custom post types as taxonomies would make a great plugin”. Little did I know how much fun I would have over the next few weeks.

Developing CPT-onomies

It wasn’t until I started development that I came up with the idea to hook into WordPress core and register the custom post type taxonomies as actual taxonomies. Once this decision was made, the project grew tenfold but, boy, was it worth it. Not only did it make the plugin stronger but it kept the user from having to learn or implement new code. That, in itself, was worth every minute of development. Tack on an extensive custom post type manager, so the user can manage their custom post types within the admin, and you’ve got yourself a pretty powerful plugin. Is CPT-onomy an official WordPress term? No. It’s just a fun word I made up. =)

Using CPT-onomies

One of the best features of the CPT-onomies plugin is that you don’t have to create CPT-onomies to put the plugin to good use. Featuring a full-fledged interface, CPT-onomies allows you to create custom post types, and manage them, without touching one line of code! If you’re already using a plugin, or theme, that creates custom post types, don’t worry, CPT-onomies is all-inclusive. Any registered custom post type can be used as a CPT-onomy.

Learn more about CPT-onomies or download CPT-onomies. Refer to the plugin’s support forums or my CPT-onomies section if you ever need any help. If you can’t find what you need, or come across any bugs, please let me know.

I hope you enjoy using CPT-onomies as much as I enjoyed bringing it to life.

But, while I may tweet about all that stuff, RachelCarden.com will be a place to share my work, thoughts and ideas surrounding WordPress and my love for programming, problem solving, and the World Wide Web.

So make yourself at home. Learn more about my background, or follow me on Twitter, and take this little nugget of inspiration with you: “All our dreams can come true, if we have the courage to pursue them.” – Walt Disney