Skip Navigation

[Resuelto] Date Field update_post_meta not firing

Este hilo está resuelto. Aquí tiene una descripción del problema y la solución.

Problem: I would like to use update_post_meta to listen for changed postmeta values, but the hook does not seem to fire for date fields.

Solution: That is correct. Date fields are removed, then readded each time an edit post form is submitted. Use the add_post_meta hook to listen for this event instead.

This support ticket is created hace 3 años, 8 meses. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Etiquetado: 

This topic contains 5 respuestas, has 2 mensajes.

Last updated by julieP hace 3 años, 7 meses.

Assisted by: Christian Cox.

Autor
Mensajes
#1722457

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?

#1723041

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.

#1723077

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.

#1723429

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!

#1725113

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.

#1735491

My issue is resolved now. Thank you!

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.