Support

Account

Register Login

Home › Forums › General Issues › acf/save_post not firing on custom plugin/localhost

Solved

acf/save_post not firing on custom plugin/localhost

  • Hey guys,

    This is a WP plugin I’m working on and I plan on using ACF FREE coupled with it to release to the repo.

    The plugin is simple and basically what it does is on save of a post, check some acfs I create and send an email(does much more than that, but thats the basics).

    I tried hooking into save_post action on localhost but it seems to be having some problems on there but on live site it works, but I’ve decided to work with acf/save_post action to make things more related.

    My problem is that im having trouble getting the action to fire.

    Here is my current code which I’m using just to check if acf is firing:

    
function my_acf_save_post( $post_id ) {

	// bail early if no ACF data
	if( empty($_POST['acf']) ) {

		echo '<script>alert("nodata");</script>';

	}

	echo '<script>alert("Saving");</script>';
}
// run before ACF saves the $_POST['acf'] data
add_action('acf/save_post', 'my_acf_save_post', 1);

    This is taken directly from the acf docs page, I tried with the ‘acf’ $_POST key but the changelog said that its a change for ACF 5.0, since im using ACF Free I also tried with ‘fields’.

    Basically I’m getting no echo, whether a script or anything, this is a fresh install. I have the acf plugin folder inside my plugin folder and including the file using include_once(‘advanced-custom-fields/acf.php’);

    thank you

  • Where and when are you adding the action? It seems to be working correctly.

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

  • Because acf uses the same functionality to save its own data that it uses to save our data. Basically the fields you see when editing a field group are the same as the fields you create using them.

    There really shouldn’t be any reason that something does not work on localhost that works on a live server. The only difference is the server. So what you need to find out is what is the difference between you local setup and the setup where you host the sites. Start by running phpinfo() on both on both.

    Create a file in the root of the site, call it info.php.

    <?php phpinfo(); ?>

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

  • I’d definitely start looking at those errors, if you can clear up whatever’s causing them you may find the cause of the filter not being called.

  • I have run into the same issue that values are not saved when using the Free version.
    Using the Pro version (on the same installation, which is a vanilla WP install with twentyseventeen) does work.

    I have used this template to create my plugin.

    Everything works as expected with the Pro version but I can’t seem to hook into the acf/save_post action nor store/see any post data (with the free version active).

    I tried to hook it from functions.php as well as from my custom plugin.

    It seems update_value in this file is not reached.


    @thelonedeveloper     did you ever find a fix ?

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

  • I am building an extension for ACF so I can’t ditch ACF 🙂

    I tried different priorities for acf/save_post but it just won’t reach the function. I put var_dumps and dies in there but it just won’t reach it.

    I also tried several priorities already; 1, 10, 20, 100. Nothing would hook.

    I hadn’t thought about WP’s save_post. That might be an option for me as well.


    @hube2     since you recommended looking at the logs, I did, but nothing shows up there.

  • I dug around a bit. I learned that get_field_objects( get_the_ID() ) returns as false. Which tells me the fields don’t seem to be ‘connected’ to this post.

    I started with a vanilla install again to test what happens without my plugin. Then the save function works as expected. So I concluded the flaw lies in my plugin. This code comes from the template provided by ACF, so I would think/expect it would work with that.

    I checked through my file and I can’t see anything (yet) that would ‘stop’ values from being saved or the field from being ‘disconnected’. If I look in my database I can also see the stored Field group rule which is connected to posts, so that looks ok.

    The normal save_post action works but I would still need get_field_objects to get the correct field key for it, to save it properly.

    But then I probably run into the issue that the fields might not be loaded properly since the field is not recognised.

    If I add a normal text field to the same group, its value does get stored….

    So I just need to ‘connect’ this field to a post, then it should work I think.

  • I think I have fixed it with a workaround by using save_post and storing the value through update_post_meta.

    I had to make an exception so this doesn’t run when v5 is active (because it works there already), so when the v4 fields are loaded I store an option value which is checked in the save_post. If it’s v4 the function runs, otherwise not.

    While it does appear to be working now as I want it, I’d still like to have it working the ‘right way’. Maybe @hube2 has some insight ?

  • @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.

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

  • I understand, that’s why I quoted ‘right way’. Because if prefer to do it as Eliot had in mind when he wrote the template for extensions but I don’t mind using it this way. I’m already happy it works 🙂

    It just has me wondering why it doesn’t work, with the ‘default’ update value function.

    If you’re interested, you can testdrive the plugin (it’s on Github)… Always appreciate any input from other devs on it…

    I will open a new ticket… I wanted to already before I found this one 🙂

Viewing 14 posts - 1 through 14 (of 14 total)

The topic ‘acf/save_post not firing on custom plugin/localhost’ is closed to new replies.