farnely

Thank you both for your replies. mysqli wasn’t an available module for PHP 8 in cPanel but nd_mysql was. Checking nd_mysql solved the issue; appreciate your help.

For some reason, even though I checked the “notify me” box when I replied, I didn’t then get notified.

@diondesigns
I’m very pleased to report your code executes without error and returns the expected value so thank you very much for your input. You’ve helped solve something that’s been bugging me for a while now.

@rossmitchell
thank you for your suggested tweak although it hasn’t changed anything. One thing I forgot to mention in my last response is that foreach($i in $array) produces an unexpected T_STRING error. Changing it to foreach($array as $i) removes the T_STRING error but still doesn’t produce the expected result overall. The code @diondesigns provided works so I’ll close this now although I’m still puzzled as to why it’s not achievable using my original format – maybe I’ll never know!

@rossmitchell tried your suggestion but the ID is no longer being retrieved and still getting an error. when I look at debug.log the content of $alist looks like this:-
”,’ 5′,’ 9′,’ 19′

@joyously if I’ve understood you correctly, you’re saying that instead of $array_list in the prepare statement, I should have a unique variable returning each of the IDs in $array meaning my prepare statement should look like this?

$id = $wpdb->get_var( 
   	$wpdb->prepare("
   		SELECT ID
   		FROM {$wpdb->prefix}posts
   		LEFT JOIN {$wpdb->prefix}postmeta
                ON {$wpdb->prefix}postmeta.post_id={$wpdb->prefix}posts.ID
   		WHERE ID IN ($placeholder_list)
   		AND meta_key = %s
   		AND meta_value = %d
   		",
   		$id1, $id2, $id3, $key, $value
   	)
);

If so, how do I create the required number of unique variables? In my example, I’ve hard-coded the values in the array. In practice, the array is dynamically created and could contain more or fewer and different IDs.

WP Cron runs on my site at the times set by my CRON task in cPanel (it’s not driven by visitor activity). Automatic updates are disabled.

My point is that by visiting that URL (either as an actual visitor or using a script), it’s possible to determine whether the database needs upgrading. That might seem innocent enough but it seems to me that it could be used as a means of identifying websites that are not well maintained/kept up to date and therefore a “good” target for other more sinister intentions.

Thank you both for your responses.

@topher1kenobe : I like your suggestion of using an options table entry and you’ve given me something to think about.

@diondesigns : I have replaced wp cron with a system CRON task. I like the idea of placing the script above root however not so keen on running it from a CRON task in cPanel simply because I’m not sure how many scheduled events I may want to implement and it isn’t easy to organise tasks in cPanel’s CRON manager. Is there any reason why I shouldn’t call the script (if it were placed above root) from within my function in wordpress using require_once or include_once? It doesn’t feel like the “wordpress way” of doing things yet moving wp-config above root appears to be a legitimate thing to do so maybe it would be OK??

Hi again

It only happens for me with pages. Just to be crystal clear:-

if I go to the edit screen for any items listed here (pages): /wp-admin/edit.php?post_type=page, the pop up appears when I leave whether I change anything or not

if I go to the edit screen for any items listed here (posts): /wp-admin/edit.php, the pop up doesn’t appear when I leave

if I go to the edit screen for any items listed here (custom post): /wp-admin/edit.php?post_type=XYZ, the pop up doesn’t appear when I leave

Hope that helps?

Hi @vladytimy
I can confirm this is not happening when editing normal posts (wp-admin/edit.php?post_type=post) or custom posts, only pages.

Since it’s not affecting the frontend and changes are taking effect, I can live with it until the fix.

Thanks for opening the ticket. I’d like to keep this open and mark resolved once I’ve tested the fix if that’s OK?

Sorry forgot to mention, if I change the post content and update, there isn’t an issue with the post not updating (it does).

Thank 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.

Thank you both for your replies; that’s been a great help

Me too – think it’s due to a change in WordPress 5.5. Maybe the developer will do something if we each raise a ticket??

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.

Hi

Just wondering if you have a timeframe for implementing these changes please?

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.

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