Introducing hidden fields during runtime

So for the first part, how to change the post type used for submitted posts:

// USP submit posts to CPT
function usp_modify_post_type($post_type) {
	return 'book'; // change this to the slug of your post type 
}
add_filter('usp_post_type', 'usp_modify_post_type');

For details on this technique, check out the USP FAQs.

And then for the post ID, good news USP already adds the information to each submitted post as a custom field named usp-post-id. So you can make use of for any post-related functionality, etc.

Thanks for the quick response . I am not sure if I was clear in my question .

I have Listing (custom post type), and I want to create a blog post using USP forms. The blog post will be associated with a Listing.

When the blog Post is created, I want to pass a Listing ID (as parent post ID). I can only pass the Listing ID if the ID is stored in the form as a hidden field during the USP form submit.

So, my challenge is to inject an ID of another post type(Listing ) into the rendered form.

How to inject a hidden field during render of the form either using shortcode or hooks ?

I’m not sure then.. Normally every post, page or CPT (whether submitted or not) is assigned a unique Post ID. USP attaches this ID to each submitted post, as explained in my previous reply. Are you saying that you want to assign some other numerical ID value to each submitted post?

I am saying that I want to pass another ID in addition, so I can associate that additional ID as meta data.

Yeah it’s not something that the plugin currently supports, the functionality isn’t there. It might be possible to rig something up using the custom form and the USP custom field, but it’s not something I’ve attempted to do.

Ok. Is it possible to render a ad-hoc Input field type in the form ?

Yes with the custom form enabled, you can add any fields/changes that you want. But as explained the plugin does not provide any corresponding functionality to handle non-USP (ad-hoc) fields that may have been added. The extra functionality however could be added using a custom script that effectively grabs the POST variables and processes the ad-hoc fields as needed.

Thanks. I will use JavaScript to accomplish this to get the job done

Sounds like a plan. Let me know if I can provide any further infos about the plugin, etc.

So I added a hidden field “blogparentpost”: https://prnt.sc/p737bz .

Now, im trying to save things in postmeta during save using the ‘SAVE_POST’ hook:
if (get_post($post_id)->post_type == ‘post’) {
$blog_parentID = $_POST[‘blogparentpost’];
//do somethings here…
}

1) I do not see the posts getting creates, so what is the default post type USP uses?
2) is the Save_post invoked when new post is submitted ?
3) what hook you recommend to use capture current $post+id, and $blog_parentID?

unable to save anything, or perform any other operations right after save.

please help. Waiting for you response.

• This reply was modified 5 years, 5 months ago by nomairkashif.

Glad to help:

1) The default is USP Post. This can be customized in the plugin settings and as described in previous replies in this post.

2) Not currently, but I would be glad to add it in the next plugin update.

3) The plugin uses parse_request, so that should work for further processing.

Please do add thebsave_post hook if you don’t mind.

Secondly, can you post an excerpt how parse_request would work? Does it contain the $postID of the blog post just created ?

Sure you can find the plugin’s use of parse_request in the file user-submitted-posts.php on line 358. Also here is the WP docs for parse_request. Understand that parse_request is an action hook with which USP uses to call usp_checkForPublicSubmission(). Likewise you can hook your own custom function into it, similar to how it’s done in the plugin, only you would use your own logic to do whatever needs done according to your goals, etc.

Perfect!

How do I extract the current published blog post ID in the hook callback ?

It should be available as a POST variable named usp-post-id, which goes on to be attached to the submitted post as a custom field, as explained in previous replies on this thread.