Support

Account

Home Forums General Issues Issues with get_field on save_post hook

Solved

Issues with get_field on save_post hook

  • I have an issue where a post is saved, and then after it is saved I want to further process the ACF information (e.g. scan links for images to download). I’m hooking into acf/save_post.

    Previously this was working fine, however in the last few updates it seems to not work. Strangely, I have essentially the same codebase on my developer version and it works fine, however my live production code doesn’t (both ACF plugins are 5.5.5).

    On my live production server the value I get when I use get_field is false (same with get_fields), although I have all the information in the $_POST['acf'] variable for the post’s field information (I tried using acf_format_value on the $_POST['acf']['field_abc...'] and I still got false).

    I can’t use Xdebug on my live production server, so it hinders me somewhat to try to debug, but I’m still trying to figure out what could be causing get_field to return false on a post which does have information for that field in the postmeta table.

  • I have a feeling it may be some kind of issue with the ACF cache.

    In advanced-custom-fields-pro/api/api-value.php for the acf_get_value function I’ve dotted it with some error_log function calls:

    [code]
    function acf_get_value( $post_id = 0, $field ) {

    // vars
    $cache_key = “get_value/post_id={$post_id}/name={$field[‘name’]}”;

    error_log( $cache_key );

    // return early if cache is found
    if( acf_isset_cache($cache_key) ) {

    error_log( ‘cache is set, retrieving from cache’ );

    $cache_value = acf_get_cache($cache_key);

    error_log( json_encode( $cache_value, JSON_PRETTY_PRINT ) );

    return $cache_value;

    }

    // load value
    $value = acf_get_metadata( $post_id, $field[‘name’] );

    error_log( json_encode( $value, JSON_PRETTY_PRINT ) );

    // if value was duplicated, it may now be a serialized string!
    $value = maybe_unserialize( $value );

    error_log( json_encode( $value, JSON_PRETTY_PRINT ) );

    // no value? try default_value
    if( $value === null && isset($field[‘default_value’]) ) {

    $value = $field[‘default_value’];

    }

    // filter for 3rd party customization
    $value = apply_filters( “acf/load_value”, $value, $post_id, $field );
    $value = apply_filters( “acf/load_value/type={$field[‘type’]}”, $value, $post_id, $field );
    $value = apply_filters( “acf/load_value/name={$field[‘_name’]}”, $value, $post_id, $field );
    $value = apply_filters( “acf/load_value/key={$field[‘key’]}”, $value, $post_id, $field );

    error_log( json_encode( $value, JSON_PRETTY_PRINT ) );

    // update cache
    acf_set_cache($cache_key, $value);

    // return
    return $value;

    }
    [/code]

    And then my debug error log output looks like this:

    [code]
    [22-Jan-2017 17:14:22 UTC] get_value/post_id=6180/name=products_selected
    [22-Jan-2017 17:14:22 UTC] cache is set, retrieving from cache
    [22-Jan-2017 17:14:22 UTC] false
    [22-Jan-2017 17:14:22 UTC] action_save_post_selection
    [22-Jan-2017 17:14:22 UTC] 6180
    [22-Jan-2017 17:14:22 UTC] false
    [22-Jan-2017 17:14:22 UTC] {
    “field_5834bbcfd967e”: [
    {
    “field_etc”…
    [/code]

  • Hmmm, I feel like there should be some method to force retrieving an ACF value (like there is in the wp_cache_get). I think this cache thing is really busting my code.

    I do use W3TC and object caching, so it’s probable there’s some configuration there which is doing some interesting things, but I still find it interesting that there is a significant difference of behaviour when I’m on my local dev compared to the live production server, even though ACF and W3TC are configured the same and the theme functions.php is exactly the same too.

  • Don’t know if this will help you or not, but you could dry clearing the cache before trying to get the values. Do acf_delete_cache();

    The acf cache is just an extension of the wp cache.

    I’ve never had a problem getting new values after they were updated, so I can only think that it is definitely something in once of the caching systems that you’re using. From what I know of W3TC it replaces the WP DB cache with it’s own system. I’ve never used W3TC.

  • I used W3TC’s object cache clearing, and in my debug logs I see that the fields get set into the cache, but when it comes to my custom acf/save_post hook to read the saved custom field’s data the value is still false. I’m still looking into it…

  • This should not be effecting you, simply because it’s working for you on one site and not another, but what is the priority of your acf/save_post filter?

  • I have it set to 9999!

    In other news, I turned off the W3TC object cache and it seems to work.

  • 9999, you sound like me.

    I’ve honestly never seen a need to have a cache plugin active on the admin side of things. Possible, because ACF is interacting directly with the WP cache to set and get cache values?

    have you opened a support ticket? Could be you best chance at getting a solution https://support.advancedcustomfields.com/new-ticket/

  • Just to confirm was having the same issue, fixed by turning off W3TC Object cache but would love a more permanent solution.

    Thanks

  • There must be some way one can disable W3TC object cache when accessing as admin. Perhaps it’s only a W3TC issue, but potentially ACF could have an option to disable its own cache if user is certain editor role, e.g. admin, author, editor, etc.

  • We seem to be hitting this issue on our site where we just enabled W3TC last week. In our case we are using a save_post hook on a custom post type and have it set to run at the default priority of 10. After turning on W3TC the values of our get_field calls in the save_post running in the admin are all returning blank. Oddly we tried totally disabling the W3TC plugin and purging all it’s cache, but the issue persists. Using the ‘Debug Objects’ plug-in we still see the W3TC cache objects even with the plug-in disabled and with repeatedly purging the cache. We also tried leaving the W3TC plugin active and disabling and punching it’s object cache and that did not help.

    We have also tried adjusting the priority on the save_post call to 999 and that did not help. Oddly moving the priority to earlier, 9, did fix the get_field issue, but then when we tried later to call update_field that failed to save the data to the wp_postmeta table.

    At this point we are at a bit of a loss on how to proceed with troubleshooting and debugging this issue. Any thoughts or help would be appreciated.

  • I haven’t tried replicating this bug yet, but as a wild guess could this issue be related to the bug outlined over here?

  • Thanks @charleslf, but I’m a bit confused by the GitHub threads. So was the fix not rolled into the 0.9.5.4 update? That seems to be what is being indicated here if I’m reading this right.

  • The w3tc version on GitHub is a community-driven fork of the official w3tc.
    It contains fixes to bugs commonly reported by users, but is not officially maintained by the w3tc folks — the patches are from a bunch of volunteers.

    That being said, several of the patches committed to GitHub actually end up being adopted by the official w3tc team and make their way to the w3tc version hosted on wp.org.

    The fix for the bug in my first reply (here) has been accepted by w3tc team, and will be available in the next plugin update (whenever that comes).

    So, if you want to try it out before the plugin release and see if it fixes this problem, you should apply these changes

    Basically, in ObjectCache_WpObjectCache_Regular.php, in function function get look for $this->cache[$key] = $value; and move it inside the if ( $value !== false ) block.

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

You must be logged in to reply to this topic.