Post Tags | default post, plugins, post content, Post Meta

1. April 18, 2009

   Reply

   I.N.K.

   Hi Peter. I’ve been searching left and right for a viable solution to insert custom_field values in a new post. I got here by reading your comment on justintadlock.com, so I have a basic understanding of your concept behind updating custom_fields on the post editor, before the post is saved. I’m not a programmer but WP got me learnin’ a bit, just by tinkerin’ with code and understanding the logics.

   Here’s a further challenge: I’m planning to have “contribute_to_this_post” links on some posts.
   Site contributors, if logged, can see and follow the link so a pre-populated post editor opens up for them.
   Here comes the pain: I’m trying to establish a parent-child relation between the post they are contributing to and their contribution posts. Since there’s no such thing as parent/child posts, here’s my idea: using a “is_child_of” custom_field. The “contribute_to_this_post” link should be able to pass the postID onto the new post as the value for “is_child_of”.

   Where I am now:
   I’m using morefields plugin, so I have page types with the proper custom_fields ready to be filled.
   I’ve got a function that gives me this url:
   http://mysite.dev/wp-admin/post-new.php?type=my-post-type&is_child_of=xy
   (xy being the pageID of the page where the contribute link is.)

   That will effectively open a new editor, of type “mypagetype”, but then the value of is_child_of won’t go in the field.

   Do you think your method could be a step closer to my solution? Any idea?
   ps: Err..sorry for the lenghty comment.

   • April 18, 2009

     Reply

     Peter

     Hi I.N.K. –

     It sounds like the technique I used could probably be applied here. A couple of questions:
     Do you need the user to be able to edit the parent post id value? Does the user need to be able to edit the post type?

     If the user shouldn’t be able to edit those fields, your job is much easier – you just need to hook in when the post is saved (this is when you first get a post id, so its the first point you’re able to save post meta).

     If you need them to be able to edit the values, its a little more complicated. If that’s the case, let me know, I bet we can figure out a solution.

     Good Luck!

2. April 18, 2009

   Reply

   I.N.K.

   ps2: don’t be (furtherly) confused by “xy being the pageID” and “mypagetype”. Those are mistakes.
   I really meant “xy being the postID” and “myposttype”.

3. April 19, 2009

   Reply

   I.N.K.

   Hi Peter.
   Luckily I can safely answer “no” to both questions. The user doesn’t even need to know about all this “is_child_of” stuff. I’ve been looking at your plugin code, and the solution is right there.
   Obviously some stuff is there just to have different fields and values submitted by the admin.
   I later found out about some very basic/childish/foundation concept: the $_GET.
   The post-new url has the “parentId” already in it (is_child_of=xy), so I could grab it from there with something like ;
   I just need to put together a basic stripped down version of your code, a simple function that sets meta_key “is_child_of” to the value of ”
   And where to put it.
   I know I’m learning something here, but it’s taking me ages, so if you can help, that’d be awesome.
   BTW, mail is valid, so..we can go on with this here, or one on one. whatever you like best.

4. April 19, 2009

   Reply

   I.N.K.

   Code got stripped so, to make sense, I’m adding it here without the php tags
   The post-new url has the “parentId” already in it (is_child_of=xy), so I could grab it from there with something like php echo $_GET["is_child_of"];
   I just need to put together a basic stripped down version of your code, a simple function that sets meta_key “is_child_of” to the value of “php echo $_GET["is_child_of"];

5. April 19, 2009

   Reply

   Peter

   Hah – what a mess! I thought this was going to be a pretty simple solution, but it quickly fell apart. Fortunately, I hate backing down from a challenge. Here’s how I suggest you handle it:

   First, some things you need to know:
   The default post content uses values from the database. Because of this, they are available wherever you need them. Unfortunately, when using a $_GET variable, you’ve only got it once – on the write new post page. The values can’t (easily) be sent through with the first autosave (as I do with the flag in DPC), because it isnt available at $_GET since autosave uses an ajax request to do its magic.

   To get around all this, I decided the easiest thing would be to take the variables from $_GET and put them into hidden fields on the page, so when the post is saved or published, they’ll go through with the rest of the post information. At that point, we can pick them up and use them in new post meta.

   The only problem with this route is that it would be possible for someone, while editing a post, to reset these values, because we can’t really differentiate between that first post save and any other post save (if there is a way to tell the difference, anybody, I’d love to hear it). To do so, however, they’d need to put the variables in the url string. And now that I think of it, we could probably check to make sure we’re on new-post.php, and only show the hidden form fields there – problem solved.

   Anyway, on to some code to get you started:

   First, you need to insert the hidden fields on the new post page. The ‘submitpost_box’ hook seems as good as any, its inside the opening and closing form tags on post-new.php, which is all we really need.
   
add_action('submitpost_box', 'hidden_fields');

   function hidden_fields(){
global $post;
if($post->ID == 0){
echo '
';
echo '
';
}
}

   So, as you can see, on the submitpost_box hook, we’re just echoing out some input fields, with names we can remember (I prefixed them to prevent naming collisions, and because I was testing this inside the DPC plugin code), and give them values from the $_GET. I tested to see if $post->ID == 0 because if it does, we know its a new post. We dont want to do this stuff on posts we’re just editing, because it will overwrite the old values.

   After that, all we need to do is pick up the values when the post is being saved.
   
add_action('transition_post_status', 'dpc_set_postmeta_flag', 10, 3);
function dpc_set_postmeta_flag($new_status, $old_status, $post){
if(isset($_POST['dpc_parent_id']){
update_post_meta($post->ID, 'dpc_parent_id', $_POST['dpc_parent_id']);
update_post_meta($post->ID, 'dpc_page_type', $_POST['dpc_page_type']);
}
}


   Now, I used the transition_post_status hook, because its what I was using in the DPC plugin – but another one might be more fitting – edit_post comes to mind. Anyway, as you can see, all I did was call update_post_meta to get the post meta entered. I checked if $_POST['dpc_parent_id'] was set first because if that isn’t set, then these values weren’t passed in, and we’d probably overwrite the old values with blanks, since it was a post revision.

   I think that should do it – give it a try, and let me know how it turns out for you!

   A little more info, in case you’re not familiar with hooks:
   WordPress Plugin API

6. April 20, 2009

   Reply

   I.N.K.

   Hi Peter, thanks so much for your help + taking the challenge.
   Upon test: the first function works, the second one gives me the pale screen of sadness.
   http://wordpress.pastebin.com/m13e8b081
   I hate the pale screen with a passion.

7. April 20, 2009

   Reply

   Peter

   Hah… the pale screen strikes again. You might look into changing your error_reporting settings for your php install to display errors- the pale screen would become much friendlier

   Anyway, you’re missing a lowly close-paren. Here’s the fixed code:

   http://wordpress.pastebin.com/m2636d1be

   Also, ‘dpc_parent_id’ had curly quotes around it, which was causing php to not read it’s contents properly. My fault for not using pastebin or something similar. Let me know how that turns out!

8. April 20, 2009

   Reply

   I.N.K.

   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   You did it man! This single trick will finally make my whole project come true. I’ve been searching for this solution for like, ages. Coupled with more fields plugin, It totally makes for a much friendly cms environment. From here, it won’t take much for us to go live. I’ll show you when it’s done, so you’ll see what you helped doing. WP community rules.

   On another note: why on earth would somebody wear such thing as a a pale screen t-shirt?
   http://img145.imageshack.us/img145/8614/palescreentshirt.jpg
   that’s beyond me, really.

9. April 20, 2009

   Reply

   Peter

   Glad I could help, and I’m glad to hear your project is going well. I definitely want to see it when it’s ready, so drop me a line here or send me an email at peter[at]apartmentonesix[dot]com.

   Good Luck!

10. December 6, 2009

    Reply

    John Stringfellow

    Peter,

    Thank you for this plugin. It will help me cut out about 7 steps out of my user created content system. I have got it working but I keep getting this error message:

    Warning: Invalid argument supplied for foreach() in /home/*****/public_html/wp-content/plugins/default-post-content/default_post_content.php on line 53

    Warning: Cannot modify header information – headers already sent by (output started at /home/*****/public_html/wp-content/plugins/default-post-content/default_post_content.php:53) in /home/*****/public_html/wp-includes/pluggable.php on line 865

    I am not sure what it asking me to do here. Do you have any ideas?

    John

Submit a Comment