You could provide a default value for the date field when editing the form, and that default value could come from a custom shortcode, for example.
Or you could run some JavaScript code on the page to provide some value after the page was rendered. The field may be included in the form but hidden from users.
Or you could add the date value after the form was submitted using one of the PHP hooks.
The key to understand is that the date fields are stored as unix timestamps.
If you can clarify what date you will be setting I could offer more specific help.
In that case do you actually need a custom date field at all?
The form will publish a post, and the date and time the form was submitted will be the standard post_date field of that published post which you can output with the wpv-post-date shortcode.
Thank you.
Can I also do it for custom types?
because I make a system of entry/exit of people and I need their date and time of entry and exit.
that's why a dynamically filled field would be perfect.
Custom post types are stored in wp_posts the same as standard blog posts and have the same fields available.
So if your form is publishing custom post types you can still depend upon the post_date field to record the moment the form was submitted. (The post modified field would be updated whenever a post was edited, but the post date field refers to when the post was created and doesn't change.)
It seems redundant to add a custom field to store the same thing, unless there is another reason to.
I need to be able to assign this value because I have two date fields in the custom type, a date and time of arrival field and a date and time of departure field.
and I have to keep them in memory and display them when listing.
yes both fields must be automatic.
the start field will be the date or another form (modifying the custom type) will affect the value of the start date field
OK, I don't really understand your use case but let's press on.
I think you should create the custom fields for start and end date/time and assign them to the post type.
Make a form to publish posts of that type, and either omit the fields from the form altogether (because they will be created automatically) or include them but hide with CSS, and then use the cred_save_data hook to trigger code that runs after the form has been submitted and which populates the date fields.
Something like:
/**
* Automatically set date fields on form submission
*/
add_action('cred_save_data', 'tssupp_form_submit', 10, 2);
function tssupp_form_submit($post_id, $form_data)
{
// Edit
$form_ids = array(123); // array of Form IDs to apply code to
$start = 'entry'; // slug of start field
$end = 'exit'; // slug of end field
if (in_array($form_data['id'], $form_ids)) {
$now = time(); // Current time and date as a timestamp
update_post_meta( $post_id, 'wpcf-'.$start, $now );
update_post_meta( $post_id, 'wpcf-'.$end, $now );
}
}
You'll need to edit the Form id(s) and the slugs of the custom fields, and you likely will need to modify it to suit your needs.
Basically I have a visitor who registers on a form and when he leaves he informs of his departure by filling out another form.
I effectively hide the fields date of arrival and date of departure.
how do I oppress?
So the first form creates a post. The second form, does it edit that first post, or it creates a new post of some other type?
In either case, you can modify the above code so that you have one condition that tests for if you are on the first form and in that case set the start date field and if you are on the second form it sets the departure field.
It doesn't matter if the second form edits the original post or creates a new one.
