But I know it might leave you wondering why the standard way doesn’t work, I’d recommend you create a new ticket for it as I have marked this one resolved and it’s pretty old as well.
@beee using save_post and update_post_meta doesn’t mean you’re wrong or doing it the wrong way, those are built in WordPress functions which might never ever change so I wouldn’t worry too much about it. I have an extension for WooCommerce which I still use some default WordPress functions instead of the WooCommerce ones and I know WooCommerce might update and deprecate their functions while WordPress core most likely wont.
I ended up ditching acf for the plugin and built everything from the ground up and used the built-in WordPress save_post hook: https://codex.wordpress.org/Plugin_API/Action_Reference/save_post
If you have a problem with actions not firing in time try adjusting the priority parameter to see if that helps, but I just made the plugin itself independent. Depending on what you are trying to achieve that might be an option for you as well @beee.
Yh, I’ve been deving on this machine without probs for a long time, I have WP_Debug, WP_Debug_LOG set in wp-config I see it has grown so ill look through it to see what it says.
I did a quick run through it and I didn’t see anything relating to PHP itself. Yeah it’s weird, should work just fine on localhost but I’m finding myself working on it from a test domain atm.
I’ve built many sites on this machine so I don’t think it’s PHP itself (running 5.5) will look into it.
Plugin seems to not work on localhost for some reason with the exact same files, I am running it on my webserver and it’s firing fine.
the only thing I dont understand @john is that for
if( empty($_POST['acf']) ) {
echo '<script>alert("nodata");</script>';
}
this still works even though I edit the fields on the post. I thought it was checking for if there was no custom fields on the post type (so there would be no data in the $_POST request). But it fires on the post type where acf has it’s custom fields.
