Justin Tadlock » WordPress

Custom Classes: WordPress Plugin

Justin Tadlock — Mon, 06 Feb 2012 18:39:33 +0000

For a recent project, I needed a way to add custom post and body classes on a per-post basis. Sure, I could have used a category or tag to style each post, but I hate creating custom categories and tags for the purposes of styling a post. So, I created a small plugin to let me add custom classes for individual posts.

How the plugin works

The plugin adds a custom meta box on the edit post screen for any public post type called “Classes” as shown in the following screenshot.

The meta box allows you to enter a custom class for a post (used by the post_class() function) or a custom body class (used by the body_class() function).

The following screenshot shows what your class will look like in the source code on a single post.

All you have to do is style your posts via CSS using the custom classes you’ve addded.

Download the plugin

You can download the latest version from the WordPress plugin repository: Custom Classes Plugin. I hope you enjoy it and find some use for it in your projects.

Please do not ask support questions in the comments below. If you’re in need of plugin support, head over to the Theme Hybrid support forums, which is where I handle support for all my plugins and themes.

One multi-task plugin vs. several single-task plugins?

Justin Tadlock — Sat, 21 Jan 2012 14:57:47 +0000

Recently, I’ve been giving a lot of thought to the debate over whether it’s better to develop larger plugins that handle many related tasks or smaller, mini-plugins that handle extremely specific tasks. There’s merit to both arguments, but I wanted to give my readers a chance to discuss this and help me come to a decision about how I developer some of my future plugins.

The biggest reason for this article is that I’ve been trying to make a final decision on how one (or multiple as the case may be) of my plugins will be developed. Other plugin developers might also find this discussion useful in helping them make decisions.

The example plugin

I want you to have an example of what I’m asking you to discuss, so I’ll give you a few details on the plugin(s) I’m developing. It is a set of extensions to how comments are handled in WordPress. Some of these extensions include:

Moderate all non-Enlish comments.
Automatically delete spam on a schedule.
Turn on/off comments for specific post types by default (like with posts).
Moderate all trackbacks and pingbacks.
And more.

The plugin currently has several options like the above. Basically, it’s just an extension to the “Discussion Settings” page in the WordPress admin. It’s easy to see how some users might only want to use one or two of those settings rather than all of them.

Advantages of a single, multi-task plugin

The following is a list of some of the advantages to running a single plugin:

You only have to run one plugin. Many people live in fear of running “too many plugins” because it might somehow break their site. Realistically, running too many large or poorly-coded plugins would be more of a problem. While you can’t really have too many plugins, this fear from users is something to consider.
Fewer things to manage. No one likes to update plugins every day. The more plugins you have, the more likely you’ll have to update them frequently. Having to only update a single plugin instead of several is easier.
Fewer translation files. Translators would only have to update and maintain a single translation file for one plugin as opposed to multiple translations for multiple plugins.

Advantages of multiple, single-task plugins

The list below is some of the advantages of using several plugins.

You don’t have to load code you don’t need. Using mini plugins means that you only have to load and run code that you absolutely want. With a single plugin, there may be several parts of the plugin that you don’t want to use.
There’s generally fewer bugs. Less code in a plugin means there’s less chance of bugs arising. It also makes it easier to find and fix bugs more quickly. Thus, allowing plugin developers to quickly get out new releases when they’re needed.
Fewer database options. With multiple plugins, sometimes you don’t need an option at all. The plugin simply works. With a single, large plugin, each setting might need to be enabled/disabled.

What are your thoughts?

Think about the example plugin I mentioned early in the post. If I allowed you to make the final decision on whether you’d like to see this developed as a single plugin or multiple plugins, which would you choose?

Now, think about the plugins you currently have installed on your site. Are there some that you’d like to see broken down into smaller plugins that only handled specific tasks?

Are there any other advantages or disadvantages you’d like to share?

Prevent Password Reset WordPress Plugin

Justin Tadlock — Thu, 19 Jan 2012 19:36:15 +0000

Recently, I needed to build some functionality into a site that disabled the ability to reset the passwords of certain site administrators via the “lost password” form. However, I wanted to leave this option open for other users in case they needed to reset their password after forgetting it.

Thus, the Prevent Password Reset plugin was born.

How the plugin works

Prevent Password Reset is an extremely simple plugin. It adds a checkbox to the “Personal Options” section of each user’s profile page in the WordPress admin as shown in the following screenshot. Anyone who can edit the user’s profile can select this option for the user.

Once this option is selected for a user, their password cannot be reset via the “lost password” form. The following screenshot shows what happens when someone attempts to reset the password for a user with password preventing enabled.

Download the plugin

You can download the latest version from the WordPress plugin repository: Prevent Password Reset Plugin. I hope you enjoy it and can get some type of use out of it.

WordCamp Birmingham 2012

Justin Tadlock — Wed, 11 Jan 2012 02:47:12 +0000

I’ll be attending WordCamp Birmingham this upcoming weekend (Jan. 14–15, 2012). I’d love to meet some of you fine folks from the WordPress community, so I hope y’all are coming! So, if you want to get together for a beer or something let me know.

Pre-order WPCandy Quarterly #1

Justin Tadlock — Fri, 16 Dec 2011 21:21:08 +0000

If you’re a WordPress enthusiast, I highly recommend pre-ordering issue #1 of the WPCandy Quarterly, a print magazine for us WordPress folks. There will be quite a few interesting articles. Plus, I’m one of the authors in the first issue.

What’s going on with DevPress?

Justin Tadlock — Wed, 14 Dec 2011 00:31:08 +0000

For those of you who don’t know about DevPress, have you been living under a rock? Seriously, it is a WordPress business I began with Tung Do, Patrick Daly, and Ptah Dunbar. All of these guys are awesome at what they do and are great folks to work with.

The main goal of DevPress was to build an awesome WordPress plugin and theme community where everyone was welcome (and a lot more!). Unfortunately, things didn’t go as planned in these past six months or so. Therefore, we had to make some tough decisions. In the end, Tung became the sole owner of DevPress.

Tung described our problem best in his official update on the DevPress blog:

DevPress managed to release high quality products and tease the community of buzz-worthy ideas, but what we needed most was consistency. If success is 80% just simply showing up well then we failed.

DevPress team members were all over the place. We never had everyone on the same page at the same time. We had too many ideas and projects that started but never got finished. This is a problem when you’re trying to kick-start a business venture.

The other issue that we ran into is the too-many-chiefs-not-enough-Indians scenario. Since we were all four the owners of the site (equal ownership), each decision had to be agreed upon. For those of you starting up your own business, take my advice: Elect a single shot-caller, one person to make most of the decisions and manage day-to-day operations. Bigger decisions can be made as a team, but smaller things need to be decided upon in a timely fashion so you can move on to the next thing you need to work on.

Tung will be moving forward with some great ideas he’s had for a long time. I’m happy he’s getting a chance to see them through.

Just so you don’t get any tabloid-like ideas about “what really happened,” just know that we’re all parting as friends. DevPress is changing directions because it was the best move for the business and the WordPress community.

I don’t feel like I’ve lost anything. I feel like I’ve made three great friends who I can rely on. Don’t be surprised if you find two or more of us working together in the future.

What does this mean for me?

For starters, JustinTadlock.com is once again the home of my WordPress tutorials. You can now find all of the tutorials I wrote for DevPress in the WordPress section of this blog.

Theme Hybrid members are getting a few plugins (DevPress plugins and unreleased plugins) as well as the News theme. I’ll be keeping members updated as I continue moving stuff over to the site.

Outside of that, it’ll be the same ol’, same ol’. I’ll just continue breaking WordPress while trying to do cool things with it.

WordPress 3.3: Sonny

Justin Tadlock — Tue, 13 Dec 2011 00:02:08 +0000

All the awesomeness that is WordPress 3.3 is finally here. Go ahead a grab a copy of the new version and have fun! I’m just thankful that we’ve got plenty of time to play around with it before Christmas.

My Life theme testing

Justin Tadlock — Thu, 24 Nov 2011 13:23:29 +0000

I’m currently testing out the My Life theme here on my blog. If you’re a member of Theme Hybrid, you can grab a beta copy of it from the Theme Hybrid forums to play around with it before release.

Custom user taxonomies in WordPress

Justin Tadlock — Thu, 20 Oct 2011 18:45:31 +0000

If you’re at all familiar with taxonomies in WordPress, you already know how awesome it is to add custom taxonomies to your posts or custom post types. WordPress developers have known this for a while.

What many people don’t know is that the current taxonomy schema was added way back in WordPress 2.3. Yes, that means the ability to create and use custom taxonomies has been around since 2007. We didn’t get all the cool functions added until 2.8 though.

However, one thing we’ve had since 2.3 was the ability to create taxonomies for any object type, not just posts. In WordPress, there are several object types:

Posts
Users
Comments
Links

So, you can technically create a taxonomy for any object type. Most of WordPress core support is for posts, but the API is extremely well thought out and can handle the other object types with minimal code effort.

This tutorial will focus on registering and using a taxonomy on the user object type. It will not be a 100% solution for everything you can do with a custom user taxonomy. Consider this an extremely rough draft of what’s possible.

Because this is such an in-depth topic, I cannot explain every minute detail. That would make for about a 50-page tutorial. You’ll need to be familiar with a few key areas in WordPress development before proceeding: plugins, themes, users, and taxonomies.

Registering a user taxonomy

In this tutorial, you will use and register a taxonomy called “Profession.” This is just an example, so feel free to experiment and create your own taxonomies for your uses.

To register the user taxonomy, you use the register_taxonomy() function just like you would with any other taxonomy. The following code block will register the profession taxonomy and set up its arguments.

/**
 * Registers the 'profession' taxonomy for users.  This is a taxonomy for the 'user' object type rather than a
 * post being the object type.
 */
function my_register_user_taxonomy() {

	 register_taxonomy(
		'profession',
		'user',
		array(
			'public' => true,
			'labels' => array(
				'name' => __( 'Professions' ),
				'singular_name' => __( 'Profession' ),
				'menu_name' => __( 'Professions' ),
				'search_items' => __( 'Search Professions' ),
				'popular_items' => __( 'Popular Professions' ),
				'all_items' => __( 'All Professions' ),
				'edit_item' => __( 'Edit Profession' ),
				'update_item' => __( 'Update Profession' ),
				'add_new_item' => __( 'Add New Profession' ),
				'new_item_name' => __( 'New Profession Name' ),
				'separate_items_with_commas' => __( 'Separate professions with commas' ),
				'add_or_remove_items' => __( 'Add or remove professions' ),
				'choose_from_most_used' => __( 'Choose from the most popular professions' ),
			),
			'rewrite' => array(
				'with_front' => true,
				'slug' => 'author/profession' // Use 'author' (default WP user slug).
			),
			'capabilities' => array(
				'manage_terms' => 'edit_users', // Using 'edit_users' cap to keep this simple.
				'edit_terms'   => 'edit_users',
				'delete_terms' => 'edit_users',
				'assign_terms' => 'read',
			),
			'update_count_callback' => 'my_update_profession_count' // Use a custom function to update the count.
		)
	);
}

I won’t cover all the arguments used in the code above. I’ve written about those in a previous tutorial. However, there are a few arguments you should pay careful attention to:

rewrite['slug']: I used author/profession so that the slug would fall in line with the WordPress user slug, author. We’ll need a slight fix for this too, which I’ll get to later in the tutorial.
capabilities: For simplicity, I’ve set most of the capabilities to edit_users. Only administrators can manage, edit, and delete professions with this by default. The assign_terms capability is set to read so all users can edit this on their profile page. You’ll want to set up some custom capabilities or configure this to do what you want.
update_count_callback: You must use a custom function for this because WordPress expects the taxonomy to be for the post object type.

Once you’ve registered your taxonomy, WordPress really doesn’t do much for you. It won’t add any custom admin pages, meta boxes, or anything of the sort like it does for posts. That’ll be left up to you.

Custom term update count callback

Right off the bat, you’ll already need some custom code. Since WordPress will only update the term counts for taxonomies on posts, you’ll need a function to do this for users.

When you registered your taxonomy, you set the update_count_callback argument to my_update_profession_count. The following code is that callback function.

/**
 * Function for updating the 'profession' taxonomy count.  What this does is update the count of a specific term
 * by the number of users that have been given the term.  We're not doing any checks for users specifically here.
 * We're just updating the count with no specifics for simplicity.
 *
 * See the _update_post_term_count() function in WordPress for more info.
 *
 * @param array $terms List of Term taxonomy IDs
 * @param object $taxonomy Current taxonomy object of terms
 */
function my_update_profession_count( $terms, $taxonomy ) {
	global $wpdb;

	foreach ( (array) $terms as $term ) {

		$count = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM $wpdb->term_relationships WHERE term_taxonomy_id = %d", $term ) );

		do_action( 'edit_term_taxonomy', $term, $taxonomy );
		$wpdb->update( $wpdb->term_taxonomy, compact( 'count' ), array( 'term_taxonomy_id' => $term ) );
		do_action( 'edited_term_taxonomy', $term, $taxonomy );
	}
}

I just kept this extremely simple and modified the _update_post_term_count() WordPress function. Feel free to further modify it to suit your needs.

Creating the manage terms page

Since WordPress does not create an admin page for managing terms of custom user taxonomies, you’ll need to create that. For the sake of simplicity and laziness, I just used the admin page WordPress already uses for other taxonomies.

The problem with this is that WordPress doesn’t recognize that the “Professions” admin page is a sub-menu of the “Users” admin page when viewing it. The sub-menu is placed correctly, but when clicking on it, the “Posts” menu is opened in the admin. I’d really love to see some WordPress core support for this.

Update: See the comment by James below to get a fix for this.

The following code is what I used, but you can definitely create a custom admin page for managing your terms.

/* Adds the taxonomy page in the admin. */
add_action( 'admin_menu', 'my_add_profession_admin_page' );

/**
 * Creates the admin page for the 'profession' taxonomy under the 'Users' menu.  It works the same as any
 * other taxonomy page in the admin.  However, this is kind of hacky and is meant as a quick solution.  When
 * clicking on the menu item in the admin, WordPress' menu system thinks you're viewing something under 'Posts'
 * instead of 'Users'.  We really need WP core support for this.
 */
function my_add_profession_admin_page() {

	$tax = get_taxonomy( 'profession' );

	add_users_page(
		esc_attr( $tax->labels->menu_name ),
		esc_attr( $tax->labels->menu_name ),
		$tax->cap->manage_terms,
		'edit-tags.php?taxonomy=' . $tax->name
	);
}

This will at least allow you to create and manage custom terms of the profession taxonomy. If you have a better solution for this, please post it in the comments for other people to see.

Fixing the “Posts” column

After creating the admin page, you probably noticed a column on it called “Posts.” Instead, it should display a “Users” column. The following code will fix this issue and list the number of users with each term from the profession taxonomy.

/* Create custom columns for the manage profession page. */
add_filter( 'manage_edit-profession_columns', 'my_manage_profession_user_column' );

/**
 * Unsets the 'posts' column and adds a 'users' column on the manage profession admin page.
 *
 * @param array $columns An array of columns to be shown in the manage terms table.
 */
function my_manage_profession_user_column( $columns ) {

	unset( $columns['posts'] );

	$columns['users'] = __( 'Users' );

	return $columns;
}

/* Customize the output of the custom column on the manage professions page. */
add_action( 'manage_profession_custom_column', 'my_manage_profession_column', 10, 3 );

/**
 * Displays content for custom columns on the manage professions page in the admin.
 *
 * @param string $display WP just passes an empty string here.
 * @param string $column The name of the custom column.
 * @param int $term_id The ID of the term being displayed in the table.
 */
function my_manage_profession_column( $display, $column, $term_id ) {

	if ( 'users' === $column ) {
		$term = get_term( $term_id, 'profession' );
		echo $term->count;
	}
}

Assigning terms to users

Thus far, you’ve got a custom taxonomy and can add terms for it, but you need a way to assign these terms to individual users. For this example, you’ll be adding a custom section to the edit user/profile page in the admin. It will display a list of radio select boxes so the user can choose their profession.

This is just an extremely basic example. You have tons of room for customization. You can do select elements, checkboxes, a text input, or whatever best works for you.

The following PHP code will add this section to the edit user/profile page.

/* Add section to the edit user page in the admin to select profession. */
add_action( 'show_user_profile', 'my_edit_user_profession_section' );
add_action( 'edit_user_profile', 'my_edit_user_profession_section' );

/**
 * Adds an additional settings section on the edit user/profile page in the admin.  This section allows users to
 * select a profession from a checkbox of terms from the profession taxonomy.  This is just one example of
 * many ways this can be handled.
 *
 * @param object $user The user object currently being edited.
 */
function my_edit_user_profession_section( $user ) {

	$tax = get_taxonomy( 'profession' );

	/* Make sure the user can assign terms of the profession taxonomy before proceeding. */
	if ( !current_user_can( $tax->cap->assign_terms ) )
		return;

	/* Get the terms of the 'profession' taxonomy. */
	$terms = get_terms( 'profession', array( 'hide_empty' => false ) ); ?>

	

	

		
			

			
					ID, 'profession', $term ) ); ?> /> name; ?>

	ID, 'profession', $term ) ); ?> /> name; ?>


After adding the preceding code, you’ll get a new section near the bottom of your edit user/profile page that looks like the following screenshot.

You’ll need a way to save the selected term (profession) for the user.  The next code block will handle that.
/* Update the profession terms when the edit user page is updated. */
add_action( 'personal_options_update', 'my_save_user_profession_terms' );
add_action( 'edit_user_profile_update', 'my_save_user_profession_terms' );

/**
 * Saves the term selected on the edit user/profile page in the admin. This function is triggered when the page
 * is updated.  We just grab the posted data and use wp_set_object_terms() to save it.
 *
 * @param int $user_id The ID of the user to save the terms for.
 */
function my_save_user_profession_terms( $user_id ) {

	$tax = get_taxonomy( 'profession' );

	/* Make sure the current user can edit the user and assign terms before proceeding. */
	if ( !current_user_can( 'edit_user', $user_id ) && current_user_can( $tax->cap->assign_terms ) )
		return false;

	$term = esc_attr( $_POST['profession'] );

	/* Sets the terms (we're just using a single term) for the user. */
	wp_set_object_terms( $user_id, array( $term ), 'profession', false);

	clean_object_term_cache( $user_id, 'profession' );
}
Displaying user taxonomy terms
You can use any of the standard WordPress taxonomy functions for listing out your terms.  For example, wp_list_categories() and wp_tag_cloud() will both work fine.  Each will link to the term archive page (covered in the section below).
If you wanted to show a tag cloud with all of your “professions” (profession cloud) in a theme template, your code would look something like the following.
 'profession' ) ); ?>
One thing to look out for though is that the title attribute for links in the tag cloud will read “1 topic” or “X topics.”  An easy way to change this is to write a custom callback function to modify the text.  In the following screenshot, you can see this changed from “topics” to “users”.

The following code block is a function that will handle that.
/**
 * Function for outputting the correct text in a tag cloud.  Use as the 'update_topic_count_callback' argument
 * when calling wp_tag_cloud().  Instead of 'topics' it displays 'users'.
 *
 * @param int $count The count of the objects for the term.
 */
function my_profession_count_text( $count ) {
	return sprintf( _n('%s user', '%s users', $count ), number_format_i18n( $count ) );
}
You’d use it when displaying your tag cloud like so:
 'profession',
		'topic_count_text_callback' => 'my_profession_count_text'
	)
); ?>
Templates for term archives

The template for term archives is handled the same as any other taxonomy.  So, if you wanted to create a custom template (you probably should) for your theme to display users by profession, you’ll want to create a template named taxonomy-profession.php.
I won’t cover creating theme templates here.  It’s outside the scope of this tutorial.  
The big difference between this template and a normal template is there’s no post loop.  Instead, you need to create a user loop.  The following code should replace your normal post loop in this template.
taxonomy );

if ( !empty( $users ) ) {
?>
	

		
			
			

			
				
			
		

	

The most important function used in the code above is the WordPress get_objects_in_term() function.  By putting in a term ID and taxonomy name, you can grab an array of all the object (user) IDs with that term (profession).  With the user ID, you can load any information about a user you want with any standard WordPress functions.
Of course, you’re free to customize this however you want.  The preceding code merely loops through each of the users with a specific profession.  It then displays each user’s avatar, name with a link to their posts archive, and description.
Disabling the ‘profession’ username
When you registered the profession taxonomy, you created the slug author/profession so that the profession archive pages would have a URL like yoursite.com/author/profession/designer.  The problem with this that “profession” could potentially be a username someone signs up to your site with.
The following code will make sure no one can sign up with this username:
/* Filter the 'sanitize_user' to disable username. */
add_filter( 'sanitize_user', 'my_disable_username' );

/**
 * Disables the 'profession' username when someone registers.  This is to avoid any conflicts with the custom
 * 'author/profession' slug used for the 'rewrite' argument when registering the 'profession' taxonomy.  This
 * will cause WordPress to output an error that the username is invalid if it matches 'profession'.
 *
 * @param string $username The username of the user before registration is complete.
 */
function my_disable_username( $username ) {

	if ( 'profession' === $username )
		$username = '';

	return $username;
}
Of course, if you use a different rewrite structure for your taxonomy, don’t worry about that code.
Time to create your own user taxonomies
Whoah!  That was certainly a ton of information to cover in a single tutorial.  I’m sure some of you have questions, so please ask away in the comments.
Now it’s time for you to venture out on your own and create some cool stuff.  I’d love to hear what ideas you have and see any projects that you use this code in.  I’m definitely interested in seeing some practical, real-world use cases of user taxonomies.
One final note:  The code in this tutorial is just something I played around with in about a two-hour span.  It’s still a work in progress.  Honestly, it took me much longer to write this tutorial.  Therefore, I leave it up to you, dear reader, to improve upon the code.



How to create custom post meta boxes
Justin Tadlock — Thu, 06 Oct 2011 20:40:05 +0000
My first post on Smashing WordPress is up: How to create custom post meta boxes.