However, if you try just echoing $post->post_content, you’ll get completely unformatted text – which is frustrating, because WordPress uses a great visual text editor on the backend – it’s a shame to not take advantage of it.  Fortunately, WordPress provides a filter to display the text just as it would be displayed in the the_content() function inside the loop.  Here’s how it works:

To get the content formatted properly, we need to apply a filter (which is different from adding a filter – here, we’re registering it so that other filter functions can modify it before it’s displayed).

apply_filters('the_content', $post->post_content);

So, we’re just applying the the_content filter to the $post->post_content variable.  Doing so means that any plugin which adds a filter function to the_content like this:

add_filter('the_content', 'my_content_manipulator');

function my_content_manipulator($content){

//do stuff here

return $content;

}

will be applied to your variable.  Fortunately, it also means that the WordPress core functions which format the post content correctly can also work on it.

$wp_filter()

As far as I can tell, this holds every currently registered function/filter combination, and all the relevant information.  I can’t quite figure out exactly what determines which filters this grabs – I’ve tried calling it from a few places, and the results are slightly different, but I can’t seem to find a pattern. I initially assumed that you wouldnt be able to see about admin side hooks from the front end, but this isn’t the case. At any rate, you get lots of information from anywhere. Not getting the info you want? Call it from somewhere else! This is a great debugging tool if you’re having trouble with plugin incompatibility – it gives you a list of the filters and actions being called,the matching functions that are working on them, the priority specified for each hook call, the accepted args, and even the order in which same-priority-level hooks are called.  An example:

    [the_title] => Array
        (
            [10] => Array
                (
                    [wptexturize] => Array
                        (
                            [function] => wptexturize
                            [accepted_args] => 1
                        )

                    [convert_chars] => Array
                        (
                            [function] => convert_chars
                            [accepted_args] => 1
                        )

                    [trim] => Array
                        (
                            [function] => trim
                            [accepted_args] => 1
                        )

                )

        )

This is a small snippet I pulled after displaying the contents of this variable in the footer of a theme.  As you can see, the referenced hook is a filter, specifically “the_title”.  It has 3 functions attached to it: wptexturize, convert_chars, and trim.  Each one is at priority level 10 (which is the default), but they are called in the order listed.   Each accepts 1 argument.

Try it Out

If you want to have a look yourself, display the contents of wp_filter with this code snippet:

<?php
global $wp_filter;
print_r($wp_filter);
?>

This is going to dump the contents right to the screen, so you don’t want to do it on a live blog. As with any use of the print_r() function, the results will be formatted nicely in the source code – but not in the rendered html.

Roundup:
Top wordpress plugins
wordpress magazine theme

Sometimes, however, they can be a little much for a non-tech savvy client or user to handle – they’ve got to choose the right custom field from the dropdown, or type it in properly, or it won’t work – and what if you’ve got a few specific option values you’d like them to choose from for the custom field?  Sometimes it’s just too risky to expect the user to be able to handle it.

With this in mind, I started looking into how to modify the Add Post and Edit Post pages (ok, they’re really the same page).  As it turns out, its not too terribly difficult to add in a few options of your own on the post page, giving the user attractive, easy to use access to more advanced features of your theme or plugin.  A few examples:

Allowing the user to choose his own sidebars

This one was a fun project for me – I had a client who wanted to  have a different sidebar on his “testimonials” page (he was a consultant).  Now, I started to just set up a new post template for him, but I realized that he really wasnt going to want to call me every time he wanted to add a new testimonial – that would be ridiculous.  I had really helped sell him on the idea of using wordpress so he wouldn’t need to call me a few times a month to make small changes to his website – so forcing him to do so to change his testimonials wouldnt be acceptable.

After giving that some thought, I decided to make another widgetized sidebar for use with the testimonials page template.  This way, he could add text widgets to just that sidebar.  I got to work, and got it set up, and decided that wasn’t quite right either – what if down the road he decided he wanted to show those testimonials on a sales page, or some other page I hadn’t thought of?  He’d be out of luck.  I decided what I really wanted to do was set up a number of sidebars (I ended up with 6), and allow him to choose the sidebars (it was a 3 column theme) for each page.  Custom Fields were the perfect fit for the job, but that meant he’d have to remember the name of each of the sidebars when he wanted to change them.  A custom post options box seemed just the right fit.  And it did – he was really excited about the functionality, and I was excited to have learned something new.

Required Post Info for a Theme Site

Another project tasked me with creating a wordpress theme site for a client.  He wanted each theme post to have a number of fields relating to its layout and structure – things like number of columns, if it was widgetized, etc.  I decided that the easy way would be to just put the info into the post body, maybe in some custom tags or something – but wouldn’t it be cool if users could search by this info?  I got to work.  What I ended up with was a custom post options box with all the relevant theme info – dropdowns and checkboxes, which removed any possibility of error from user input.  The client was happy, and as always, I had a good time doing it.

Implementation

Before we get to how to actually implement this, a word of warning:  with great power comes great responsibility.  In this case, you’ve got great power to annoy your users – if you’re releasing a plugin with minor functionality that probably doesnt need a decision made on a per-post basis, it’s probably best to leave it off of the post page.  There is no sense in cluttering and slowing down the post page if it isn’t completely necessary.

The actual implementation of this isn’t too hairy – we’ve basically got 4 parts:

1. Tell WordPress what we want
2. Display the options box
3. Retrieve the options
4. Insert them into custom fields

Finding Room on the Post Page with add_meta_box()

First things first – we’ve got to reserve a spot on the oh-so-exclusive edit post page.  Here’s how we do it:

add_action('admin_menu', 'my_post_options_box');

function my_post_options_box() {
add_meta_box('post_info', 'Post Information', 'custom_post_info', 'post', 'side', 'high');
}

First things first – we hook into the admin_menu action, with our callback function my_post_options_box().  With this callback function, we initiate the actual box – with the add_meta_box() call.  Add meta box works like this:

add_meta_box(‘id’, ‘title’, ‘callback’, ‘page’, ‘context’, ‘priority’)

• id – This is the identifier for your box.  Choose wisely.
• title – This holds the string that will display to the user, so make it informative, and properly formatted.
• callback – This references the function that is actually going to display your  option box.
• page – This determines where your post box shows up and your options are post, page, or link.    As far as I know, its not possible to call more than a single option here – so if you want your box on posts and pages, you’ll need to make the call twice.
• context – Where your post box will end up – your options are normal, advanced, and side.  Side shows up on the right side (only available since 2.7), obviously, and, as far as I can tell, both normal and advanced show up below the post box.
• priority – Where (vertically) your box will show up.  Your options are high and low, low putting your option at the bottom of the other boxes, and high putting it at the top.  Both screenshots shown above are set to side and high priority.

Displaying Your Options Box

Now we’re going to actually display the options on the page:

function custom_post_info() {
global $post;
?>
<fieldset id="mycustom-div">
<div>
<p>
<label for="cpi_dropdown_options" >Dropdown Options:</label><br />
<select name="cpi_dropdown_options" id="cpi_dropdown_options">
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 1' ); ?>>Option 1</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 2' ); ?>>Option 2</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 3' ); ?>>Option 3</option>
</select>
<br />
<br />
<label for="cpi_text_option">Text Option:</label><br />
<input type="text" name="cpi_text_option" id="cpi_text_option" value="<?php echo get_post_meta($post->ID, 'cpi_text_option', true); ?>">
</p>
</div>
</fieldset>
<?php
}

Nothing too fancy going on here – but a couple of important points – we grab the $post global at the top – we do this so we can check against already stored values in the database (for editing posts instead of creating them).   The entire section is wrapped in a fieldset, a div, and a paragraph – this ensures that the display matchces the rest of the boxes.  Other than that, its a pretty standard form, we’ve got a dropdown menu and a text box waiting to be populated.

Retrieving the Options and Inserting Them Into Custom Fields

We’ve had the user set the options, all that is left is to retrieve them on “Save Draft” or “Publish”, and put them where they really belong – in custom fields.  This is a little trickier than I expected it to be (and maybe I’ve made it too difficult.  If somebody can think of a way to simplify this, please let me know).

add_action('save_post', 'custom_add_save');
function custom_add_save($postID){
// called after a post or page is saved
if($parent_id = wp_is_post_revision($postID))
{
$postID = $parent_id;
}

if ($_POST['cpi_dropdown_options']) {
update_custom_meta($postID, $_POST['cpi_dropdown_options'], 'cpi_dropdown_options');
}
if ($_POST['cpi_text_option']) {
update_custom_meta($postID, $_POST['cpi_text_option'], 'cpi_text_option');
}
}

The first thing we do is hook into the save_post action.  This is called on both saving and publishing, so we should be covered.  Our custom_add_save takes a post id as input from the save_post action, and we need it to tell wordpress where to save our options.

Next, we need to figure out if the post id we got matches a real post, or just a revision.  Revisions are stored in the database right alongside posts, with their own id and all – so we use the wp_is_post_revision function to determine if we’re working with a revision.  If we are, wp_is_post_revision conveniently hands off the id of the parent post for us to use.

Now we’ll check to see if our options were posted.    If we find a $_POST option matching one of our fields, we use that to update the custom field relating to it – but since we have to do this a few times, I’ve sent the actual work of updating the custom fields to another function – update_custom_meta().  Here, we check if the post_meta (custom field) is already set – if it is, we just update it.  If it isn’t, we add a new one.

All Together Now

// ===================
// = POST OPTION BOX =
// ===================

add_action('admin_menu', 'my_post_options_box');

function my_post_options_box() {
add_meta_box('post_info', 'Post Information', 'custom_post_info', 'post', 'side', 'high');
}

//Adds the actual option box
function custom_post_info() {
global $post;
?>
<fieldset id="mycustom-div">
<div>
<p>
<label for="cpi_dropdown_options" >Dropdown Options:</label><br />
<select name="cpi_dropdown_options" id="cpi_dropdown_options">
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 1' ); ?>>Option 1</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 2' ); ?>>Option 2</option>
<option<?php selected( get_post_meta($post->ID, 'cpi_dropdown_options', true), 'Option 3' ); ?>>Option 3</option>
</select>
<br />
<br />
<label for="cpi_text_option">Text Option:</label><br />
<input type="text" name="cpi_text_option" id="cpi_text_option" value="<?php echo get_post_meta($post->ID, 'cpi_text_option', true); ?>">
</p>
</div>
</fieldset>
<?php
}

add_action('save_post', 'custom_add_save');
function custom_add_save($postID){
// called after a post or page is saved
if($parent_id = wp_is_post_revision($postID))
{
$postID = $parent_id;
}

if ($_POST['cpi_dropdown_options']) {
update_custom_meta($postID, $_POST['cpi_dropdown_options'], 'cpi_dropdown_options');
}
if ($_POST['cpi_text_option']) {
update_custom_meta($postID, $_POST['cpi_text_option'], 'cpi_text_option');
}
}

function update_custom_meta($postID, $newvalue, $field_name) {
// To create new meta
if(!get_post_meta($postID, $field_name)){
add_post_meta($postID, $field_name, $newvalue);
}else{
// or to update existing meta
update_post_meta($postID, $field_name, $newvalue);
}
}
?&gt;

And there you have it.  Quick, go make something interesting!

Maybe Serialize?

As it turns out, WordPress is one step ahead of me.  Maybe_serialize() is called a number of times throughout wordpress, relating to these items:

• Post Meta:  It’s called on add_post_meta() and update_post_meta().
• User Meta:  It’s called on update_usermeta()
• Options:  And, of course, its called on add_option() and update_option()

So there you go.  Use all the arrays and objects you want in post meta, user meta, and options – throw caution to the wind, and put them straight in.  Wordpress will handle the boring stuff.