Problem: I would like to create a parametric search View that allows users to filter a list of posts by post status, using a dropdown select filter.
Solution: It is not currently possible to create front-end filters for post status. Other workarounds proposed in the past have limitations that are not easily overcome with custom code. Instead, the most practical approach is to create a custom select field that includes values corresponding to each possible post status. Copy the actual post status information into the value of this custom field for each post, and set up a parametric search View that filters upon this custom field.
In this case the posts are created in Forms, and a generic select field is used to allow the User to choose a post status for the created post. There is a custom code snippet using the cred_submit_complete API to programmatically set the post status after the Form is submitted. We can tap into that event hook to also set the custom field value programmatically with update_post_meta:
add_action('cred_submit_complete', 'my_save_draft',10,2);
function my_save_draft($post_id, $form_data)
{
// if a specific form
if ($form_data['id'] = array(737,521))
{
if (isset($_POST['post_stat']))
{
// update post status
$my_post = array(
'ID' => $post_id,
'post_status' => $_POST['post_stat'],
);
wp_update_post($my_post);
// add / update post-status custom field value
update_post_meta( $post_id, 'wpcf-post-status', $_POST['post_stat']);
}
}
}
Problem: I would like to remove the requirement for a standard User email field in a Create User Form. My Form is set to autogenerate the User login (username).
Solution: Removing the email field and the login field will cause problems because Toolset's login autogeneration process expects an email address to be present in the Form submission. The automatic login is created based on the email address, and the software is not designed to support the case where an email address does not exist and login autogeneration is required. You can work around that problem by specifying your own custom unique generated login in a cred_before_save_data hook, but there are some limitations to consider. See the discussion in the following ticket link.
