WordPress Custom Fields in Comments

July 11th, 2011

I’ve been tinkering with how to add custom fields to my wordpress comments. It turns out the documentation is sort of sparse in regards to doing so, but a few helpful posts, and some digging inside of the comment-template.php core file finally got me there.

The Background

I’ve got regular posts and such with regular comments. I’ve got a custom post type set up for a section of a site thats called “units”. I wanted this custom post type to have it’s own special comments with the additional custom fields (It could be star ratings, drop down menus, extra input fields, whatever.) I wanted regular comments everywhere on the site, except comments that were of that ‘unit’ post type. Since WordPress 3.0, there is a new generic form for handling comments. In specific, this function call ‘comment_form()’ loads it up. This tutorial assumes your working with something later than 3.0 and using this new method of calling and formatting comments…

The Solution

Step: 1

The first thing is we have to set up a new comment.php template file, which we will include in our single.php post type pages. The easiest way to do this, is just make a copy the comments.php and rename it comments-units.php. That way we can have the two separate comment template files, and load them wherever we choose.

Find your ‘single-units.php’ file, (or whatever template file you want to add your new comments to, and change this:

comments_template( '/comments.php', true );

To this:

comments_template( '/comments-units.php', true );

The ‘true’ second parameter makes WordPress sort ‘trackback’ comments separately from ‘regular’ comments

Step: 2

Open up your comments-units.php file and find this line of code (near the bottom)

<?php comment_form(); ?>

Replace that comment_form line, with the following bit of code. Of course, customize for your own needs.

<?php
$args = array(
		'id_form' => 'commentform',
	    'id_submit' => 'submit',
	    'title_reply' => __( 'Leave a Unit Report' ),
	    'title_reply_to' => __( 'Leave a Reply to %s' ),
	    'cancel_reply_link' => __( 'Cancel reply' ),
	    'label_submit' => __( 'Post Report' ),
		'comment_field' => '<p class="comment-form-comment">' . '<label for="comment">' . __( 'Unit Report' ) . '</label>' . '<textarea id="comment" name="comment" cols="45" rows="12" tabindex="4" aria-required="true"></textarea>' . '</p>'
		);

      comment_form($args);
?>

Note: This comment_form() function initiates the comment form. We pass an variable with a set of arguments to ovverride some of the default items of the comment form. For a full list, see the wp codex directory.

Step 3

Now we need to add whatever custom fields we want, to the default “name, url, website” fields.
I’ve got two simple text input fields I’m adding to the comments here. You can add as many or any type of form field.

global $mm_extra_fields;
	$mm_extra_fields = array(
		'hidden_field1' => '<input id="type" name="type" type="hidden" value="unit-report" size="30" />',
		'field1' => '<p class="comment-form"><label for="species">Species</label><span class="required">*</span><input id="species" name="species" type="text" value="ex: Mule Deer" size="30"></p>',
		'field2' => '<p class="comment-form"><label for="terrain">Terrain</label><input id="terrain" name="terrain" type="text" value="ex: High Altitude, Rocky Terrain" size="30" aria-required="true"></p>'
	);

I’ve put my fields inside of a variable called $mm_extra_fields. This variable is an array, with keys and values. The value for each key is the HTML that I will output via wp filters to the default fields list. I’m giving it global scope, so I can use it inside of my hook function below

Here is the hook, that adds the above fields, to the comment form list.

add_filter('comment_form_default_fields','mm_extra_fields');
	function mm_extra_fields($fields) {
		global $mm_extra_fields;
		foreach($mm_extra_fields as $mm_extra_field_key => $mm_extra_fields_html){
			$fields[$mm_extra_field_key] = $mm_extra_fields_html;
		}
		return $fields;
	}

You can see that we’re just looping over our array via foreach, and adding new keys and values to the the $fields[] variable. Once were done, we return the $fields variable, which has our new fields attached! Wallah. We’re half way there…

You can see the before and after in the following photo. (Don’t stop here, as there are a couple of “gotchas” ahead.)

custom comment fields worpdress

Step 4

One or two notes. If your using your own CSS or forms, style accordingly. I’ve had to make a few additions to the TwentyEleven css file, to get my new fields to style the same as the other defaults. Namely the paragraph tag, that surrounds the form element. I gave mine the generic class name of 'class="comment-form"'
You’ll need to go add css styles to accommodate for this class name.

For example, you’d need to modify all of the css blocks, that deal with comment form styling to look something like this: (note I added my comment-form selector to the top of the grouped selectors). There are a few other spots you’ll need to do the same…

        #respond .comment-form,
	#respond .comment-form-author,
	#respond .comment-form-email,
	#respond .comment-form-url,
	#respond .comment-form-comment {
		position: relative;
	}

Step 5

Here’s one of those gotchas. Everything looks fine and dandy so far, but you’d sooner or later (hopefully sooner) realize that IF the user is logged in, all of your custom comment fields go away. Not good. Not good at all.

Luckily there is a relatively easy fix for that. We call upon another hook to add our same fields, if the user is logged in. Here’s the code.

	add_action( 'comment_form_logged_in_after', 'mm_extra_comment_fields_logged_in',10,2);
	function mm_extra_comment_fields_logged_in($commenter,$user_identity){
		global $mm_extra_fields;
		foreach($mm_extra_fields as $mm_extra_fields_html){
			echo $mm_extra_fields_html."\n";
		}
	}

We’re re-using our array of extra fields we created earlier, and following the same logic on the first filter. We’re just using a different hook this time…

Step 6

Get some ice cream already!

Step 7

Okay, so we have our form, it loads properly both when and when not logged in. Now we just need a couple of more hooks to actually SAVE the form data into the database, and retrieve it to display with our comments… Easy, right?

To save the custom comment fields, we call the function ‘add_comment_meta()’ in the comment_post hook

add_action ('comment_post', 'mm_add_comment_meta', 1);
function mm_add_comment_meta($comment_id) {
	if(isset($_POST['type'])){
		$type = wp_filter_nohtml_kses($_POST['type']);
		add_comment_meta($comment_id, 'comment-type', $type, false);
	}
	if(isset($_POST['species'])){
		$species = wp_filter_nohtml_kses($_POST['species']);
		add_comment_meta($comment_id, 'species', $species, false);
	}
	if(isset($_POST['terrain'])){
		$terrain = wp_filter_nohtml_kses($_POST['terrain']);
		add_comment_meta($comment_id, 'terrain', $terrain, false);
	}
}

That’s it. Whenever a comment gets posted, it will add our extra fields to the “comments_meta” database table. This works exactly like ‘custom_fields’ for regular posts. It’s all just stored as meta data, but in it’s own comments_meta table. Spiffy. The wp_filter_nohtml_kses function strips out any html tags from the data, so users can’t upload malicious scripts or html… There are several other validation functions in the codex to ensure safe data…

You might have noticed that in the first code drop, I actually had a hidden field called ‘type’ that gets added along with my two visible fields. I’m adding this, so I can flag comments to be my special ‘type’ in the database. This is sort of a hack, and no official documentation on how this should be used, but I’ll show it for completeness sake.

Just like regular posts have a ‘post_type’ field, comments have a “comment_type” field. WordPress only uses 2. If it’s blank, that means it’s a regular comment, if it’s not a regular comment, it might say ‘trackback’. Right now, I think those are the real only use cases.

Since I have my own ‘type’ of comment, I decided to add ‘unit-report’ in that field of the comment being inserted. This allows me to run custom queries on the DB and get all comments that are of type=’unit-report’ should I need. Here’s how.

add_filter('preprocess_comment','mm_unit_comment_type');

function mm_unit_comment_type($commentdata){
	global $post;
	if ($post->post_type == 'units' {
		$commentdata['comment_type'] = 'unit-report';
		return $commentdata;
	}
	else{
		return $commentdata;
	}
}

First we check to make sure the comment is coming from comments of our custom post type ‘units’, if it is, we add the comment_type of ‘unit-report’. That’s really it.

Step LAST

The lastliest thing we need to do, is display our custom meta values on our comments. This is pretty easy. I imagine most people are using the callback method for displaying posts, which is the way the default themes do it. In order to make this work, you’ll need to go find that callback function call. It looks like this, and should be in the middle of the the template file comments loop. (The function name is twentyeleven_comment)

wp_list_comments( array( 'callback' => 'twentyeleven_comment' ) );

Find that callback function (in your functions.php file) and edit the line that looks like this:

<?php comment_text(); ?>

I made mine look like this. (We simply use a function called ‘get_comment_meta’, which takes the comment id, and key-name.) Setting the third parameter to true makes it output a string, if set to false, it will return an array

<div class="comment-content">
	<?php
		if(is_singular('units')){
			?>
			<p><?php echo "Species: ".get_comment_meta( $comment->comment_ID, 'species', true ); ?></p>
			<p><?php echo "Terrain: ".get_comment_meta( $comment->comment_ID, 'terrain', true ); ?></p>
			<span>Unit Report:</span>
			<?php
		}
	?>
	<?php comment_text(); ?>
</div>

Now we’re really done. I do a quick check to see if we’re on a comment page of my post type of ‘units’ (because both regular comments and my special ‘unit comments use this same callback for display) if so, we display the extra fields from the database we added earlier! Phew. That was lot.

Comment and ask questions, or suggest better/alternate ways of noodling. If you’ve made it this far, congrats. There is admittingly ONE thing missing. Now way to “edit” the custom wordpress comment fields on the back-end, like you can with regular comments. Maybe I’ll look into this later…

Style to taste!

final custom meta

Kids iPhone App

February 21st, 2011

My first kids iPhone app is out. It’s called Toddler Trainer. It’s a simple learning game where your kids learn shapes, objects, numbers, letters, and words. Several different mini-prizes exists for successful level completion. If you’ve got kids between 1 year and 3.5 years, check it out, I’m sure they’ll love it.

Iphone app for kids

The app features over 200 individual objects, all accompanied with voice over.

Realistic CSS3 Box Shadows

November 3rd, 2010

Update: Here is a working demo

Want to learn how to create the sexiest most real looking box shadows using pure CSS? Then I’ve got a trick for you. The standard Box Shadow that you can apply via CSS3 to a box is rather bland. It may look something like this.

Note: If you like this effect, please link to my post, don’t steal! Thanks.

boring shadows

Boring Shadows

It is nice and all, and a nice leap from having to do shadows with png background images and such, but it doesn’t quite cut it for me. So with a few tricks, and some magic. We’ll be creating this.

Sexy CSS Box Shadow

Sexy CSS Box Shadow

It gives the effect that the page is “curling” or lifting off of the page. This effect is achieved with PURE CSS and ONE single <div> tag!

Let’s get started.

The first thing we will need to do is set up our HTML. It is as basic as it gets folks.

Step 1

Simply create the following in your HTML document.

Text Here

Now that we have our Box in place, we can do the fancy stuff in CSS. We’ll be using CSS gradients, CSS Box Shadows, and CSS Text Shadows, but the actual trick, or effect comes into play with several “experminetal” css features. Namely: -transform [rotate,skew] and the Pseudo selectors :before and :after. We also throw in some z-index, and other goodies, but my particular effect (which I think I am the first to create) uses SKEW to make it all work.

The CSS Stuff

We need to set up our div via CSS with some basic styles. The following code, sets up our box, gives us a gradient background, gives our box an initial shadow, makes our entire page background gray, and centers our box on screen.

NOTE: I’ve only included the -webkit prefixes which will work on Safari, and Chrome. If you’re working in Firefox, please prefix accordingly. If you have no idea what I’m talking about, then you ought to learn about css prefixes first. Also check out Jeffery’s screencast at NETTUTS for a different sort of shadow but uses some of the same principles.

Step 2

body{
	background-color:#ddd;
}

#box{
	width:300px;
	height:300px;
	margin:50px auto;
	position:relative;
	background: -webkit-gradient(linear, 0 0, 0 100%, from(#fefbb0), to(#fff955));
       -webkit-box-shadow: 0px 0px 3px rgba(0, 0, 0, 0.4);
}

Here is what it should look like.

box with Gradient

Simple Box, with CSS shadow and CSS Gradient Background

Step 3

Next we need to add the pseudo selector of :before and :after, which are sort of like “layers” of our box. This allows us to create new shadows and rotate and skew those “layers” separate from our original box. Thus allowing for nifty shadows. Here is the CSS.

#box:after{
	-webkit-box-shadow: 8px 12px 10px rgba(0, 0, 0, 0.7);
    position:absolute;
	content:'';
	background:transparent;
	bottom:10px;
	right:9px;
	width:70%;
	height:70%;
    -webkit-transform: rotate(5deg)
					   skew(10deg);
}

This takes advantage of the :after selector. We create another box shadow on our new “layer” make its background transparent, rotate it, and skew it, then use css positioning to move it to the bottom right of our original box.

This is what things should look like.

Box Shadow, skewed rotated

:after box shadow: rotated, skewed, and positioned.

I am going to leave the shadow in “front” of our box, so you can see how my magic skew comes into play, to create the more realistic shadow.

Step 4

Next we do almost the same thing, except we use the “:before” pseudo selector, and skew our box at a different angle, and make its shadow “WHITE”. This is the important part, to sell the effect.

Here is the CSS

#box:before{
	-webkit-box-shadow: 11px 11px 32px rgba(255, 255, 255, 0.7);
    position:absolute;
	content:'';
	background:transparent;
	bottom:46px;
	right:41px;
	width:50%;
	height:50%;
    -webkit-transform: rotate(20deg)
					   skew(45deg);

}

This is what it should look like. You should now be able to see the “ah-hah” of what i’m getting at.

both css box shadows

Boths CSS Shadows, one white, one black

Step 5

The last thing we do is add the z-index to our before and after selectors to move the shadows behind the box, not in front.

Give your :before selector a z-index of -1, and your :after a z-index of -2;

Before

	z-index:-1;

After

        font-family:Arial;
	font-size:3em;
	color:#fffb9b;
	text-align:center;
	text-shadow: 1px 1px 2px rgba(255, 255, 255, 0.6),
				-1px -1px 1px rgba(0, 0, 0, 0.4);

And that’s it! This only opens up some of the possibilities of the shadows! By nesting another div or image in our original box we could open up a whole other dimension of fancy shadows and potentially create complex shadows on both sides of the box.

By varying the degree of “blur” in the shadows we can create different levels of depth for sharp or soft shadows. Link to me, as I appreciate the juice.

Sexy CSS Box Shadow

Sexy CSS Box Shadow

Andrew

Add custom post types to wordpress main feed

June 21st, 2010

Background

I wanted my custom post types that I created in my last writeup (custom post types with archive page) to appear in my wordpress main feed. By default the custom post types do not get added to the main feed that wordpress creates. In my last write up I showed how I added the necessary rewrite rules in order to have the structure: www.domain.com/custom-p-type/feed. This will create a feed with all of those custom post types. Perfect. But what about my “main” wordpress feed?

What I wanted

What I wanted is for my www.domain.com/feed to include ALL of my sites content. Be it posts, or custom post types that I create. There are a couple of methods I found for doing this. I finally found the solution on the track in this ticket. http://core.trac.wordpress.org/ticket/12943

The solution

Here is what will add your custom post type content to your sites main feed, and leave your regular custom post type feeds specific for their respective content…

function myfeed_request($qv) {
	if (isset($qv['feed']) && !isset($qv['post_type']))
		$qv['post_type'] = get_post_types($args = array(
	  		'public'   => true,
	  		'_builtin' => false
		));
		array_push($qv['post_type'],'post');
		return $qv;
}
add_filter('request', 'myfeed_request');

The explanation

Thats it! Done. This code checks to see if the query var ‘feed’ exists, if it does it also checks to see if the ‘post_type’ query var IS NOT set. If the post_type query var is set, this means we are on one of our regular custom post type pages, and we don’t want to modify the way the feeds are genereated, as wordpress handles them out of the box.

So, if we are on a “feed” page, and we don’t have a post_type query var set, we must be on the home page feed (in my case). So we modify the default feed by querying for all custom post types that are not built in, and that are public using the get_post_types() function. We then append the “post” post type to the end with array_push, because I wanted my main feed to include all my custom post type content, as well as my regular post content.

Now I have the structure: mydomain.com/feed/ Which houses all of my sites published content, and each custom post type has its respective feed at mydomain.com/custom-p-type/feed/

Thingabeauty.

Custom Post Types WordPress 3.0 with template archives

April 15th, 2010

UPDATE: As of WP 3.1, custom post types archive pages are built in! (No doubt in response to this an other similar posts…) You just need to set the new ‘has_archive’ parameter to ‘true’ when registering the post type.

I’ve been playing around with the latest nightly betas of wordpress 3.0, especially the custom post type feature.  It looks great for what I want to do, but doesn’t exactly seem “ready”.  I’ve read various blogs and posts about custom post types trying to get a grips on making this lovely little feature do what I want.  Namely http://kovshenin.com/archives/extending-custom-post-types-in-wordpress-3-0/ and WordPress Codex, and this plugin http://wordpress.org/extend/plugins/cms-press/

I tried reading various tutorials on the web, and nothing really did what I wanted, so I’ve decided to make my own tutorial on how to create custom post types in wordpress 3.0 with archive pages.

The code within the plugin was finally what got me what I wanted.  So if your looking how to use custom post types in WordPress 3.0 and want to have your own archive template file with each of your custom post types then this post is for you.  I really JUST started to look into themeing and code in WordPress, so much of my work is borrowed from the sources listed about, and may not be the optimal way of doing things.  If you know of better/other ways to accomplish this, please pipe up in the comments, we’re all friends here.  I’ll try and explain the steps in detail so noobs like myself can follow along.

Here is what I wanted:

  1. A custom post type, we’ll say called “stories” that allows me to add stories in the wordpress backend.
  2. The URL of that custom post type to be an “archive” page of all the stories e.g. (www.domain.com/stories/)
  3. Each story to have its own structure like so (www.domain.com/stories/my-first-story/)

WordPress does numbers 1 and 3 automatically for you after you register the custom post type in your themes “functions.php” file.  This is done like so:

1st – Register the new Custom Post Type with wordpress

register_post_type('stories', array(
	'label' => __('Stories'),
	'singular_label' => __('Story'),
	'public' => true, // Allows it to be publicly queryable
	'show_ui' => true, // Displays the post time in the Admin Interface
	'_builtin' => false,
	'_edit_link' => 'post.php?post=%d',
	'capability_type' => 'post',
	'hierarchical' => false,
	'rewrite' => array("slug" => "stories"), // the slug for permalinks
	'supports' => array('title','editor','author','custom-fields') // What can this post type do
));

The code above will create a new link in your admin area where you can add the custom post type. If you don’t believe it, go ahead and add it to your functions.php file and check it out!

Number 2 turned out to be a LOT more tricky than I initially believed.  Before I get to the solution that worked for me, I’ll give a bit of background.

When you register a new custom post type in wordpress 3.0 it automatically creates rewrite rules for that post type.  (Which is what makes domain.com/stories/my-cool-story/) possible.  It doesn’t create any rewrite rules which would allow for (domain.com/stories/) to show an archive page.  If you tried to type that in, you would get a 404 not found.

The default rewrite rules that wordpress creates for your custom post types is like so:

[stories/[^/]+/attachment/([^/]+)/?$] => index.php?attachment=$matches[1]
[stories/[^/]+/attachment/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[stories/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[stories/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[stories/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]
[stories/([^/]+)/trackback/?$] => index.php?stories=$matches[1]&tb=1
[stories/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?stories=$matches[1]&feed=$matches[2]
[stories/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?stories=$matches[1]&feed=$matches[2]
[stories/([^/]+)/page/?([0-9]{1,})/?$] => index.php?stories=$matches[1]&paged=$matches[2]
[stories/([^/]+)(/[0-9]+)?/?$] => index.php?stories=$matches[1]&page=$matches[2]
[stories/[^/]+/([^/]+)/?$] => index.php?attachment=$matches[1]
[stories/[^/]+/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[stories/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[stories/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[stories/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]

The current WordPress beta has the logic built into the templating system to look for a file called single-(custom-post-type).php for the custom post types “singular” pages.  So in my case the url (domain.com/stories/my-cool-story/) would be looking for a template file called “single-stories.php” in my themes folder.  If that file doesn’t exists it will use the regular single file, or eventually fall back on the “index.php” file.  Depends on how your theme is set up.

So the problem is that first, there are no rewrite rules for /stories/ to work.  Second, there is no logic to re-direct /stories/ to a template file which would show an “archive” of my stories.

The Solution.

2nd – Add new rewrite rules

After you’ve registered your custom post type, like I showed earlier in this post, we have to set up some re-write rules for our new shiny post type.  This is done like so.


add_new_rules();
function add_new_rules(){

	global $wp_rewrite;

	$rewrite_rules = $wp_rewrite->generate_rewrite_rules('stories/');
	$rewrite_rules['test/?$'] = 'index.php?paged=1';

	foreach($rewrite_rules as $regex => $redirect)
	{
		if(strpos($redirect, 'attachment=') === false)
			{
				$redirect .= '&post_type=stories';
			}
		if(0 < preg_match_all('@\$([0-9])@', $redirect, $matches))
			{
				for($i = 0; $i < count($matches[0]); $i++)
				{
					$redirect = str_replace($matches[0][$i], '$matches['.$matches[1][$i].']', $redirect);
				}
			}
		$wp_rewrite->add_rule($regex, $redirect, 'top');
	}

}

This bit of code I mostly took from the CMS Press plugin mentioned above. Check it out, it’s pretty sweet.

Which should produce the following NEW rewrite rules which are added to our already default rules that WordPress supplies us.  For a total of 19 rules/ custom post type.  (Someone could possibly speak to how many rules would be “acceptable” for a medium sized website in production, as I’m not really sure what constitutes “to many” rewrite rules when it comes to performance in WP…)

[stories/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?&feed=$matches[1]&post_type=stories
[stories/(feed|rdf|rss|rss2|atom)/?$] => index.php?&feed=$matches[1]&post_type=stories
[stories/page/?([0-9]{1,})/?$] => index.php?&paged=$matches[1]&post_type=stories
[stories/?$] => index.php?paged=1&post_type=stories

Notice that we added  the variable “post_type=stories” to each of our url’s that we rewrote.  This will allow us to redirect to our custom template in the next step.

Note: I’m not sure really where to hook this function so that it doesn’t make rewrite rules on each page load.  Really we only need to write the rules each time the permastructure changes, or we add a new post type, but I’m not sure how/where to do that.. Any ideas?

If your having troubles getting that rewrite rule to work, go and re-update your permalinks settings page.

3rd – Redirect requests on our new rules to our custom template files

So now we are going to add a hook into the system to over-ride the default templating system, because as mentioned in the background info section, wordpress doesn’t have this built in.

We essentially are checking to see if the variable “post_type=stories” exists in our query vars.  If it does, then we set up the feeds and trackbacks stuff that wordpress does, and we redirect to one of two theme files.

If the “name” variable isn’t in our query vars, then obviously the query is for the archive page, as the name variable only appears when we are requesting a single post.  So we redirect to a template file called “single-stories.php” if the name file does exists, (which is what wordpress would have done normally) and we re-direct to a template file called “single.php” if the name variable doesn’t exist.

Here’s my code:


	add_action("template_redirect",'template_redirect');
	function template_redirect()
	{
		global $wp;

		$muley_custom_types = array("stories");

		if (in_array($wp->query_vars["post_type"], $muley_custom_types))
		{
			if ( is_robots() ) :
				do_action('do_robots');
				return;
			elseif ( is_feed() ) :
				do_feed();
				return;
			elseif ( is_trackback() ) :
				include( ABSPATH . 'wp-trackback.php' );
				return;
			elseif($wp->query_vars["name"]):
				include(TEMPLATEPATH . "/single-".$wp->query_vars["post_type"].".php");
				die();
			else:
				include(TEMPLATEPATH . "/".$wp->query_vars["post_type"].".php");
				die();
			endif;

		}
	}

That way I can have custom 2 separate custom template files (post-type.php, and post-type-single) for each of my custom post types.

You would need to do that code for each of your custom post types, or write a little function to loop through an array of your custom post types and set them up automatically.

It would be nice if I could query wordpress for my custom post types and have it all be dynamic, but I haven’t looked into seeing if wordpress stores the custom post types in the DB.??

Anyway, that should get you started on hacking around with Custom Post Types.  I think that this should be the DEFAULT way that wordpress handles custom post types.  It seems to me logically that almost everyone is trying to do this by default with their wordpress installations that are running more “CMS” style instead of “blog” style.  Previously most everyone did this same sort of structure with categories and such with the Posts, but this way is much more organized if you ask me.

You can also add custom taxonomies (categories) for each of your custom post types should you so be inclined.  i.e. stories could be divided into fishing stories, hunting stories, hiking stories, etc.  however, we are focusing solely on post types in this tutorial.

Things to note:

-The title tags for your custom post type archives page won’t work.  I haven’t looked into how to fix this yet, as I have no idea how wordpress does titles, let alone for custom post types and custom rewrite rules.??  Any insights would be helpful.