The early years

As I was growing up in smalltown Alabama, I always wanted to be a writer. From about the time I could hold a crayon, I was writing something. Writing on the walls. The kitchen table. Occasionally, on paper. From what my parents tell me, I could do this quite well at about the age of 3.

During my pre-teen years, I wanted to follow in my father’s footsteps and write songs, so music and lyrics were my first introduction to how beautiful language could be.

Eventually, I outgrew my songwriting phase. Be glad I did. The world certainly doesn’t need any more boy-band pop songs. I figured I could offer something of a little more substance to the world.

High school

In high school, I had the most wonderful English teacher. She was one of those teachers that understood that literacy is not just about basic reading and writing skills. Literature. Technology. Music. Film. Those are the things that matter. Don’t get me wrong. We still had to do the boring high school English class stuff. But, she opened my mind to the world outside of the small town I was living in.

At some point during my senior year I realized that I wanted to write. I mean really write. It was the first time I’d ever put “write a book” on my list of life goals.

College

I graduated from Auburn University in 2007 with a B.A. in English and a concentration in creative writing and journalism.

When I began college, I didn’t plan on having a degree in English. I was in software engineering. Then I was in hotel and restaurant management. Then I was in software engineering again. Like many other college students, I bounced around majors a few times. It was tough finding something that was both enjoyable and challenging.

Despite protests from friends and a few from my family, I decided to take the plunge and declare myself as an English major. What I found was something that I loved. How could anyone not love reading 20+ books a semester? I had the time of my life exploring ethnographic studies, novels, and even the Bible as literature.

Each professor impacted my life in some way. Each class allowed me to explore other cultures. Each friend I got to know, helped shape me.

By the time I graduated, I had narrowed my list of life goals down to a few things. At the top of that list: Write something that has an impact on someone’s life.

At some point during college, I also started learning HTML, CSS, PHP, and WordPress.

After college

Harsh realization that life is not all roses and peaches.

…Time spent wandering the globe…

I moved back to Alabama last year because I wanted to get back to my roots. I wanted to engulf myself in the white-trash, trailer-park, tobacco-chewing culture that I hadn’t been a part of in so long.

The plan: Observe the culture. Write.

I could give you at least 100 reasons why I haven’t finished a novel yet, but I won’t. There’s no point in trying to justify losing sight of my goal.

I also spent some more time playing around with WordPress during this phase of my life. I suppose that time could’ve been spent working on the great Southern American novel.

An opportunity

A few months ago, I received an email about collaborating on a WordPress plugin development book for Wrox, a company devoted to publishing books “by programmers for programmers.”

At first, I was a bit hesitant to take on any extra WordPress projects. It also meant that I wouldn’t be able to apply for teaching jobs this school year, which was one of my goals for 2010. And, it wasn’t quite what I had in mind when I put “write a book” on my list of life goals.

However, it was an opportunity to write about something I’m passionate about.

The book

We have a great team of WordPress minds melding for what will be an awesome WordPress plugin development book. Brad Williams, Ozh Richard, and I are the writers. We’ve also picked up Andrew Nacin as our WordPress technical editor.

As a sidenote to this: I’m convinced that Andrew is actually a super-advanced robot that has been programmed to do nothing other than write awesome WordPress code. And, I’m happy to have him on the team.

I don’t want to get into too many technical details about the book yet. I do want to say that it will be a great resource for professional plugin development. We will put everything we have into making this the best book on creating plugins available for WordPress.

For me, this book announcement is mostly about sharing my personal journey to this point. I am thankful that Wrox, Brad, and Ozh are giving me an opportunity to realize one of my lifelong dreams. And, I hope that all my readers will come along on this journey with me (and buy the book when it’s published in March).

Also, check out theses posts by Brad and Ozh:

• New Book: Professional WordPress Plugin Development
• Into Plugins? You Will Love This.

The question usually goes back to my original post on creating a movie database with taxonomies. In the tutorial, I explain how to make several taxonomies that represent people (actor, director, producer, and writer). Taxonomies give us a way to clearly label and organize what roles a person takes on within the production of a movie. The relationship between the given taxonomy and the movie post type usually stops there.

The question: How does one make an “actor” both a taxonomy term and a post of a specific post type?

That’s essentially what most of the questions boil down to. We want the clear organizational structure of taxonomies, but we also want each term in a taxonomy to behave as if it were a post/page with the ability to edit the content, upload media, have custom fields, and allow comments. So, we also need a “person” post type to handle this.

Creating taxonomies and post types is the easy part. Making the connection we want is the complex part of the question.

What we’re doing

In this tutorial, we’re trying to make connections between two post types and one taxonomy.

• Movie (post type).
• Person (post type).
• Actor (taxonomy).

In my movie database example, we’d be making the connection with several taxonomies. But, I want to keep this tutorial simple.

The goal is to create a “movie” and list its actors on the movie page. But, instead of going to an actor archive when clicking on one of the actor’s names, we want to visit a “person” page with custom content. This would allow you to write custom content, upload images, add videos, open up the commenting section, and do all the things you’d normally be able to do with posts.

On the movie database, when we see Tom Hanks listed as an actor, we’d want to visit a custom person page we set up for him.

Post type and taxonomy setup

The rest of this tutorial assumes a working knowledge of creating post types and taxonomies. The examples below will be limited and likely won’t be helpful unless you have an understanding of this process. Please read my previous tutorials on post types and taxonomies for a more in-depth review.

Open your theme’s functions.php file and add this PHP code to create the movie and person post types.

add_action( 'init', 'my_register_post_types' );

function my_register_post_types() {

	register_post_type(
		'movie',
		array(
			'public' => true,
			'labels' => array( 'name' => 'Movies', 'singular_name' => 'Movie' )
		)
	);

	register_post_type(
		'person',
		array(
			'public' => true,
			'labels' => array( 'name' => 'People', 'singular_name' => 'Person' )
		)
	);
}

Now, let’s add some code for our actor taxonomy.

add_action( 'init', 'my_register_taxonomies' );

function my_register_taxonomies() {

	register_taxonomy(
		'actor',
		array( 'movie' ),
		array(
			'public' => true,
			'labels' => array( 'name' => 'Actors', 'singular_name' => 'Actor' )
		)
	);
}

That should give us a simple setup to work with and base to build our new functionality on.

The biggest thing to note here is that we have to be careful with our actor and person slugs. When we create a new actor (term), we need to have the exact same slug as the person (post). For example, when creating the Tom Hanks “actor,” it needs to have the slug of tom-hanks. And, when we create the Tom Hanks “person,” it needs to have the slug of tom-hanks. Otherwise, the proposed solutions below won’t work.

Option #1: Changing term links to post permalinks

One option is to change the links to actor archives to a specific post. We’ll be working with term and post slugs in this step. I normally don’t recommend using slugs because IDs are usually best to work with. They don’t change and slugs can. Unfortunately, connecting the terms and posts via ID isn’t something we can do right now.

The code below will do this step automatically for you. What it does is filter term_link (link to actor archive page). It grabs the term slug (actor name) and searches for a post slug that matches the term slug and has a post type of “person.” If it finds the post, it switches the link for you. Otherwise, it does nothing.

If you’re listing a ton of terms on one page, this solution isn’t ideal unless you mix it in with a caching solution.

add_filter( 'term_link', 'my_term_to_type', 10, 3 );

function my_term_to_type( $link, $term, $taxonomy ) {

	if ( 'actor' == $taxonomy ) {
		$post_id = my_get_post_id_by_slug( $term->slug, 'person' );

		if ( !empty( $post_id ) )
			return get_permalink( $post_id );
	}

	return $link;
}

function my_get_post_id_by_slug( $slug, $post_type ) {
	global $wpdb;

	$slug = rawurlencode( urldecode( $slug ) );
	$slug = sanitize_title( basename( $slug ) );

	$post_id = $wpdb->get_var( $wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_name = %s AND post_type = %s", $slug, $post_type ) );

	if ( is_array( $post_id ) )
		return $post_id[0];
	elseif ( !empty( $post_id ) );
		return $post_id;

	return false;
}

Option #2: Redirect term archives to posts

In the above example, term archives are still publicly available. We’re not doing a redirect, so it’s possible for someone to still stumble upon the archive or for you to even make it available if you wanted to. But, if you’re looking for a way to redirect anyone that visits a term archive to the appropriate post, use the code below. This method is also a lot more efficient.

Use this code in your functions.php file.

add_action( 'template_redirect', 'my_redirect_term_to_post' );

function my_redirect_term_to_post() {
	global $wp_query;

	if ( is_tax() ) {
		$term = $wp_query->get_queried_object();

		if ( 'actor' == $term->taxonomy ) {
			$post_id = my_get_post_id_by_slug( $term->slug, 'person' );

			if ( !empty( $post_id ) )
				wp_redirect( get_permalink( $post_id ), 301 );
		}
	}
}

function my_get_post_id_by_slug( $slug, $post_type ) {
	global $wpdb;

	$slug = rawurlencode( urldecode( $slug ) );
	$slug = sanitize_title( basename( $slug ) );

	$post_id = $wpdb->get_var( $wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_name = %s AND post_type = %s", $slug, $post_type ) );

	if ( is_array( $post_id ) )
		return $post_id[0];
	elseif ( !empty( $post_id ) );
		return $post_id;

	return false;
}

Asking for a term meta table

There has been some discussion in the WordPress community about adding a term meta table to the WordPress core. I can list a ton of reasons this would be a great idea, but let me just focus on how it would make the above solutions even better.

Right now (in the examples), we’re calling up the database to search for a post based on a slug. This isn’t something I really like to do on the front end, especially with the first example. For example, listing 50 actors on a page using the first option would cause us to search the database 50 times to see if a post slug matches the taxonomy term.

A term meta table would easily solve this problem. We could save the post ID as metadata for individual terms. We could even do the post lookup in the backend instead of doing it on-the-fly on the front end of the site. Or, even provide a nice interface for easily selecting the post/term we want to connect. Having term meta would allow us to do a quick check if there’s a post we want to redirect to.

Other solutions and thoughts

The above solutions are just something I was tinkering around with because of the enormous number of questions I get about this. I haven’t fully explored every possible option, so I can’t say that either is the best route to take. Think of it more as “Justin thinking out loud” than a definite solution.

I would love to hear your take on other solutions or even solutions that we could try to get rolled into core to better handle metadata and relationships between post types and taxonomies.

The idea of parent/child themes was created so that the parent theme could be updated while keeping customizations intact within a child theme. That system works great. The problems begin when a child theme is updated. Users tend to want to take advantage of the update, but they can’t upgrade because they’ve made customizations.

Essentially, we’ve just added another layer to the preexisting problem.

But, that’s not where the real problem is at. The problem is confusion over what frameworks, parent themes, and child themes are. Users aren’t to blame for this confusion. Theme developers are at fault here (even me), and I’m going to attempt to clear things up.

Advanced parent themes are not frameworks

I’m going to avoid calling any other “framework” themes out and tell you that my own Hybrid theme is not a framework, at least not in the traditional development framework sense. It’s an advanced parent theme. Admittedly, I’ve called it a “framework” before because I’ve just been following the crowd.

What should we call the Hybrid theme? Simple. It’s a parent theme.

One thing we should definitely not confuse are the terms “framework” and “parent theme.” These two are not interchangeable. That’s where a lot of the confusion stems from.

What is a theme framework?

This is the question I most wanted to answer because I’ll be releasing a framework for theme developers soon (see below). But, I can’t do that with all this confusion floating around the community.

A theme framework is a set of conventions to use for developing WordPress [parent] themes.

Yes, that’s a bit vague, but frameworks can exist for all kinds of different purposes. This can be something like an elegant template engine (Carrington Core is really good for this) or a set of helper functions for more quickly building a theme.

It is not a theme though. You can’t simply drop it in your WordPress themes directory and expect it to work.

Frameworks are for theme developers. They offer a set of standards (or whatever features) for theme developers to use in creating their own themes. They’re a set of functions/features created to aid development.

What is a parent theme?

Nearly all WordPress themes are parent themes. Only those called “child themes” are not parent themes.

Theme developers create parent themes for users to download and install on their sites. My Hybrid theme is, without a doubt, a parent theme. Parent themes should house the theme design, functionality, and the templates required for running the theme in WordPress.

You can use a framework to build a parent theme, but the framework is not a parent theme itself.

What is a child theme?

A child theme is something users should be creating so that they can customize the look and functionality of their site. The child theme inherits all of its functionality from a single parent theme.

When a theme developer creates a child theme, things become problematic because that child theme might eventually need an update. If you’re a theme developer and are building a child theme with a 20kb functions file and five or six custom templates, I can assure you that you’re doing it wrong. I’ve even had to tell myself this.

What you should really be creating is a parent theme. Child themes from theme developers should be nothing more than a stylesheet and a few functions. This idea of releasing advanced child themes just creates the same problem child themes were meant to solve: upgradability.

I’ve got over two years of experience at this point in dealing with parent/child themes if you need a reason to take my advice on this.

How frameworks work

Confused yet? Let me break this process down for you and explain how it should work.

• Frameworks come packaged within a single folder.
• Developers drop the framework folder into a new parent theme and load the framework.
• Users create a child theme based on the parent theme to house their customizations, allowing both the framework and parent theme to be updated.

Here’s a diagram for reference:

Users should only ever have to worry about creating a child theme. This will allow them to make modifications without losing them when the parent theme is updated. They shouldn’t have to worry about all the other stuff.

As you can see by now (I hope), the question of grandchild themes has been completely averted because theme developers shouldn’t be adding advanced functionality (that might need future updating) within child themes.

Doesn’t Hybrid break these rules?

The Hybrid parent theme doesn’t break the rules. A couple of the child themes? Definitely. If I could afford a time-traveling machine (and if they existed), I’d zip back a year or two and turn a couple of those child themes into parent themes instead. We all have to learn from our mistakes, and I can freely admit that I’ve taken the wrong route on occasion.

So, I’m going to give you a real-world example of everything I’ve been talking about and how it could’ve been avoided with one of my own themes.

Hybrid has a child theme called Hybrid News. This child theme has a few extra features that make it more advanced than its parent theme. One good example of a problem was when WordPress 3.0 launched with a new menu system (which I love). The Hybrid News child theme has an extra navigation menu that’s not present within its parent theme.

The problem: How do you upgrade the Hybrid News child theme to use the the new nav menu system for its extra menu?

You certainly can’t expect users to upgrade the child theme and lose all of their customizations. To solve this particular problem, I wrote a tutorial on making the switch to the new system. But, it was just a way to avoid the larger problem at hand.

The solution should’ve been: Make Hybrid News a parent theme. This would allow it to be upgraded and users to keep their customizations intact.

If you’re a theme developer with a lot of advanced child themes, you may be thinking that you’ve got this problem all figured out. You may have already come up with plenty of nifty solutions for avoiding these types of problems. But, no one can foresee what new things will come in later versions of WordPress to conflict with those solutions.

Introducing Hybrid Core: A theme framework

Last year, I mentioned that I’d release Hybrid Core to the public for download. Unfortunately, that release never came out. I wanted some more time to perfect it, which turned out to be around a year worth of extra time.

Hybrid Core will be a theme development framework for use by other theme developers. What this means is that any theme developer will be able to download this and build parent themes with an awesome framework behind them. Yes, I’m essentially giving you the keys to the Theme Hybrid kingdom.

Hybrid Core is currently packaged within my Hybrid parent theme. It is used to handle the “logic” behind how the theme runs. Theme developers will be able to load this framework and build themes using the set of conventions provided by the framework. All of the HTML, CSS, and extra functionality will be left up to you.

In the next month or two, I’ll be putting the finishing touches on this. I’m still moving some stuff around that’s specific to the Hybrid parent theme and getting it out of the way.

It’d be awesome to see many great themes built off this framework. It’s a project that I started building in June 2008, so a lot of work and testing have been put into it. The next theme I build will be a parent theme based off it, so you’ll have a good, working example of how to use the framework.

Just in case you were wondering if building a “grandchild” theme is actually possible, the answer is no, at least not by default. And, I hope to never see the day it happens.

But, I still wanted a way to easily allow readers to visit my archives. I also wanted to not just show monthly archives like the standard WordPress archives widget. The method I decided on has three major benefits:

• Allows readers to find archives by year, month, and day.
• Doesn’t take up any extra space on my blog.
• The code was already written in my Breadrumb Trail plugin, so there wasn’t much I had to do.

On this blog and many others, we have a thing called a byline or dateline, which is usually located before or after the post title. Traditionally, the date the post was written is shown. But, it doesn’t do much. It just sits there. Yes, it provides valuable information to the user but not anything more than that.

What we’re going to do is link the various parts of the date to archive pages. We’re going to give the post date more purpose.

Creating the post date link function

The first thing we need to do is create a function in our theme’s functions.php file. Actually, we’re going to create a function and a shortcode. Just drop this PHP code in the file:

<?php

add_shortcode( 'entry-link-published', 'my_entry_published_link' );

function my_entry_published_link() {

	/* Get the year, month, and day of the current post. */
	$year = get_the_time( 'Y' );
	$month = get_the_time( 'm' );
	$day = get_the_time( 'd' );
	$out = '';

	/* Add a link to the monthly archive. */
	$out .= '<a href="' . get_month_link( $year, $month ) . '" title="Archive for ' . esc_attr( get_the_time( 'F Y' ) ) . '">' . get_the_time( 'F' ) . '</a>';

	/* Add a link to the daily archive. */
	$out .= ' <a href="' . get_day_link( $year, $month, $day ) . '" title="Archive for ' . esc_attr( get_the_time( 'F d, Y' ) ) . '">' . $day . '</a>';

	/* Add a link to the yearly archive. */
	$out .= ', <a href="' . get_year_link( $year ) . '" title="Archive for ' . esc_attr( $year ) . '">' . $year . '</a>';

	return $out;
}

?>

For non-American users, you might want to switch the dates around as I’m using the “Month Day, Year” format. The WordPress Codex also has a helpful guide on formatting date and time if you want to mix things up a bit.

Note to theme authors: Please don’t implement this function as is into your themes. There are tons of variations on the date/time format and we have to respect what the user chooses unless the design can’t be accomplished without a specific format. If you come up with a way to handle all scenarios, then by all means, go for it.

Using the published link in your theme

We’ve added the function to run this to our theme’s functions.php file. Now, we have to use the function in our theme. All themes are going to be a little different, so I can’t tell you exactly where to put the code. You’ll just have to look in your theme templates or ask your theme author how to do it. I can tell you that this code should go within The Loop.

This is the code you add to the template:

<?php echo my_entry_published_link(); ?>

That’s all the code you have to deal with.

If you’re using a super-intelligent theme like Hybrid, you can use the [entry-link-published] shortcode and not worry about adding the PHP function.

Or, if you’re not using Hybrid and just want to know how to run a shortcode in a theme template, try this out:

<?php echo do_shortcode( '[entry-link-published]' ); ?>

What are the benefits of doing this?

I count two main benefits:

• Providing an easy way for readers to visit your archives. It never hurts to implement more methods of keeping people on your site.
• It’s just something fun to do. Maybe spruce up your blog a little.

Maybe it’ll even help search engines crawl your site easier. I don’t know. I quit trying to figure them out a long time ago.

I hope you enjoy this little snippet of code. If you want to see it in action, I’m using it on my blog now. Just look at my post byline and you’ll see the date linked to three different archives.

I’ve been promising a real-world example of what’s possible with custom post types for a while. But, I didn’t want to put together yet-another-long-technically-detailed post. I wanted to give you something that would open your mind to the possibilities.

And, there’s loads of possibilities.

I’ve been tinkering around with the idea of building a forum plugin, so I decided to get behind the project completely and make it happen. What started out as a simple project quickly turned into something that a lot of people have been wanting — a forum plugin that fully integrates itself within WordPress.

Post types for the plugin

The plugin uses three post types for handling the structure:

• Forums: This is your top level, which holds everything else.
• Topics: Children of forums and use the topic tags taxonomy.
• Replies: These are the individual posts made within a topic.

I had originally taken a different route of using a forum taxonomy, topic post type, and reply comment type. However, using that structure had major limitations.

The benefits of using three post types are numerous. Here are some examples:

• Forums can have metadata (custom fields) and media attachments added to them to allow a lot of cool stuff (forum thumbnails, for example).
• You get pretty permalinks using a reply post type (forums/topic-name/page/2).
• Replies can also have their own media attachments (user-uploaded images).
• Capabilities/permissions are handled a lot better with post types.
• Can set up custom post statuses such as “closed” and use the current statuses like “private.”
• Works well with plugins that allow you to edit from the front end of the site.

This is not to say there aren’t issues with this method. There’s a lot of custom work work that needed to be done, which isn’t surprising considering I’m using custom post types.

I can’t take all the credit for this idea of using three post types. John James Jacoby convinced me this was the best route to go.

Taxonomies for the plugin

The only taxonomy used by default is the topic tag taxonomy. It allows users to assign tags to specific topics.

The great thing about the plugin though is that you can build custom taxonomies on top of it. You can give forums, topics, and replies their own taxonomies if you wanted. Since we’re using custom post types for those things, the possibilities are endless.

Integration with WordPress

Obviously, we want our forum plugin to work well with WordPress. Some of the current problems users of other forum software are facing when integrating are:

• Separate user login pages (and separate user database tables in some cases).
• Separate roles and permissions setups.
• Using multiple themes to get the same design across the site.
• Not being able to use WordPress plugins within the forum.
• Having to figure out how “deep integration” works just to use things like menus and widgets.

My plugin seeks to solve those issues and use the tools available in WordPress.

Lightweight

I’m not a fan of adding every fancy gizmo and gadget in the world to a forum. I like to keep things simple and extend it with other plugins when I need a new feature. I also don’t want 20 theme templates when I can use a handful.

The biggest goal I have is to keep this thing as lightweight as possible. There are over 10,000 plugins for WordPress that will allow this plugin to be extended.

What about the bbPress plugin?

While this is outside the scope of what I’d planned on writing about, I know questions about bbPress will crop up. I’ll try to address those.

It’s true that bbPress will be becoming a plugin in the future and work has already started on it. I’m happy that there’s at least something happening. I love bbPress and have been using it for years, but I can’t wait around six or seven months again to see where the project is headed. I’m not saying bbPress isn’t going anywhere, but I had to make the decision to move forward on my own after the last disappointment.

I’d love to be involved in the bbPress plugin project at some point, but my priorities right now don’t mesh well with it. It’d also be great if the ideas used in my plugin or any of its code gets used in the bbPress plugin.

One thing I will promise to plugin users is that I’ll try to make it as easy as possible to switch between either plugin if that’s what they choose to do.

Demo and testing

The plugin isn’t ready for a public release right now. There’s tons of work still ahead. But, testing does need to be done on a large enough scale for me to make this a solid plugin.

I’ve put the plugin on one of my own sites for live testing. If you have any interest in this plugin at all or just want to help test, please register for my forums at Pop Critics.

At first, I was a bit disappointed that this wasn’t taken care of because this would be a major blow to my plugin. However, I soon learned this could be considered a great feature rather than a bug.

Andrew Nacin mentioned that we’d need to “roll our own handling” for capabilities using the map_meta_cap hook. This hook gives you control over the meta capabilities as well as the power to step outside of the WordPress way of doing things. The more I play around with it, the more I’d rather WordPress not automatically map these.

Before reading on, please note that this is only an issue/feature if you’re using custom capabilities for your post types. If not, this might not interest you much.

What are meta capabilities?

Meta capabilities are capabilities a user is granted on a per-post basis. The three we’re dealing with here are:

• edit_post
• delete_post
• read_post

For regular blog posts, WordPress “maps” these to specific capabilities granted to user roles. For example, a user might be given the edit_post capability for post 100 if they are the post author or have the edit_others_posts capability.

When using custom post types, this mapping doesn’t happen automatically if you’re setting up custom capabilities. We have to come up with our own solution.

In this tutorial, I’ll be using the movie post type, so the above three meta capabilities for our purposes will be:

• edit_movie
• delete_movie
• read_movie

Setting up your custom post type

At this point, I’ll assume you’re familiar with creating custom post types. If not, you’ll want to read through my detailed tutorial on them. The code presented below will be an abridged version of what you might use.

We’re going to focus on two arguments, capability_type and capabilities. These control the permissions for what a user with a specific role can do with the post type.

As mentioned earlier, the post type we’re going with is movie. So, let’s set up that post type:

add_action( 'init', 'create_my_post_types' );

function create_my_post_types() {
	register_post_type(
		'movie',
		array(
			'public' => true,
			'capability_type' => 'movie',
			'capabilities' => array(
				'publish_posts' => 'publish_movies',
				'edit_posts' => 'edit_movies',
				'edit_others_posts' => 'edit_others_movies',
				'delete_posts' => 'delete_movies',
				'delete_others_posts' => 'delete_others_movies',
				'read_private_posts' => 'read_private_movies',
				'edit_post' => 'edit_movie',
				'delete_post' => 'delete_movie',
				'read_post' => 'read_movie',
			),
		)
	);
}

I’ve also added in a couple of extra capabilities that were not shown in my previous tutorial on post types: delete_posts and delete_others_posts. We’re going to use these to give people the ability to delete posts (movies).

Assigning capabilities to roles

To assign specific capabilities to roles, you’re going to need a role management plugin. A good one to use is my Members plugin. You could code this if you wanted, but it’s a bit outside the scope of this tutorial.

What you need to do at this point is assign capabilities to the roles that should have them. Just be careful not to give too much power to the wrong roles.

• publish_movies: This allows a user to publish a movie.
• edit_movies: Allows editing of the user’s own movies but does not grant publishing permission.
• edit_others_movies: Allows the user to edit everyone else’s movies but not publish.
• delete_movies: Grants the ability to delete movies written by that user but not others’ movies.
• delete_others_movies: Capability to edit movies written by other users.
• read_private_movies: Allows users to read private movies.
• edit_movie: Meta capability assigned by WordPress. Do not give to any role.
• delete_movie: Meta capability assigned by WordPress. Do not give to any role.
• read_movie: Meta capability assigned by WordPress. Do not give to any role.

Just to say it again: it is important that you don’t assign those last three capabilities to any role. These are our meta capabilities that we’ll be mapping in the next section.

Mapping the meta capabilities

This part is completely customizable. What we’re doing here is filtering the map_meta_cap hook so we can do our own mapping. What this means is that users will be granted meta capabilities on a per-post basis so they can do things like edit their own posts.

I’m going to keep it extremely simple and follow my notes from the previous section. If you wanted, you could do all kinds of crazy things here.

You can simply drop the below in your plugin or theme’s functions.php (whichever you’re using) and be done with it. It’ll follow the rules I set forth above.

add_filter( 'map_meta_cap', 'my_map_meta_cap', 10, 4 );

function my_map_meta_cap( $caps, $cap, $user_id, $args ) {

	/* If editing, deleting, or reading a movie, get the post and post type object. */
	if ( 'edit_movie' == $cap || 'delete_movie' == $cap || 'read_movie' == $cap ) {
		$post = get_post( $args[0] );
		$post_type = get_post_type_object( $post->post_type );

		/* Set an empty array for the caps. */
		$caps = array();
	}

	/* If editing a movie, assign the required capability. */
	if ( 'edit_movie' == $cap ) {
		if ( $user_id == $post->post_author )
			$caps[] = $post_type->cap->edit_posts;
		else
			$caps[] = $post_type->cap->edit_others_posts;
	}

	/* If deleting a movie, assign the required capability. */
	elseif ( 'delete_movie' == $cap ) {
		if ( $user_id == $post->post_author )
			$caps[] = $post_type->cap->delete_posts;
		else
			$caps[] = $post_type->cap->delete_others_posts;
	}

	/* If reading a private movie, assign the required capability. */
	elseif ( 'read_movie' == $cap ) {

		if ( 'private' != $post->post_status )
			$caps[] = 'read';
		elseif ( $user_id == $post->post_author )
			$caps[] = 'read';
		else
			$caps[] = $post_type->cap->read_private_posts;
	}

	/* Return the capabilities required by the user. */
	return $caps;
}

Now taking questions

I realize there’s still quite a few things that I might not have covered in my tutorials on post types so far. Some people have probably figured these out by now, but others of you may be stuck.

Feel free to ask any questions you have about post types, and I’ll see about answering them or writing more tutorials based on your suggestions.

The issue: Before WordPress 3.0 was released, a small piece of code was added to the WordPress core that changes all instances of “Wordpress” (notice the lowercase “p”) to “WordPress” in areas where content is shown on the site. We’ll get to the details in a bit.

I tried hard to stay out this debate because I’m fairly certain I made a vow to myself to stay out of these types of arguments. But, I’ve got a few opinions on this one that I can’t just keep to myself. And, as someone that is considered a leader within the WordPress community, I feel responsible for communicating with that community on this issue.

It’s spelled “WordPress”

WPCamelCase.com says so, and I’d never question an entire site dedicated to the proper spelling of a single word.

On a more serious note, these are not proper:

• Wordpress
• wordPress
• wordpress
• Word Press
• word press
• wordress
• WoRdPrEsS

Coming from an English and journalism (especially journalism) background, I feel a strong need to hack into the site of anyone that misspells WordPress and correct it for them. Fortunately, I don’t know how to hack people’s sites, have just a smidgen of self control, and respect the rights of others.

Why is there an issue?

Matt Mullenweg wrote a filter function called capital_P_dangit() that correctly capitalizes the “P” in misspellings of WordPress where the “p” is lowercase. It may seem like a minor thing, but there are several issues at hand.

• The code literally breaks things like URLs on some sites. For example, suppose you installed WordPress in a /Wordpress directory. That would cause all kinds of trouble with things like images.
• This function is effectively changing what people write, and WordPress should not have editorial control over the content of anyone’s blog.
• The code was committed to WordPress without a Trac ticket, so it wasn’t left open to community discussion beforehand.
• Matt’s responses seem to dismiss the very community of people that help make WordPress what it is.

Following the discussion

I cannot accurately represent all of the discussion that has happened to this point. I highly recommend that you read the discussions provided by the below links if you want all the details.

• “Wordpress” being turned into CamelCase “WordPress” breaks URLs
• Putting the P in WordPress: WP Hackers
• Automatically Correcting the WordPress Mistake
• Wordpress -> WordPress in core?
• MattPress Egomania
• “Wordpress” to “WordPress” filter
• A Fuss About Nothing
• CapitalP.org

Breaking URLs

If nothing else, this issue must be addressed. In fact, this bug was brought up in a bug report before WordPress 3.0 was released. Yes, before.

The resolution set for this bug: wontfix.

A new ticket is now open for discussion and resolutions. Mark Jaquith has at least created a patch that should fix this issue.

Don’t change my content

The real issue is not the bug; it’s the display of content that people didn’t write. Sure, the cases where people actually intend to misspell WordPress are rare, but that’s besides the point.

The point is that the content is yours, and you should be able to write anything any way you see fit, including “WordPress.”

If you want to debate that last statement in any way, I suppose you can try all you want, but I can’t think of a single reason why a piece of software should be able to control the output of my words without consent.

We’re talking about principles here, and changing what people write in this manner goes against everything I believe in. I simply refuse to allow this on my site.

One of the reasons I use WordPress is because of its philosophy on community, openness, and freedom, which fits along nicely with my own personal philosophy about most things in life. The idea that a piece of software could infringe upon those values is what bothers people.

What about emoticons and auto-paragraphs?

What about apples and oranges?

This line of reasoning keeps getting brought up in the debate.

If you think the forced spelling of a word and the opt-in process of converting smileys and basic word-processing are one in the same, there’s no convincing you there’s an issue. You may as well stop reading now.

Why don’t you build a plugin?

According to Matt Mullenweg, a plugin should be built:

As I said before, you are in /complete control/ of your site. It’s a single line to remove a filter. If you don’t like the filter, vote with your feet or with a plugin.

Vote with your feet? This type of remark represents one of the biggest issues in the WordPress community. Attitudes like this can bring down entire empires.

I completely agree with the plugin idea though. Building plugins to gauge community interest in certain features and making the decision to include these plugins in core code based on statistics is a great idea.

As pointed out by Jeff Chander, it just so happens that someone made a plugin nearly three years ago that does the same job as capital_P_dangit(). It’s called Ozh’ Correctly Spell WordPress.

At the time of writing, this plugin has received a grand total of…wait for it…338 downloads!

As flawed as that argument is, a new plugin has been created called Remove Wordpress to WordPress Filter that disables the capital_P_dangit() functionality. Funnily enough, its number of downloads will likely surpass the other plugin within a week or two given its current rate of adoption.

But, since we’re voting with plugins, there’ll be 16 other plugins that will disable this filter soon enough. All of my plugins will have this bug fix added to them in their next updates.

There’s two things that will make me reconsider this decision and remove this from my plugins:

• The capital_P_dangit() function is removed from the default filters or made to be opt-in.
• An outcry of arguments from my plugin users to remove it. Some of us listen to our users, even when we disagree with them.

Since some folks have missed the point of this last argument, which I thought was clever (though I’m a bit biased), I must inject a note here to interrupt the flow of this article. No, I don’t actually intend to update all 16 of my plugins to try and prove a point. The entire point is to show how irrational such an action would be.

How to remove the capital_P_dangit() filter

You can either install the Remove Wordpress to WordPress Filter plugin or add the below code to your theme’s functions.php file.

remove_filter( 'the_content', 'capital_P_dangit' );
remove_filter( 'the_title', 'capital_P_dangit' );
remove_filter( 'comment_text', 'capital_P_dangit' );

Listen to your community

I’ve only seen a handful of people that agree this function should be in WordPress. It has been met with harsh opposition. The people arguing to remove this function are people we need in the community. They’re plugin developers, theme developers, contributors to core code, and evangelists for the WordPress platform. These are the people that continue making WordPress better.

Don’t alienate them.

Are these people only a vocal minority of WordPress users? Certainly. However, these people speak for a larger amount of users. For users without the knowledge of mailing lists. For users without the understanding of how Trac works. They are the people that interact with the majority every day. They are the voice of the majority.

Don’t let their voices go unheard.