Title: updated_post_meta & date fields Last modified: July 22, 2020 --- # updated_post_meta & date fields * Resolved [farnely](https://wordpress.org/support/users/farnely/) * (@farnely) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/) * I am using this snippet to create postmeta when a specific field in a custom post is updated by a user on the frontend:- * ``` add_action('updated_post_meta','func_meta_changed', 10, 4); function func_meta_changed($meta_id, $post_id, $meta_key, $meta_value) { $type = get_post_type( $post_id ); if ( $type == 'my-custom-post' ) { if ('custom-field-1' == $meta_key) { add_post_meta($post_id, 'field-meta-updated', 'Field 1'); } } } ``` * If the custom field is a single line or radio, this is working correctly but if the custom field in the post stores a timestamp, nothing happens if the date is changed (not even an empty entry). The date itself IS updating. * Is this expected? Viewing 8 replies - 1 through 8 (of 8 total) * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13166532) * I don’t see why a timestamp would be handled differently. Try adding a series of `error_log()` statements into your code, then check the error log to determine if the action has even fired and called your function; and how far code gets before something goes wrong. The error_log() calls may as well include pertinent variable values as further information on what might be going wrong. * Thread Starter [farnely](https://wordpress.org/support/users/farnely/) * (@farnely) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13168185) * I don’t see why a timestamp would be handled differently either! * I know the function is being called because ‘field-meta-updated’ values are created when other non-date fields are changed. Following your suggestion, I changed my snippet to include a single line field as well (custom-field-2) and added various statements using `error_log()`. I then changed both fields on the frontend, both fields updated correctly in the database I’ve noted the results within the code so it’s hopefully clearer what happened. * ``` add_action('updated_post_meta','func_meta_changed', 10, 4); function func_meta_changed($meta_id, $post_id, $meta_key, $meta_value) { $the_keys = array ($meta_key); foreach ( $the_keys as $each ) { error_log('meta changed: ' . $each, 1, 'email@email.com'); //OUTCOME: report created for custom-field-2 (and an expected hidden meta key I have no control over) //COMMENT: report should have been created for custom-field-1 too } $type = get_post_type( $post_id ); if ( empty( $type) ) { error_log("post type not available", 1, "email@email.com"); //OUTCOME: no report generated } if ( $type == 'my-custom-post' ) { if ('custom-field-1' != $meta_key) { add_post_meta($post_id, 'field-meta-updated', 'Field 1'); error_log("custom-field-1 not meta_key", 1, "email@email.com"); //OUTCOME: report generated } if ('custom-field-1' == $meta_key) { add_post_meta($post_id, 'field-meta-updated', 'Field 1'); error_log("custom-field-1 change recorded", 1, "email@email.com"); //OUTCOME: no report generated } if ('custom-field-2' != $meta_key) { add_post_meta($post_id, 'field-meta-updated', 'Field 2'); error_log("custom-field-2 not meta_key", 1, "email@email.com"); //OUTCOME: report generated //COMMENT: clearly not right! } if ('custom-field-2' == $meta_key) { add_post_meta($post_id, 'field-meta-updated', 'Field 2'); error_log("custom-field-2 change recorded", 1, "email@email.com"); //OUTCOME: report generated } } } ``` * I think my logic for the `error_log()` statements is correct but don’t understand why I’m getting confirmation that custom-field-1 (the date field) was changed AND that it wasn’t yet the data for custom-field-2 is correct. Can you see anything that might be skewing the error reports? * I’d appreciate any further insight or suggestions you might have to get to the bottom of this. * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13169449) * I think doing something under `!=` conditions is confusing the results. The actions could result from any other meta update. Well, the presence of those conditions are confusing me anyway X) * So this seems to indicate that the action does not fire at all when a timestamp is saved for key ‘custom-field-1’. Is this your conclusion as well? But it does fire for ‘custom-field-2’. And saving some non-timestamp value for ‘custom-field- 1’ does cause the action to fire. Is that what is happening? * Where is the ‘custom-field-1’ value being entered? The custom fields meta box on post edit screen? Do you get the same result if you hooked ‘update_post_meta’ instead? I know this would fail to reflect a failed update. I ask for investigative reasons, it’s not a suggested fix if it succeeds. * In addition to `!=` conditions confusing the error logging, you may as well log variable values to ensure all is as expected. For example: `error_log("custom- field-1 change to $meta_value recorded", 1, "email@email.com");` The values checked this way may all be fine, but it’d be important to see if they are not. * I’m a bit leery of emailing log entries, I’m suspicious the order messages come in may not reflect the order in which code executed. If accessing a log file is not convenient and you want to get email debug data, I’d compile all of my log entries into an single variable, then send it all via email all at once through` wp_mail()` at the end of my function. Then everything related to one callback is in one place. * Thread Starter [farnely](https://wordpress.org/support/users/farnely/) * (@farnely) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13170841) * Hello again – thanks for your response. * > So this seems to indicate that the action does not fire at all when a timestamp > is saved for key ‘custom-field-1’. Is this your conclusion as well? * I don’t know/can’t tell if the function isn’t firing for ‘custom-field-1’; it could be firing but simply not “picking up” the change in value?? * > But it does fire for ‘custom-field-2’ * Yes, when just ‘custom-field-2’ is updated or when it’s updated at the same time as ‘custom-field-1’. * > And saving some non-timestamp value for ‘custom-field-1’ does cause the action > to fire. Is that what is happening? * Although where the database is concerned, this is simply a value of some sort, I’m not able to test this scenario because the field was set up as a ‘date type’ and is validated on form submission accordingly and in any event the data entry method for the field on the frontend is a datepicker. I can’t change the validation because I’m using a plugin to create custom fields and frontend submission forms and that performs validation functions in addition to any I might choose to include via the field and form settings. * > Where is the ‘custom-field-1’ value being entered? The custom fields meta box > on post edit screen? Do you get the same result if you hooked ‘update_post_meta’ * Both fields are updated via a form on the frontend (not in wp-admin). The ‘update_post_meta’ hook works OK. * I’ve taken on board everything else you’ve said and actually realised that when you referred to logging values you meant the post values and not the ‘meta-changed’ values (my blond moment). So, I re-wrote my snippet to email me a list of updated keys and their values instead of using `error_log()`, I then changed both custom fields on the frontend and the email contained data for the hidden field I mentioned and the single line but nothing for the date field! * It’s really very strange. I’ve double-checked my field names and the form and I’ve inspected the metadata for the post in the database itself in case of oddities or unexpected content but there isn’t any. The test site I’m experiencing this on is a multi site install so I also tried it on a single site install on a different domain and the behaviour is the same. * Is there any chance at all that you could test the scenario yourself please? If you can’t replicate the issue then I think I need to look at contacting the plugin developers (unless you have any other ideas?) * Many thanks * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13172232) * Thanks for the feedback, that’s all helpful towards my understanding. While I’ve not actually tested your code, I don’t see any reason it wouldn’t work for any conventionally saved meta data. I’m willing to test, but I’m leaning towards the theory that the date data is not saved through update_post_meta(), hence your callback never executes. So evaluating functionality would require me to utilize the same plugin. What plugin are you using for this form? If it has freely available source code I’m willing to take a cursory look and see if there is some easy alternative. * > The ‘update_post_meta’ hook works OK * Works OK in that you get the same debug data as for “updated”? Or works OK where you get the “custom-field-1 change recorded” message and the ‘field-meta-updated’ DB field has the right value? * Thread Starter [farnely](https://wordpress.org/support/users/farnely/) * (@farnely) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13189463) * Hi * Re the update_post_meta hook, it works in that the ‘field-meta-updated’ field is updated correctly in the database. * It’s a paid plugin so code not freely available unfortunately. Your theory is an interesting one so I’ve asked the question in the developer’s support forum. I’ll let you know what they say. * Thread Starter [farnely](https://wordpress.org/support/users/farnely/) * (@farnely) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13193325) * Hello again * Well it turns out your theory was right; the plugin saves date fields using ` add_post_meta` not `update_post_meta`. I’ve added a hook to create the ‘field- meta-updated’ fields for the date field when the form is saved and this has tested successfully. * Thank you so much for your help and guidance – very much appreciated. * Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/) * (@bcworkz) * [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13196192) * You’re welcome. It should have occurred to me to check that action instead. Since“ update” will “add” if the field does not exist, I never use the “add” variant. The possibility was off of my radar. Viewing 8 replies - 1 through 8 (of 8 total) The topic ‘updated_post_meta & date fields’ is closed to new replies. ## Tags * [custom field](https://wordpress.org/support/topic-tag/custom-field/) * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 8 replies * 2 participants * Last reply from: [bcworkz](https://wordpress.org/support/users/bcworkz/) * Last activity: [5 years, 11 months ago](https://wordpress.org/support/topic/updated_post_meta-date-fields/#post-13196192) * Status: resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics