farnely
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Uncaught TypeError: wp.i18n is undefinedThank you both for your responses. After a bit more digging around and trialling various scenarios, I’ve managed to demonstrate to the developer that there is an issue requiring their attention. It’s been escalated. Am closing this since it appears to not be wordpress core related.
Forum: Developing with WordPress
In reply to: WP_Query Clarification pleaseThank you both for your replies; that’s been a great help
Forum: Plugins
In reply to: [Post Views Counter] Plugin Issue After I Update WordPress 5.5Me too – think it’s due to a change in WordPress 5.5. Maybe the developer will do something if we each raise a ticket??
Forum: Fixing WordPress
In reply to: updated_post_meta & date fieldsHello again
Well it turns out your theory was right; the plugin saves date fields using
add_post_metanotupdate_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.
Hi
Just wondering if you have a timeframe for implementing these changes please?
Forum: Fixing WordPress
In reply to: updated_post_meta & date fieldsHi
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.
Forum: Fixing WordPress
In reply to: updated_post_meta & date fieldsHello 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
Forum: Fixing WordPress
In reply to: updated_post_meta & date fieldsI 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.
Forum: Fixing WordPress
In reply to: CRON Job triggers REST API CallThank you for clarifying and I appreciate your swift response.
Forum: Themes and Templates
In reply to: [einfach] Clarification pleaseYou can ignore this; duff info on stackflow – sorry!
Forum: Plugins
In reply to: [Melapress File Monitor] No email notificationsI have an update for you: at the time the email was sent during the manual scan, a PHP notice appeared in my debug.log starting “PHP Notice: Trying to get property ‘access_token’ of non-object in” and referring to a file in my SMTP plugin. I’m not getting any notices like this when other plugins send emails. Hope this helps.
Forum: Plugins
In reply to: [Melapress File Monitor] Scan FrequencyWell realtime would be awesome but I’d be very happy with hourly scans. Do you have a timeframe for implementing better scanning options?
Forum: Plugins
In reply to: [Melapress File Monitor] Scan FrequencyThanks for coming back to me.
I read about the plugin here https://www.wpwhitesecurity.com/wordpress-plugins/website-file-changes-monitor/ so because it says “get alerted whenever files are added, modified or deleted” it was a bit of a surprise to then find that actually the alert is at the most a daily one.
I would really like to have the ability to run scans multiple times a day, maybe even hourly (for obvious reasons!). Is this something you foresee happening?