Support

Account

Home Forums General Issues get_field returning null after update

Solved

get_field returning null after update

  • get_fields is suddenly returning a null value after today’s update. No other changes were made to the site. I took over development from someone else, so this isn’t my code. Was this function depreciated or changed? After switching to get_post_fields, the expected values are returned.

  • Can you please check the code is get_field and not get_fields (note the s)

  • Same issue here. After updating to version 5.11, get_field returns null on my taxonomies:

    get_field('my_field', $taxonomy . '_' . $term_id)

  • What happens if you toggle the return settings and resave, does that fix it?

    So if it’s set to return an array, switch to ID, save, switch back and resave?

  • My bad, no “s”, should have copied paste that. Here was the code that returned null on a key being a taxonomy image slug:

    $img = get_field($key);

    Switched to this as a quick fix

    $img = get_post_field( $key );

  • I’m seeing the same thing after the update.

    All get_field/the_field functions return null.

    I’m seeing this on multiple sites.

    The fields aren’t added by the user or registered in ACF, they are imported into the post from the contents of an API.

    Has there been a change where get_field will only return info if the field is registered by acf or data explicitly entered by the user?

  • Hey folks,

    This is likely happening as a result of a recent security update to the logic behind get_field() and similar functions.

    The problem was that before ACF 5.11, get_field() would return a value even if there wasn’t a matching field. This meant that it could be used to grab non-ACF data, including arbitrary options or user meta.

    However, get_field() should still work in ACF 5.11, as long as the field that you want the value for exists.

    We have seen some cases in support where fields/field groups registered via PHP (via acf_add_local_field_group(), acf_add_local_field(), and the like) are registered on a late action hook, or on a hook specific to the admin or front end, etc.

    In those cases, though the field is registered, it may not available at the time that get_field() is called, so null is returned.

    If you think that might be what’s happening to you, registering the fields on the “acf/init” action hook or just in your theme’s functions.php file should resolve the issue. Otherwise, feel free to reply here or shoot us an email so we can dig into it further.

  • In our project, those fields were not registered via PHP. They were created using the ACF WP Editor.

  • I’m going to update mine to use get_post_meta() instead as the fields in the API’s can change.
    https://developer.wordpress.org/reference/functions/get_post_meta/

    For anyone wanting to do the same, remember that if you just want a single value, you have to set the last parameter to true.
    Otherwise, even if there’s only one field you will still get an array returned containing one item with the value you want.

    @retroriff did yo try toggling the return options? Maybe also try changing the data in the field you are trying to get and save it as well.

  • The following code now returns nothing on the category.php template, used to work fine. I use this code on multiple sites:

    <php while (have_posts()) : the_post(); ?>
    <h3 class="text-center"><?php the_title(); ?></h3/>
    <?php the_field('r4m_video_url'); ?>
    <?php if ( get_field( 'r4m_video_description') ): ?>
    <?php the_field('r4m_video_description'); ?>
    <?php endif; ?>
    <?php endwhile; ?>

    ‘r4m_video_url’ is a text field for iframe code.

    Any ideas what is causing the error?

  • @aodesign have you tried following @jarvis suggestion above?

  • @robwent do you mean switch between the return array options, by editing the field group? Did it work for you? Text field doesn’t have different return formats, or perhaps I’m misunderstanding?

  • @aodesign No, you are correct.
    I would try resaving the field in a post and see if that puts it back, or try specifying the post ID as a second parameter just in case.

    If not, you can download the last version from the downloads page for a temporary fix if it’s a live site.

    My issue was that the postmeta isn’t registered as an acf field but I was using get_field to get the information anyway.

  • @robwent thanks for your input. The field works in a post, but not in the category. I’ve rolled back the ACF plugin for the time being. At least my site is back up again.

  • This update made ACF completely unusable on my website. Rolling back the version this evening.

  • As mentioned by @mattshaw if you are using ACF to manage fields created by some other plugin or value then it is usually a bad idea to do so without creating an ACF field to replace the other field and then hide the other field so that it cannot be used.

    As an example, on every site I built I replace the built in WP featured image field. I do this so that I can require a feature image because the front end design depends on the featured image existing. I create a field with the label “Featured Image” and the name “_thumbnail_id” which is identical to the meta key used by WP for holding the featured image ID. Then I hide the standard featured image input field. This makes it so that I can use get_field('_thumbnail_id') and also makes the value available to all standard WP functions that deals with the featured image.

    I can understand how this can lead to problems for some but the developers of ACF are enforcing what would be considered best practices. get_field() should not be used for getting meta values for fields created outside of ACF. get_{$object_type}_meta() should have been using all along in these cases.

    Another reason of not using get_field() for non ACF fields is simply readability and needing to figure out code in the future. If I see get_field('field name') I and other developers will automatically think that this is an ACF field and I will start looking for this field in the field groups if I need to change something. I will be completely confused when I don’t find that field. It will make the code much harder for others to work on or even myself a year after I’ve written it.

    Another thing to consider is that ACF fields should always be defined no matter how/when they will be used and other methods of showing and hiding those fields should be used rather than conditionally creating the fields. This is one of the uses for the acf/prepare_field filter which can be used to conditionally include a field when showing a field group.

  • @hube2 It may be best practice, but this is also a breaking change that came without warning.

    I’m not really clear on how this improves security, but it would have been a good idea to give a heads up considering how many sites are set to auto-update.

  • Here is a possible fix for those using get_field() for non ACF fields. This is untested. Most of it is pulled out of the function acf_get_metadata().

    
    add_filter('acf/load_value', 'get_meta_or_option_for_acf_get_field', 20, 3);
    function get_post_meta_for_acf_get_field($value, $post_id, $field) {
      if ($value !== NULL) {
        return $value;
      }
      $decoded = acf_decode_post_id( $post_id );
      $id      = $decoded['id'];
      $type    = $decoded['type'];
      if (!$id) {
        return $value;
      }
      $name = $field['name'];
      if ($type === 'option') {
        return get_option("{$id}_{$name}", NULL);
      } else {
        $meta = get_metadata($type, $id, $name, false);
        return isset($meta[0]) ? $meta[0] : NULL;
      }
    }
    
  • @t0su @retroriff @aodesign @williamsp

    If you’re still having issues, could you please shoot an email to support@advancedcustomfields.com so we can troubleshoot further? We’re happy to help out, although it might be a bit tough on the forum.

  • @robwent I definitely see where you’re coming from. I think part of the issue is that we underestimated the number of folks that are using get_field() to get values for fields that don’t technically exist or to get fields unrelated to ACF.

    The other part of the issue is that this was part of a security fix, which we would typically prefer to hold off on disclosing until folks have had a chance to update. That said, we definitely could have done better at documenting this once we did release the update. We’ve since updated the docs for get_field() to include some notes about this change, and updated the release post to point to those notes.

    Regarding how this change improves security – the problem with get_field() being able to get arbitrary values is that it opens up vulnerabilities with things like AJAX requests or form submissions where get_field() might be manipulated by the request data.

  • We are seeing this issue as well.

    We run quite a few large multi-sites and after using switch_to_blog() the get_field(‘something’, ‘options’) returns null.

    This is a big issue for us.

    We found a temp fix, but this seems like a breaking change that needs to be rolled back.

    Joe

  • @floodlightdesign I believe that the only reason you did not have issues with this is the past is that you were using basic fields or possibly other types of fields that store simple text values. That also goes for getting fields with ACF when not created in ACF. The problem on multisite is that the fields need to be defined on the site you are switching from. There have been many topics over the years about this on multisite and ways to work around it. How you’d do this would be dependent on what you’re doing. If you post a new topic with the details I might be able to help you correct.

    I’m not part of the ACF dev team, but I do support what they have implemented. However, I do understand how this can be a problem for those that have depended on what was basically an unintended feature and that it could mean rebuilding sites. That’s why I posted the code that I posted above. While I don’t have this issue, if I did I’d want to be able to update ACF and get site back up and running as quickly as possible until I could fix correctly (or not).

    I will add that the code I provided will only work for fields that store simple text values in the DB because when the ACF field is not defined then ACF will be unable to format more complex fields correctly. But again, I’m assuming that most of the issue has to do with text based field since this flaw in ACF would never have worked with complex data types in the first place.

  • Appreciate the response – we are well aware of a fix. The fix on hundreds of sites becomes less straightforward.

    The main concern is this should not have happened in the first place.

    ACF Pro has been a solid part of our enterprise website implementation strategy for many years. I understand that issues happen, but this seems to be the first of its kind that has effected us so extensively. Changes that break or eliminate previous functionality need to be well publicized and documented.

  • Luckily for me, I only had 1 site affected and only 4 places in the code that needed updating to accommodate the new security feature. Being in a full-time cybersecurity role, I have a lot of appreciation for this feature so that it doesn’t bleed over from unintended functionality. However, more disclosure/documentation about this update and how to mitigate would have been nice for developers so that our sites don’t suddenly go down after auto-updating (as it was for mine) and then scrambling to figure out what caused it.

    I’ve never used this particular plugin in combination with custom developments, so seeing the format of the function name I originally assumed it was a built-in function to WordPress. Took me a little while to figure out no built-in function existed and this was part of ACF. Perhaps adding the plugin tag infront of the function, such as acf_get_field, could have helped ID this as a plugin issue sooner. I appreciate all the support this forum has provided, which will have me considering using this more often for future projects.

  • It’s totally NOT professional.

    Does the new developer REALLY forgot that ACF supports loading local fields from a JSON file, i.e. the fields definition will NOT exist per se, but will exist in a json that ACF loads.

    https://www.advancedcustomfields.com/resources/local-json/

    In my case all my :

    get_field(‘blabla_option_definition_that_should_be_loaded_from_json’, ‘option’)

    are now returning NULL instead of something, breaking all logic based on that.

    In case the new developer didn’t know that too : ACF is also used to generate Options page that have sitewide effects: https://www.advancedcustomfields.com/resources/options-page/

    As a result I have stored ACF field definitions in a JSON file that is totally ignored and thus all sitewide settings stored are ignored.

    And this has been reported on the 10th but you let everyone discover your error, losing money for 3 days wondering what was going on…

    What the hell are you waiting for AT LEAST inform every pro users that there is a glitch and that they should check everything is working fine???

    Very very upset to see this plugin has been acquired and how it’s now being developed.

Viewing 25 posts - 1 through 25 (of 88 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.