The topic I wanted to broach was CTR rate on Mobile Ads. Here is what I’ve found from several informal surveys I’ve conduced with colleagues, students, and other associates.

95% of ‘clicks’ or shall I say ‘taps’ on mobile ads served from mobile websites, or native apps are ACCIDENTAL.

Case in point: I’ve clicked on hundreds and hundreds of these ads in the 5 years I’ve been rocking an iPhone. I have NEVER purposely, with full intention, clicked on one of these mobile ads. Not once. Nada. Never. Zip. Zilch.

Am I a lone case here? Surely the advertisers are aware of this. Are they actually getting any ROI whatsoever from these ads? Can some advertiser weigh in here? Do you realize that 95% of all the ‘clicks’ on your ad were accidental, or done by my 3 year old son?

The mobile Ad space is really broken. Re-inforced by Apples alteration of their iAd and payout program for mobile ads over and over

A Quick Background

I noticed my website, that I converted to run mostly on WordPress, was dropping rankings in Google. I thought not too much of this, as I figured since a large portion of the site was being served differently, once Google had indexed and caught back up with my new method of madness, I’d climb back up.

I finally decided to go check out Google’s Webmaster tools (which I have set up on the site) to see if it was finding errors I hadn’t seen. Mind you, this is after several months. I quickly noticed something was real-bad-wrong when Google claimed that 70,000 of my links were returning 404′s!!!

So I starting clicking on the links Google claimed were dead. Not a single one of the pages returned a 404, nor showed my custom 404 page I had set up in WordPress. Not a one. Obviously something was still amiss. I snagged the handy Firefox plugin FireBug, and looked at the actual headers that were being returned by those pages. Sure enough. A good portion of my URL’s were giving 404′s. The strange thing, is that the page was returning and being loaded just fine…

After further searching I noticed a pattern. All of the 404 pages were custom pages that weren’t really part of the wordpress framework, but I was including WP functions in the following manner (like the docs suggest you’re supposed to do):


<?php
define('WP_USE_THEMES', false);
include($_SERVER['DOCUMENT_ROOT'] . '/wp-blog-header.php');
?>


Look familiar? If you’re reading this article, it probably does. It turns out that this will cause WordPress to throw a 404 header, even though the page displays! Because the actual .php or .html file is in the directory.

I started searching the net, and found several “solutions” to this problem. Some people were even suggesting just changing the title of the pages via filters to override the 404 not found titles!! BAD IDEA. Some were suggesting forcing a new header manually like so: header("HTTP/1.1 200 OK");

I don’t know why it works, but changing the code to include wp-load instead of wp-blog-header seems to fix the 404 error on custom pages! I haven’t found any adverse effects at all…

Here is the fix.


<?php
define('WP_USE_THEMES', false);
include($_SERVER['DOCUMENT_ROOT'] . '/wp-load.php');
?>


Thanks to the following post (with its own special fix), and more importantly http://www.adrogen.com/blog/wordpress-wp-blog-headerphp-causes-404-in-ie/comment-page-1/#comment-13325 for the final fix.

I wonder how many zillions of people have used this method when using custom pages with WordPress functions included and have no idea that their custom pages are sending 404 headers courtesy of WordPress?

First of all, let it be known that I teach for a living. I enjoy it. I teach at a 2 year college. I teach web design. Most of my students are “designers”. I’ve noticed a few things.

1. People think web design is easy. (thanks a lot wordpress, weebly, myspace, blogspot, frontpage, insert favorite WYSYWYG here etc..)
2. Most of the students sort of know what “HTML” is. (“It’s the Internet language stuff…”)
3. 6 years ago, most didn’t know who nor what HTML is.

This is a pretty significant shift, in a few short years.

With as pervasive as the internet has become, residing in most everyones pocket, the Internet and its language are the communication standard of the 21st century. I can see if a few short years. HTML being taught right alongside English, Math, & Science. Our middle schools will soon be teaching their students how to deliver, consume, and author content on the web. When they reach college level learning, HTML will be like English. It will be the non-verbal communication tool that all people will need to know. Those who don’t learn it, will be the minority or disadvantaged.

Whether or not they use the language daily or not, they will be better employees/managers for having attained the skill.

HTML is the new English my friends.

Maybe in some future not-so-distant date, instead of the facebook and twitters and picassas, and g pluses, we will all just have our own domains. Instead of signing in to a business site to make social connections, I just connect my domain to my friends domain. I control my content, my look, my ads, my design, my services, my widgets etc.

Aside from the business/entertainment side of the web, I see the “Social Web” as a giant mashup of Blogspot blogs meets Facebook meets Myspace, meets Twitter meets WordPress.org CMS meets RSS meets XML, where users are in control of their own domain, and create sites that are more of an extension of themselves. The connections are made between the domains. Standards arise to define new types of “social” content syndication. People write widgets and plugins that users can easily integrate/subsribe to/purchase.

The evolving notification world of mobile comes to the web. I’m notified of the ongoings of my social domain. I lose my address books and “contacts”. These social connections are my contacts. I decide how to categorize or label them. The programmers and developers create the products, I am the master of my domain. HTML gives me that ability and power.

HTML is the new English.

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.)

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!

Iphone app for kids

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

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

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

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.

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.

: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.

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

Andrew

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.

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.

These 5 cameras here are obviously not the most expensive and feature packed, but excellent digital cameras for under a $1000 dollars.

My first choice is a camera that I bought from newegg for $799.00 a week ago. Now it’s $725!

1. Nikon D80 – info from dpreview.com

2. Canon 400d (Digital Rebel xti) – info

3. Pentax k10d info

4. Nikon d40x info

5. Canon eos30D info

Remember that it’s not the camera thats going to take the perfect photo, but the photographer. If your budget is tight, go with the nikon d40x, or the canon Digital Rebel, and spend the extra money you would have spent on a more expensive body on a more expensive lens.

Remember: A high quality lens and cheap body will take much better pictures than a cheap lens with a high quality body.

beta.netscape.com

Just goes to show the power of keywords and how they relate to SERP’s. Go ahead, try it, it’s funny.

This anomily is knows as Google Bombing. A famous example is the search for “miserable failure,” which turned up George Bushes name.