This is one of the topics I like to talk about. I’ve not only written about it once, but I followed that up about a year later. But, here I am again, with new thoughts on things, and a different perspective.

The Old Way

The first time I wrote about the panels, I suggested setting up an array of information, that would be used to create the actual box. Then each piece of information would be saved into the database. That was a pretty good solution. Then, the second time, I thought “Hey, why not just store everything one big serialized array” That would stop me from having to define each variable before I could use the meta box information. Well, that worked out for a while, but then I started seeing some faults. When you imported a WordPress database, all of your custom field information would be totally borked. I’m sure there was a way to properly re-import the arrays, but not with my current setup (I think…). So there was the fault in storing the information in an array in the database. There was also a fault in storing the fields in a huge array. It was bulky, limited, and didn’t allow for very expansive boxes.

A Semi-Fix for using an Array

To try and fix the limitations of creating the meta boxes via a huge array, I created a switch loop that would loop through and check for different types. I had a few generic ones like text, textarea, select, etc (the ones you see in most places). But then I also added a case for something called “custom.”

<?php
	break;
	case 'custom' :

		include_once( TEMPLATEPATH . $callback );
?>

So what that allowed me to do was define the metabox as being “custom”, and then I could create any custom fields, group of fields, in the $callback file I defined. Okay… that kind of fixes it. But then I realized, why not just do everything like that? Why limit the other options as well.

The New Way

My new way ditches the array of boxes entirely, and saves each piece of information in a separate field (which is still easily accessible (more on that later)), and allows for completely custom meta boxes.

All of the code posted below will go in functions.php in your theme. Also, I’m not going to explain each section line by line. Most of the code is re-used from the previous tutorials, so go check those out if you are confused.

Defining the meta box

Let’s create a function where we can initiate and add our meta boxes. We are using add_meta_box. I won’t go over what each parameter means, because I went over it in the other tutorials, and the codex are very helpful.

/**
 * Create custom meta boxes.
 *
 * @since 1.0.0
 */
function sf_create_meta_box()
{
	add_meta_box(
		'sf-meta-box-subtitle',
		__( 'Subtitle', 'sf' ),
		'sf_meta_box_subtitle',
		'post',
		'normal',
		'high'
	);
}

So that function will add a meta box that I’m going to use for a subtitle. Now we need to define the callback function that will be called (sf_meta_box_subtitle). Unlike the old way, we now are building the HTML structure by hand. It may seem like more work, but really it’s just a few lines.

function sf_meta_box_subtitle()
{
	global $meta; sf_post_meta( $post->ID );
?>

	<input type="text" name="sf_meta[subtitle]" value="<?php echo $meta[ 'subtitle' ]; ?>" style="width:99%;" /><br />
	<p><?php _e( 'Use this to add a subtitle to the post.', 'sf' ); ?></p>

<?php
}

You’ll see a function in there, sf_post_meta that we haven’t gone over yet. That will be used to get the the meta information on the front-end, as well as the back-end. More on that later.

We need to now call the original function in the admin panel, so it knows to load in the meta boxes. A simple one-liner will do that:

add_action( 'admin_menu', 'sf_create_meta_box' );

Saving the Data

Now we need to save the data. First we do a few checks to see if we need to save the information. We don’t want to do anything if no data has been submitted, if a revision is being saved, or the current user can’t edit posts (someone being sneaky).

Next I added an action so if you ever need to do anything right before the meta information is saved (maybe add something more to the array), you can easily do that.

Because we have created an array of fields by using sf_meta[input_name], we can loop through those fields specifically. Then we just go through a few checks to see if we need to add, update, or delete the post meta.

And one final do_action so we can do anything extra if we need to afterwords.

/**
 * Verify and save meta. Don't save if there is no specific meta, it is a revision,
 * or the current user can't edit posts.
 */
function sf_save_meta_box( $post_id, $post )
{
	global $post, $type;

	$post = get_post( $post_id );

	if( !isset( $_POST[ "sf_meta" ] ) )
		return;

	if( $post->post_type == 'revision' )
		return;

	if( !current_user_can( 'edit_post', $post_id ))
		return; 

	$meta = apply_filters( 'sf_post_meta', $_POST[ "sf_meta" ] );

	foreach( $meta as $key => $meta_box )
	{
		$key = 'meta_' . $key;
		$curdata = $meta_box;
		$olddata = get_post_meta( $post_id, $key, true );

		if( $olddata == "" && $curdata != "" )
			add_post_meta( $post_id, $key, $curdata );
		elseif( $curdata != $olddata )
			update_post_meta( $post_id, $key, $curdata, $olddata );
		elseif( $curdata == "" )
			delete_post_meta( $post_id, $key );
	}

	do_action( 'sf_saved_meta', $post );
}

add_action( 'save_post', 'sf_save_meta_box', 1, 2 );

Using the Data

I said before that it was a pain defining a variable for each field of meta information you wanted to use. Well it is. However, this time around I have a solution. The following function will do a few things: Define a post ID if one doesn’t exist (tries to get one from the loop), and gets a list of meta keys associated with that post.

Then here is where it gets cool: WordPress adds an underscore to all of their internal information. So we know we don’t need to grab any of that. So as we loop through, anything that starts with an _, we simply ignore. Otherwise, we add it to our $meta array. Then we cut out our prefixed meta_, and add just the simple part of the key to our array.

/**
 * Gathers all meta objects attached to a certain posts.
 * Excludes WordPress internal meta and creates an array of data.
 */
function sf_post_meta( $post_id = '' )
{
	global $meta, $post, $wpdb;

	if( empty( $post_id ) )
		$post_id = $post->ID;

	$meta = array();
	$custom_field_keys = get_post_custom_keys( $post_id );

	if( $custom_field_keys )
	{
		foreach( $custom_field_keys as $key => $value )
		{
			$valuet = trim( $value );

			if ( '_' == $valuet{0} )
				continue;

			$value_short = str_replace( 'meta_', "", $valuet );

			$meta[ $value_short ] = get_post_meta( $post_id, $value, true );
		}
	}

	return $meta;
}

Now in our page, we can just do this after our while loop.

<?php while( have_posts() ) : the_post(); sf_post_meta(); ?>

Notice the call of sf_post_meta? That is what’s going to call all the meta info we need. Then we can just do the following when we need to access the data.

<div class="subtitle"><?php echo $meta[ 'subtitle' ]; ?></div>

If this does not work, try adding global $meta; before the loop.

Conclusion

It’s as easy as that. Now you can create beautiful meta boxes that are integrated directly into the writing pages, without having to deal with clunky arrays, or worrying about defining a ton of variables to access your data.

WPBundle

This is the type of code that will be powering the themes on WPBundle. The code that will be behind these themes (HTML/PHP, excluding CSS), will be licensed under the GPL, which means that you will be able to freely use and access the code whether you have paid for the themes or not. (You will still need to buy the bundle to get the images, CSS, support, and PSD files.) I urge you to subscribe to WPBundle so you can stay up to date on all of the going-ons.