In the function hooked onto save_posts
you should make sure that you check that the action wasn’t triggered by an auto-save routine. I suspect that the reason why the post ‘forgets’ the data is that the post auto-saves, and updates the post-meta with blank data.
To do this:
function save_details($post_id){
//Make sure you check this isn't an autosave.
if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE )
return;
update_post_meta($post_id, "media_meta", $_POST["media_meta"]);
update_post_meta($post_id, "highlights_meta", $_POST["highlights_meta"]);
update_post_meta($post_id, "main_meta", $_POST["main_meta"]);
update_post_meta($post_id, "tabbed_meta", $_POST["tabbed_meta"]);
}
I’ve had a quick glance at the tutorial. It seems to ignore best practice and security checks such as the following:
- The function hooked on
save_posts
is given the argument$post_id
(the post ID). You should use this rather thanglobal $post
. - Prefix your functions.
save_details
is very generic, and if the WordPress core or another plug-in uses that function name, it’ll crash your blog. This is particularly important for plugin developers. Prefix it with something unique:my_name_save_details
. Same goes for the other functions. - Check user permissions. Use
current_user_can
to verify that a user is allowed to be editing the post. - Uses nonces. In your metabox, add a nonce and verify it in
my_name_save_details
. This checks the data you’re adding to your database really came from your metabox.(See Codex) - Perform other checks.
save_posts
fires every time a post or page is saved/updated, but you only really want to be altering posts of your custom post type. It’s not essential, but removes the possibility of upsets further down the line. You can useget_post_type
to help with this.