In this tutorial, you’ll learn how to utilize the add_meta_box() functionality to add two things to your pages:

1. Excerpt box.
2. Custom taxonomies boxes.

Being able to add these meta boxes to pages isn’t the limit. This tutorial should serve as a starting point. You could do the same for custom post types, links, or anything that fires the do_meta_boxes action hook.

Adding an excerpt box to your page editor

The first thing you should do is open your theme’s functions.php file in your favorite text editor. Paste the following PHP code into it:

add_action( 'admin_menu', 'my_page_excerpt_meta_box' );

function my_page_excerpt_meta_box() {
	add_meta_box( 'postexcerpt', __('Excerpt'), 'post_excerpt_meta_box', 'page', 'normal', 'core' );
}

Now, you’ll be able to add excerpts to your pages, just like posts. This can come in handy with themes that display search results in excerpt form.

Adding custom taxonomies to your page editor

This one will be a bit trickier. I’ll have to assume you’ve created a custom taxonomy specifically for pages. If you’re unfamiliar with this process, you need to familiarize yourself with creating custom taxonomies.

Let’s assume you’ve created a “People” taxonomy for pages. Your custom taxonomy code should look a little like this.

register_taxonomy( 'people', 'page', array( 'hierarchical' => false, 'label' => 'People', 'query_var' => true, 'rewrite' => true ) );

The important thing in that line is page. We’ll be adding meta boxes for all taxonomies that have been registered for pages.

Again, we’ll go to our theme’s functions.php file. Paste this PHP code in:

add_action( 'admin_menu', 'my_page_taxonomy_meta_boxes' );

function my_page_taxonomy_meta_boxes() {
	foreach ( get_object_taxonomies( 'page' ) as $tax_name ) {
		if ( !is_taxonomy_hierarchical( $tax_name ) ) {
			$tax = get_taxonomy( $tax_name );
			add_meta_box( "tagsdiv-{$tax_name}", $tax->label, 'post_tags_meta_box', 'page', 'side', 'core' );
		}
	}
}

Once that’s done, you’ll be able to use your page-based custom taxonomies.

Please note that hierarchical taxonomies aren’t going to be available yet. Maybe in WordPress 3.0?

A good move by WordPress

I’m glad WordPress is moving in this direction with some of its functionality. Average Joe might not realize the implications of something as simple as moving code to another file, but developers should rejoice. The reuse of code is a cornerstone of good development practice. By making things more modular, it becomes easier to create new things without rewriting a lot of code.

I’ve shown you how to do these things with pages. Just imagine being able to make these simple and quick changes for custom post types (i.e., content types), essentially having the ability to create any type of site you want with WordPress.

The problem with providing backwards compatibility is twofold:

1. Users continue using old versions of WordPress.
2. We have extra code to worry about.

Force users to upgrade

With the recent security scare that targeted older versions of WordPress, blame is being thrown around left and right, from everyone to users to the WordPress developers. While staying updated with the latest version of WordPress isn’t going to make your site 100% secure, it will make it secure from known security exploits.

By providing backwards compatibility in our plugins/themes, developers are partly responsible. We’re giving users an excuse to not upgrade. Obviously, developers are not to blame for people not upgrading their sites, but we can do our part in helping them stay secure by not supporting older versions of WordPress.

How do we not support older versions? Some things are simply going to be backwards compatible because they require no new WordPress functions, so we can’t do anything about those plugins. The best thing to do is to use new WordPress functions as they become available and are useful to your plugin or theme.

Why would you want to support older versions of WordPress? There’s no point in doing so.

Get rid of code you don’t need

Maybe you really don’t care if users’ sites are hacked from staying on an older version. That’s fine. Another valid reason for keeping with the latest WordPress trends is that you don’t have to check for functions.

How often do you use the function_exists() and/or the class_exists() functions?

If you’re checking if a WordPress function exists, you’re doing so because you’re supporting older versions. Do yourself and your users a favor and just call the function. If it breaks a user’s site, tell them they need to upgrade. Maybe even take a moment to explain the benefits of upgrading to them.

Provide the best possible themes and plugins

The WordPress developers have done about all they can do to make sure people upgrade, but we should take a bit more initiative as developers within community, the people that end users actually interact with. By forcing users to upgrade, we’re helping them stay secure.

Before writing this post, I tried to think of valid reasons to provide backwards compatibility and only thought of one, and that’s the crossover period between major version upgrades. This period should last about one month. This gives users ample time to upgrade and provides support for people with WordPress MU.

I’m certainly open to other ideas about how plugin and theme developers can get more involved in the security of their users’ sites. Feel free to leave your thoughts on how they can.

One of the features I feel that’s lacking in most plugins and themes is the ability to define custom capabilities to access certain content. This is one of the reasons I’ve developed this plugin.

If you’re a plugin or theme developer and add admin menus, this tutorial should be helpful. What I’ll be showing you is a way to give users of your plugin smarter control over its settings.

Adding an admin menu page the normal way

There are several functions for adding admin menus, which all work basically the same way. I’ll use add_submenu_page() as an example since it’s fairly common.

When adding a page, you’ll use the function like this:

add_submenu_page( $parent_page, $page_title, $menu_title, $capability, $file, $function );

What we’ll be focusing on here is the $capability variable. Typically, this is hardcoded, but we need to be able to change this. So, when writing that code, you should replace $capability with a filter hook:

add_submenu_page( $parent_page, $page_title, $menu_title, apply_filters( 'plugin_name_capability', $capability ), $file, $function );

plugin_name_capability should be something unique to your plugin. Just leave $capability as whatever capability you would normally use. It can now be changed.

Making this change does two important things:

1. Allows users to change the capability if they want to with a filter.
2. Allows you to integrate your plugin with the Members plugin.

You can stop reading here and will have done your part in making your plugin more flexible. However, you can offer integration with my Members plugin, which will make it even easier for users to use.

Integrating your plugin/theme with the Members plugin

Here’s where the real neat stuff comes into play. You can run a check to see if the Members plugin is installed. If the plugin is indeed installed, you can create a custom capability just for your plugin’s settings page.

Let’s assume that filter hook was something like this:

apply_filters( 'plugin_name_capability', 'manage_options' );

People without the Members plugin would need the manage_options capability to change the settings for your plugin. To me, that doesn’t sound like a great solution, and it definitely doesn’t offer the site owner much flexibility.

If the Members plugin is installed, we’ll change that capability to something like edit_my_plugin_settings (change to something unique):

if ( function_exists( 'members_plugin_init' ) )
	add_filter( 'plugin_name_capability', 'plugin_name_unique_capability' );

function plugin_name_unique_capability( $cap ) {
	return 'edit_my_plugin_settings';
}

Now, only users of a role with the edit_my_plugin_settings capability will be able to access that plugin’s page.

Adding the capability to the role edit page

You can offer even more integration with the Members plugin if you like. You can add a checkbox to the Edit Role page that allows users to easily select this capability rather than typing it in.

if ( function_exists( 'members_get_capabilities' ) )
	add_filter( 'members_get_capabilities', 'plugin_name_extra_caps' );

function plugin_name_extra_caps( $caps ) {
	$caps[] = 'edit_my_plugin_settings';
	return $caps;
}

Why is all this important?

Imagine running a site with 20 different writers, publishers, administrators, and so on. Some people of that site need specific access to certain things but no access to other things.

For example, a friend and I are both running this site with all these people. The friend doesn’t need access to the WordPress options, but he does need access to your plugin’s options. Those should be controlled by two separate capabilities rather than one.

I created Members to allow site owners to have as much flexibility as possible. But, the plugin itself can only do so much on its own. As developers in the WordPress community, we can make WordPress infinitely flexible by working together, and I’m definitely trying to make it as easy as possible to integrate other plugins with my own.

I created this plugin because I wasn’t satisfied with the current user, role, and permissions plugins available. Yes, some of them are good, but nothing fit what I had in mind perfectly. Some offered few features. Some worked completely outside of the WordPress role and capability system. Others lacked an appropriate license.

This plugin is still a long way away from my goals, but it’ll get there eventually.

What does the plugin do?

Members has what I call “components.” Instead of normal plugin settings, you get a components-selection page that allows you to choose only the features that you want to use.

The current components are (more will come in future versions):

• Edit Roles: Edit your user roles and their capabilities.
• New Roles: Create new roles for use on your site.
• Content Permissions: Adds a meta box on your write post/page editor that allows you to restrict content to specific roles.
• Widgets: Adds a login form widget and user-listing widget that you can use in any widget area on your site.
• Shortcodes: Creates shortcodes that you can use to restrict or allow access to certain parts of your posts and pages (or any other shortcode-capable area).
• Template Tags: New functions for use within your WordPress theme for various things.
• Private Blog: Allows you to create a private blog that can only be accessed by users that are logged in (redirects them to the login page).

Screenshots of the plugin

I’ve uploaded a few screenshots so you can see what part of the plugin looks like:

• Select Components Screen
• Edit Roles Component
• New Roles Component
• Content Permissions Component

Ideas for future versions

Version 0.1 has been all about role and capability management, but that’s just the beginning. Version 0.2 will be about user management.

But, it’s not all about my ideas. I’ll be working through many of the ideas presented in my original post on this plugin. I’m also open to any new ideas you might have.

Download the plugin

Before using this plugin, please read the readme.html file included in the plugin download. It will guide you through everything you need to know about using it.

• Version: 0.1
• Requires: WordPress 2.8+
• Support: Support forums
• Download (from WP.org)

Please don’t use my contact page or the comments section below to ask support questions. Use my support forums at Theme Hybrid, which is where I handle all support questions for my WordPress projects.

Management of these fields will be coming in a later version of my user management plugin, but some of you may want to do this now.

In this tutorial, I’ll show you how to add an input box for a Twitter username and how to display it on your site, which will look a little something like this:

My profile and Twitter link

If you want to see a live example, check out one of my latests posts on Pop Critics.

Adding custom user fields

Open your theme’s functions.php file and drop this PHP code in:

add_action( 'show_user_profile', 'my_show_extra_profile_fields' );
add_action( 'edit_user_profile', 'my_show_extra_profile_fields' );

function my_show_extra_profile_fields( $user ) { ?>

	<h3>Extra profile information</h3>

	<table class="form-table">

		<tr>
			<th><label for="twitter">Twitter</label></th>

			<td>
				<input type="text" name="twitter" id="twitter" value="<?php echo esc_attr( get_the_author_meta( 'twitter', $user->ID ) ); ?>" class="regular-text" /><br />
				<span class="description">Please enter your Twitter username.</span>
			</td>
		</tr>

	</table>
<?php }

This will create a new area in the user edit screen that looks like this:

Additional profile fields

The custom part of the code is this bit:

<tr>
	<th><label for="twitter">Twitter</label></th>

	<td>
		<input type="text" name="twitter" id="twitter" value="<?php echo esc_attr( get_the_author_meta( 'twitter', $user->ID ) ); ?>" class="regular-text" /><br />
		<span class="description">Please enter your Twitter username.</span>
	</td>
</tr>

Note that if you want to add more fields, copy that and change twitter to something unique for each additional field. Just make sure you change each instance of twitter.

Saving the custom user fields

Just because we’re displaying these extra fields, doesn’t mean they’ll be saved when the user profile is updated. So, we need one more function to handle this. Drop this PHP code in your theme’s functions.php file.

add_action( 'personal_options_update', 'my_save_extra_profile_fields' );
add_action( 'edit_user_profile_update', 'my_save_extra_profile_fields' );

function my_save_extra_profile_fields( $user_id ) {

	if ( !current_user_can( 'edit_user', $user_id ) )
		return false;

	/* Copy and paste this line for additional fields. Make sure to change 'twitter' to the field ID. */
	update_usermeta( $user_id, 'twitter', $_POST['twitter'] );
}

Now, your information will be saved.

Displaying custom user fields on the site

For getting these additional fields, WordPress has two nifty functions: the_author_meta() and get_the_author_meta(). The former displays the meta information, and the latter returns it for use in PHP. Each takes in two parameters:

the_author_meta( $meta_key, $user_id );

You can use this to grab the information from any of the fields you’ve created. For example, the $meta_key for our Twitter field is twitter. We just need to call it up somewhere in our theme.

So, what we’re going to do is build an author box to add to the end of our single posts. Once again, we visit our theme’s functions.php file and drop some PHP code in:

function my_author_box() { ?>
	<div class="author-profile vcard">
		<?php echo get_avatar( get_the_author_meta( 'user_email' ), '96' ); ?>

		<h4 class="author-name fn n">Article written by <?php the_author_posts_link(); ?></h4>

		<p class="author-description author-bio">
			<?php the_author_meta( 'description' ); ?>
		</p>

		<?php if ( get_the_author_meta( 'twitter' ) ) { ?>
			<p class="twitter clear">
				<a href="http://twitter.com/<?php the_author_meta( 'twitter' ); ?>" title="Follow <?php the_author_meta( 'display_name' ); ?> on Twitter">Follow <?php the_author_meta( 'display_name' ); ?> on Twitter</a>
			</p>
		<?php } // End check for twitter ?>
	</div><?php
}

Now, all you need to do call the function in your theme’s single.php file somewhere after the post has been displayed:

<?php my_author_box(); ?>

If you’re using a child theme, your theme author can probably tell you a more appropriate action hook to add this function to so you don’t mess up your theme’s template files.

What other custom user field uses can you think of?

This is just another one of those powerful features of WordPress that I don’t see used much. I have several things in mind that I could use this technique for, but I’d like to hear what you’d do with it.

Surely we can do some cooler stuff than just displaying a link to Twitter?

I had no idea how popular the idea would be, even warranting itself a blog post, a forum topic, and loads of emails and replies on Twitter. So, I thought it’d be best to get the feel of the community and see what everyone’s thoughts were.

Many were in the same boat as me — not quite satisfied.

I don’t mean to build my plugin up too much though. There’s an extremely long road ahead if I’m going to implement as many features as we all want. The first release is about building a solid foundation for future development. I want to get the essentials down first. Then, I can start building new things in.

What does this plugin do?

First and foremost, it’s a role management plugin. This is the foundation of everything. It will allow you to control each of your site’s roles and their accompanying capabilities.

But, it’s not only a role management plugin. It has a components-based system that allows you to only use the components you wish to use. The current components are:

• Edit Roles: Edit your user roles and their capabilities.
• New Roles: Create new roles for use on your site.
• Content Permissions: Adds a meta box on your write post/page editor that allows you to restrict content to specific roles.
• Widgets: Adds a login form widget and user-listing widget that you can use in any widget area on your site.
• Shortcodes: Creates shortcodes that you can use to restrict or allow access to certain parts of your posts and pages (or any other shortcode-capable area).
• Template Tags: New functions for use within your WordPress theme for various things.
• Private Blog: Allows you to create a private blog that can only be accessed by users that are logged in (redirects them to the login page).

This is just the beginning though. You’ve given me loads of ideas in my original post on this, and I plan on implementing as much as possible in later versions.

What I need from you all

Testing. Testing. Testing. And, feedback, of course.

This is one of the larger projects I’ve worked on, so a lot of the stuff is new terrain, even for me. With enough feedback and testing, this can be a great project for the WordPress community.

I know many of you will have ideas about new things to be added, but let’s try to hold those ideas until later. What you see here will be in version 0.1 of the plugin, but new things will come in later versions. Right now, I want to focus on making sure the current components work.

Some specific things I’m looking for:

• Is anything too hard to understand?
• Does something not work the way you expect it to?
• Do you recieve any error messages?
• Each component and each component’s options need to be tested.
• Testing on various browsers definitely needs to be done.
• Needs to be tested on the WordPress 2.8 branch and the current trunk.

Some questions:

• How should restricted pages (Content Permissions component) be handled? Remove from page lists if user isn’t allowed to view them?
• Will someone check to make sure content isn’t showing in feeds (Content Permissions component) unless it’s supposed to?
• Is there anything else you’d like to see done with the current widgets (Widgets component)?

I’m hoping to officially launch this plugin in another week or two (depending on what bugs are found).

How to use the plugin

I’ve written a fairly comprehensive guide, which is included within the plugin download. It is the readme.html file.

If you have questions about usage, please refer to that guide first. Also, I encourage you to read my guide on users, roles, and capabilities in Wordpress. It’ll give you a better understanding of how things work.

Beta test the plugin

Please do not use this plugin on a live site. It is for test environments only. If you use it on a live site and it breaks that site, you are responsible for fixing it.

Sorry for such a stern warning, but I’ve locked myself out of my test install on more than one occasion while developing this plugin. Let’s make sure it works before using it on live sites, okay?

• Download Version 0.1 Beta 1

Help me name the plugin

I’m currently calling it the Members plugin because I haven’t given a name to it yet. If you have ideas about what to call it, feel free to let me know.

The plugin is supposed to be a complete user, role, and content management plugin. While it’s not quite there yet, I hope that it’ll become the “must-install” plugin for all multi-user WordPress sites in the future.

What I’m proposing in this post is not something new to the WordPress world. I’m not creating new ideas with my upcoming plugin. This is how it works in WordPress. The plugin will just put a face to these ideas.

If you do not grasp this concept, you won’t understand the inherent limitations of the plugin nor the features of it.

What are users?

For the sake of thoroughness (even though you probably understand this), users are people that have registered on your site. They have a user account. Users, in this context, are not people who have visited your site or someone that leaves a comment.

Being a registered user doesn’t mean anything though. Users are given context through a role. Roles define each user’s place on the site.

What are roles?

Roles are a way of grouping users. By default, WordPress gives you several roles to work with:

• Administrator
• Editor
• Author
• Contributor
• Subscriber

These are all pretty straightforward. Average Joe shouldn’t have much trouble figuring out what roles can do certain things. But, let me present what’s really going on here.

There are two important things you need to understand about roles in WordPress before moving forward:

1. Roles are not hierarchical.
2. Roles have no meaning without capabilities.

Many of you might want to argue with that first point. You might want to say that “administrator” is a higher level than “subscriber.” But, that’s not entirely true. It’s the wrong way to look at how roles work. The default administrator role simply has more capabilities. You could give the default subscriber role more capabilities than the administrator (if you wanted to).

If you learn nothing else from this post, remember this — roles are defined by what capabilities they are granted. There is no hierarchy.

What are capabilities?

This is the real beauty of how the system works. Capabilities are permissions. They’re a way of saying a role can or can’t do something.

Capabilities are given to roles. So, users of a certain role are limited by that role’s capabilities.

For example, the administrator role (by default) is granted the capability of edit_themes. You don’t get to edit your theme because you’re an administrator. You are allowed to edit your theme because your role (administrator) has the capability of edit_themes. If you took away that capability, you would no longer be able to edit your theme in the WordPress admin, no matter how important you think your role is.

Putting it all together

Here’s the short and simple version of this concept:

• Users are people that have registered on your site.
• Each user is given a role on your site.
• Each role is given a set of capabilities (i.e., permissions) that grant/restrict their access.

Why is all this important?

It’s important to understand how the platform you’re using works. I was amazed at the number of comments I recieved that focused on a hierarchical role system, which is not how WordPress works.

That’s the thing that troubles me the most. If people are going to be using a plugin that extends the current role and capability system, they must understand how things work.

A sneak-peek at the plugin

Since many of you have been patiently awaiting news on this plugin and have read through this post, it’s only fair that I offer you a little teaser. This preview is of the Edit Roles component, which is one of several components I’m building into the plugin:

• Screenshot of the Edit Roles component

For those of you interested in beta testing the plugin, look for a blog post later this week. The plugin is coming along quite nicely.

It’s one thing to try and convince your family that you’re doing the right thing. It’s an entirely different beast trying to get other people to take the plunge with you.

Over the summer, I’ve been talking to a few folks about expanding my projects online. Sure, many people are interested in the idea. But, when you tell them that you have no financial backing for certain projects and that the projects can fail at any time, they lose interest fast.

Motivation is key

If you’re not entirely convinced you can be successful, you won’t be.

Even if I convince people that things will work out financially in the long run, it’s tough instilling self-confidence and motivation into everyone. The thing people most often tell me is, “I don’t really have the time.” They want success, but they don’t have time for it. Or, they want someone to hand it to them.

If you don’t think you have enough time, let me introduce you to a few people I know. How about a single mother with two kids, two jobs, and college classes to attend? I know few people with busier schedules than her.

Not having time means you don’t have motivation.

I can’t even begin to tell you how many people I’ve referred to Ian Stewart’s website There Really Is No Secret. If you haven’t checked out that site, it’ll tell you all you need to know to be successful in all things.

Finding the right people

My journey to find the right kind of people for my team has been tough. I have a handful of people that are on board right now for some upcoming projects.

I know plenty of folks online that have the right amount of determination, but right now, I want people that are close to home. I like being able to meet people face to face and having the ability to have weekly meetings where we can all get together and run over ideas.

To find the right kind of people, you have to put yourself out there. Get out there and make things happen. Be open and honest.

My selling point is: If you’re not willing to put your heart and soul behind a project, we’re not going to be a good fit. That’s what it all comes down to for me. I don’t care if you’re a genius or have never even touched a computer. You need to be willing to work hard and see it through.

What the heck am I talking about?

These are just a few thoughts I’ve been playing through my head lately.

I’ve been building a team of people that are willing to work hard and have fun on some online projects. I’ll keep everyone updated on the status of these projects (and what they are) as they near their launch.

In the meantime, if you live or know someone that lives around Montgomery, Alabama, that might be interested in working on the Web, shoot me a message through my contact form.

The good news is that WordPress has a built-in system that allows us to deregister these scripts and styles.

Wait, don’t the plugins require this code? Probably. But, we want to take control of these files and make our sites run faster. Disabling these scripts and styles will allow us to do a few things:

1. Combine multiple files into single files (mileage may vary with JavaScript here).
2. Load the files only on the pages we’re using the script or style.
3. Stop having to use !important in our style.css file to make simple CSS adjustments.

For this exercise, I’ve chosen two popular plugins from the plugin repository: Contact Form 7 and WP-PageNavi.

The dirty truth

Not all plugins use the appropriate methods for loading scripts and styles. Some developers just drop stuff right in the header. This is usually because they’re not familar with two important WordPress functions: wp_enqueue_script() and wp_enqueue_style(). If your plugin/theme author isn’t using these functions, please encourage them to do so. It allows the rest of us to work with their code using the methods WordPress provides.

While figuring out what scripts or styles you want to disable, you might have to get your hands dirty. This means looking in code. Unless your plugin author has documented the script or style handle, you’ll need to find it.

Disabling JavaScript

For this example, we’ll be disabling the Contact Form 7 plugin’s JavaScript. The first thing you need to do is find the handle for the script. Open the wp-contact-form-7.php file in your favorite text editor and do a search for wp_enqueue_script. Doing so will turn up this bit of code:

wp_enqueue_script( 'contact-form-7', wpcf7_plugin_url( 'contact-form-7.js' ), array('jquery', 'jquery-form'), WPCF7_VERSION, $in_footer );

The handle for this plugin’s JavaScript is contact-form-7. Now, you can close this file and move on.

Open your theme’s functions.php file and add this PHP in:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );

function my_deregister_javascript() {
	wp_deregister_script( 'contact-form-7' );
}

Once saved, the script will no longer load. You can deregister as many scripts as you want within this function.

Disabling styles

In this example, we’ll be disabling WP-PageNavi’s stylesheet. This is something I almost always do because I add the style rules to my theme’s style.css file.

The first thing you should do is open wp-pagenavi.php in a text editor and search for wp_enqueue_style. This will turn up this code:

wp_enqueue_style('wp-pagenavi', get_stylesheet_directory_uri().'/pagenavi-css.css', false, '2.50', 'all');

And this:

wp_enqueue_style('wp-pagenavi', plugins_url('wp-pagenavi/pagenavi-css.css'), false, '2.50', 'all');

What we’re looking for is wp-pagenavi, which is the handle for the style. Once you’ve found that, close the file and add this to your theme’s functions.php file.

add_action( 'wp_print_styles', 'my_deregister_styles', 100 );

function my_deregister_styles() {
	wp_deregister_style( 'wp-pagenavi' );
}

That’ll disable the stylesheet for this plugin. Feel free to deregister as many styles as you want within this function.

Tips on making this work better

You’ve disabled several scripts and styles, but you need to do something with them. Here’s a list of tips on how to make use of the methods described in this tutorial:

• Append styles that you’ve disabled to the end of your theme’s style.css file and edit them from there to get the look you want.
• Combine several scripts into a single file and load it yourself. I would only do this for things that use the same JavaScript library. For example, I often combine scripts that are built on jQuery.
• Use conditional tags for fine-grained control over when a script or style is loaded.

If you disable something, it may cause the plugin/theme not to work correctly. Most styles can easily be added to your theme’s stylesheet so that you’re not loading a ton of stylesheets on your site. JavaScript is a different beast altogether, and I only recommend combining multiple files into one if you know what you’re doing.

Have fun with this. Experiment. Share your experience with others in the comments.

While it’s cool to be able to style a particular post or page (or tons of other things) with a simple CSS selector in a single stylesheet, it’s not always enough. Sometimes, you may need to drastically change the appearance of a page. To do this, you’d need to load a different stylesheet.

Many tutorials will tell you to dive directly into your theme’s header.php file. Of course, you know I’m more interested in doing things the smart way by taking advantage of a theme’s functions.php file. This technique will allow you to easily transfer your custom code from theme to theme, use within a plugin, and it’s the best method when working from a child theme.

Dynamically changing your theme’s stylesheet

For this example, we have two pages we want use separate stylesheets on: About and Portfolio. The first thing you should do is create your stylesheets. Drop them into your theme (or child theme) folder and name them style-about.css and style-portfolio.css.

Once that’s done, add this code to your functions.php file:

<?php

add_filter( 'stylesheet_uri', 'my_stylesheet', 10, 2 );

function my_stylesheet( $stylesheet_uri, $stylesheet_dir_uri ) {

	if ( is_page( 'about' ) )
		$stylesheet_uri = $stylesheet_dir_uri . '/style-about.css';
	elseif ( is_page( 'portfolio' ) )
		$stylesheet_uri = $stylesheet_dir_uri . '/style-portfolio.css';

	return $stylesheet_uri;
}

?>

Just save and check out your new styles.

The code explained

What we’ve done with the few lines of code above is filter stylesheet_uri, which is a hook that returns your currently active theme’s stylesheet. This hook gives us two parameters we can use:

• $stylesheet_uri
  The URI to the current theme’s stylesheet, which needs to be returned.
• $stylesheet_dir_uri
  The URI of the current theme’s directory, which we can use in our own function and not have to figure out where our styleheets are.

The is_page() function is one of many conditional tags at your disposal for determining what page a visitor is currently viewing.