I can’t relate to this, use it myself more often in the save_post hook. What does your source code look like?
Thread Starter
Jack
(@jack1132132)
For example,
function save_post_callback($post_id) {
$get_files = get_post_meta($post_id, 'upload-1', true);
echo $get_files;
$get_files = get_post_meta($post_id-1, 'upload-1', true);
echo $get_files ;
}
add_action('save_post', 'save_post_callback');
The first echo comes up empty, while the second echo prints the meta of the previous post. When I make another post the meta that wasn’t printed the first time prints now, and again the post getting created prints empty.
Thread Starter
Jack
(@jack1132132)
The meta value is a link to an uploaded file, maybe the file is still being created when the do_action save_post is called.
Thread Starter
Jack
(@jack1132132)
From the thread: https://wordpress.org/support/topic/cron-even-is-working-on-update-but-not-on-publish/
I think you’ve encountered a race condition. When “save_post” fires, the code to set related post meta has yet to complete. It’s a multi-threaded process. PHP continues while data is being written. Writing data is relatively slow. Thus there is not yet post meta to get on initial publish, so your callback terminates early.
Maybe if getting post meta fails, see if there is needed data in $_POST. Only if neither has data should the callback terminate early. I’ve heard that WP core devs will be correcting this by having “save_post” wait for all DB writes to complete. I’ve no idea how that is accomplished, but you could implement something similar if you can learn how they’re doing it. Or wait until the revision hits. Scheduled for 5.8 IIRC.
Maybe that’s what’s happening in my case, not sure there’s a way to determine when the files are uploaded and URL saved to the meta data of the post.
-
This reply was modified 1 year, 10 months ago by Jack.
You have 2 problems in the code:
a) You use the save_post filter without checking any posttype. Your test output could therefore also come from some other concurrent save operation, where the PostId would of course be different from what you expected.
Solution: use posttype specific hooks. For posts this would be:
add_action('save_post_post', 'save_post_callback');
b) The determination of the previous PostId via $post_id-1 is inaccurate. There can come out just as x-any other record. If you want to get a previous record of the same post type, use get_post()
with appropriate search parameters.
Thread Starter
Jack
(@jack1132132)
I’m the only user so there shouldn’t be anyone else posting. I’m using $post_id-1 just to try and debug this, it is retriving the correct meta of the previous post but I wouldn’t use it on production.
Thread Starter
Jack
(@jack1132132)
The wp_postmeta table gets inserted the new field, but updated_postmeta
is never called either…
Thread Starter
Jack
(@jack1132132)
updated_postmeta
or updated_post_meta
nothing works
Thread Starter
Jack
(@jack1132132)
Ok, it’s added_post_meta
not updated_post_meta
for when a new field is inserted… It’s working now.
Lots of bad info on the internet, was under the impression updated_post_meta
was called both when an update and creation happened. And save_hook
and other hooks do NOT work at finding a posts meta right after it’s created because the posts meta is still being saved so it creates a race condition. added_post_meta
is the only way.
-
This reply was modified 1 year, 10 months ago by Jack.