You can clone with
I'm reporting what I believe to be a bug, but could very well be by design (in which case I'd like to get some insight).
I have extended the standard Post type in a table-based Pod. My WP site allows for creation of posts from the front-end, so I'm manually calling wp_insert_post and wp_update_post at various points in my code. Prior to calling those I set some metadata, by calling Pods::save. The thing is, when I call wp_update_post after that, all my metadata in wp_pods_post gets erased.
I've been tracking the code and found PodsMeta::save_post to blame, which is called through WP action save_post. For some reason I don't get, it will call Pods::save with empty values, undoing my job.
Luckily enough there's a simple workaround: I just include "post" in the blacklisted post types before I programmatically update any post via the pods_meta_save_post_blacklist_types filter, but that's just that: a workaround.
Am I doing/getting something wrong or is this plain undesired behavior?
The best way to get around this (for now) is to use pods_no_conflict_on( 'post' ); before you want to run your wp_update_post call, and pods_no_conflict_off( 'post' ); after.
pods_no_conflict_on( 'post' );
pods_no_conflict_off( 'post' );
I'm looking into a fix for the actual issue now though.
Better restricting of wp_insert/update_post integration for #923
Can you retest this issue with the latest fixes? http://pods.io/latest/
Try it without the pods no conflict or any other hack you may have used.
No problem at all, I've closed the ticket as the fix is working for my tests, but if you have any further issue just let me know and I'll reopen this or we can start a new one.