update_post_meta() data appears to be overwritten with NULL

Thank you very much!
It’s good advice, I will try NULL trapping the updates as you suggest, and check for empty $post_id.

3. I am not able to understand this line
$cpt_meta_fields = (array)$this;
$this is a class object and you’re converting it into an array, doesn’t make sense to me.

The class in fact contains more than 20 attributes, and I am using this to convert to a key value array, without having to explicitly access each, which I can then pass to the meta update.
It’s analogous to
get_object_vars($obj)
but includes the (many) private attributes.

Thanks again

@bcworkz thank you, that is a very interesting thought.

Briefly the data is in fact POSTed from a nodejs system that receives, parses and scrubs data from external systems before POSTing it to this code.
I have validated the contents of the json before it gets sent many times as part of this whole debugging process (I do not have an example to hand, but could generate one if it’s helpful).

Here’s the latest version of the POST handler code (changed slightly from in the original post above, as part of my ongoing efforts):

// we might be getting POSTed json data from the back end sync
if ($_SERVER['REQUEST_METHOD'] == "POST"){
	$json = file_get_contents('php://input');
	if ($json){
		$data = json_decode($json, true);
		$registry = new My_Registry($data);
		$registry->create_or_update();
		unset($registry);
		exit();
	}
}

I think the unset() and exit() are not needed, but not causing further issues.

I’ve added a debug var_dump() to the _write_meta_value() function above (3 posts up), and that has only ever shown valid data. But having said that, what you describe is exactly consistent with the problem I am having. Here’s the full code that decides whether to create or update. I believe this should always end up with a valid value for $this->registry_cpt_id but I have stared at it so much I may well have missed something:

function create_or_update(){
	$post_id = $this->_exists();
	if ( empty($post_id) ){
		$post_id = wp_insert_post(array (
			'post_type' => 'gwc_registry',
			'post_title' => $this->title,
			'post_status' => 'publish',
			'comment_status' => 'closed',
			'ping_status' => 'closed'
		));
	} else {
		// TODO update existing post title here if necessary
	}
	// do we now have a post to work with?
	if ( ! empty($post_id) ){
		$this->registry_cpt_id = $post_id;
		$this->_update_meta();
	}
}

private function _exists(){
	$params = array(
		'posts_per_page' => 1,//only looking for one hit
		'post_type' => 'gwc_registry',
		'meta_key' => 'registry_id',
		'meta_value' => $this->id
	);
	$reg_query = new WP_Query($params);
	if ($reg_query->have_posts()) {
		$reg_query->the_post();
		$post_id = get_the_id();
		wp_reset_postdata();
		return $post_id;
	}
	return false;
}

Unfortunately importing this data from multiple sources (which I have no control over) means there are multiple unique index key fields that need to be preserved. So $this->registry_cpt_id is the WordPress post ID, different from $this->id and $this->registryno.

Sorry for the long post, and thanks again

Thanks @vijayhardaha that’s a good thought.
Let me look in to that (obviously there’s some private content I have to filter out).

I’ve put what I believe is everything relevant in a Gist.
A few comments:

• I’ve included the small awk script I used to remove proprietary / personal info from the example POST json strings. This was run with a final sed cleanup like this – ./awk-cleanup.sh post1.txt | sed 's/,}/}/g' > post1-clean.txt
• I believe the result is still valid json, but I have not tested that (it’s a fine tradeoff between a good result and writing a custom json parser obviously)
• I’ve also included the my_dump.php utility that is referenced many times (commented out) in the code
• I have pasted the cleaned up code without removing my code comments, and also left a few commented lines of code in the hope it might be helpful as well.

Sorry for the lengthy turnaround – it took some time to put this all together in a shareable form.

Edit: One final comment in case it’s relevant, the POST is going to a custom archive page for the Registry CPT;

• This reply was modified 2 years, 3 months ago by cxtinac.

Thank you very much @vijayhardaha I have looked at your Gist.

These are good cleanup suggestions, I will do this. I guess my question would be do you believe this will help with the original problem? Obviously there are many ways to wrangle the incoming stringified json POST into update_post_meta() calls, but I still have been unable to find any evidence that I’m sending invalid data to update_post_meta() (I wish I had!).

I am still not able to understand $cpt_meta_fields = (array)$this; this.

The My_Registry class is a pretty thin wrapper on the $data array anyway, and (array)$this then is a one-line way to get the data array back out, without getting backed in to iterating over dozens of fields by name. The (admittedly small) advantage of actually parsing $data into private fields in the class in the first place is that it will help me cleanly reference individual fields as needed in future code. The object “unpacking” happens in a private method, and obviously values are referenced read-only fwiw.

There is a detailed discussion of this approach here, in case you have not seen that.
Hope that helps.

Thanks again for your advice.

Fixed.
The problem was that the custom post type was using a global $post; to get a post ID to operate on when it ran update_post_meta() (old code), and when a new custom post was created it leaked a reference to the prior post, leading to the confusing results I experienced.

So for me the learning is be exceptionally cautious about scope when using global $post;, especially outside of theme files and the loop!

Here’s the discussion that put me on to the solution.

@vijayhardaha @bcworkz thank you very much for your help, advice and support!
I will update the Status to resolved.