I'm using the wordpress function updated_post_meta to populate custom field 'D' if custom field 'A', 'B' or 'C' are updated using a CRED edit form. This is working for single line and radio fields but not date fields.
I've carried out extensive testing and ascertained that date fields & their content are simply not being picked up by the updated_post_meta function. It's been suggested that perhaps CRED doesn't use update_post_meta to update the field value in the database. Could this be the case?
It's been suggested that perhaps CRED doesn't use update_post_meta to update the field value in the database. Could this be the case?
Hello this is, strangely enough, correct. CRED does not use update_post_meta to set date field values, it uses add_post_meta. It turns out that when an edit post Form is submitted, the date field meta values are first deleted, then added back to the post. In my local tests, it looks like this happens every time the Edit Post Form is submitted, regardless of whether or not there has been a modification to the date. I don't have the technical information about why it needs to happen this way, but my guess is it has to do with Form notification triggers and hooks, or timezones.
You could use add_post_meta to listen for the event where a custom date field is added, but this hook doesn't help you determine whether or not the value was modified, whether the event was triggered by creating a new post or editing an existing post, which Form initiated the addition, etc., so not really much help there.
Let me run a quick test with cred_before_save_data. I think you might be able to check in the $_POST superglobal to validate the current values from the database vs the selected values from the Form in $_POST. I'll update you shortly.
Okay yes, in a cred_before_save_data callback you can get the current value of a date field from the database (Unix timestamp format) and get the same Unix timestamp format from the datepicker in a Form.
Current date field value in Unix timestamp format:
$post_id = 12345;
$current_date = get_post_meta( $post_id, 'wpcf-date-field-slug', true);
In a cred_before_save_data callback, this is how you get the selected date from the Form in Unix timestamp format:
$new_date = $_POST['wpcf-date-field-slug']['timestamp'];
For other field types, drop the 'timestamp' at the end, like this:
$new_text = $_POST['wpcf-text-field-slug'];
You can compare those values as integers to determine if there was a change in the Form:
if( intval($current_date) !== intval($new_date) ) {
// the date was changed in the Form
}
I'm not sure of your PHP skill level so if you need more direct guidance please do let me know. I can show you links to the CRED API with a code example (click the orange "+ More" button):
https://toolset.com/documentation/programmer-reference/cred-api/#cred_before_save_data
Your custom code probably needs to account for the case where the date is removed in Forms, and also account for the case where the date is added in Forms but did not previously exist. The same is true for the two other fields, so the custom code will not be very short and simple. I'm able to help if you run into a specific problem or need advice, just let me know.
Hi Christian
That's great - thank you! I had set up a workaround whilst you investigated but your solution is neater.
It's interesting you say the treatment of date field is to do with cred notification data; in my tests i could see that updated_post_meta is triggered at least 4 times when the form is set to send an email. I don't know if that figure is per email (my form only has one notification to one user) or for the form submission itself but it does seem excessive. Do you know if there's a reason for it? I'm tempted to take notifications out of cred and put them into cred_save_data instead!
No unfortunately I don't know offhand, CRED is a bit of an older code base so it doesn't surprise me that there are some inefficient routines built in.
My issue is resolved now. Thank you!
