Support

Account

Register Login

Home › Forums › General Issues › get_field returning null after update

Solved

get_field returning null after update

  • I think that my issue is that I have a few calls to get_field() in a plugin that are not in any action. This latest update exposed that issue in my code. I’ll fix and update ACF and post back here if that turns out not to be my issue.

    Thanks!

  • @John I’ve been able to replicate my issue on a blank site and I’ve sent this site as an All in One WP Migration backup for the support to investigate.

    I can send it to you too if you want, you seem more responsive than the acf support 😉

    Funny enough the ACF team sent an email this morning about 5.11… not stating that we should check our installation because of the numerous issues reported here… just to announce some news…

    People here are in emergency mode but the ACF team isn’t.

  • Hello,

    In @benjamin74’s case, the issue was they were using get_field in a plugin but not wrapped inside an action hook – so it was executing as soon as WordPress loaded the plugin’s php file, before ACF and WordPress had initialised properly.

    This “worked” prior to 5.11, but incorrectly. Because ACF had no awareness of the field, it returned the raw data from the database without any processing or formatting, or obeying any options defined on the field settings.

    I’m pretty sure the only places where this can happen are in a plugin, or in a theme’s functions.php where you get_field is being called before the “acf/init” action, so ACF is not correctly loaded. In the case of functions like acf_add_options_page, or acf_register_block_type, our sample code includes the requirement to make sure acf/init has happened – but as get_field and the_field are “template” code, the vast majority of instances of their usage is in templates – where you don’t need to worry about making sure WordPress and ACF is fully initialised already – we’ll make sure the documentation is clearer about this for the future.

  • Hey @cbrady23 – Yup, that’s likely to be the cause. If you wrap your code inside a hook that is acf/init or later, you should be okay! But please let me know if you need any further help!

  • Hey @retroriff,

    Where about is your code that does the get_field? Could you drop us an email to [email protected] with your code for that, and we’ll take a look?

    The chances are, that code is happening before ACF has been initialised, and so ACF doesn’t think the fields exist.

  • I’m not sure how others have ever been able to call an ACF function in plugin before acf/init because when it comes to plugins I have always needed to be more careful.

    The issue with plugins is that you never know in what order plugins will be loaded. The order plugins are loaded changes based on the order that they are activated and it can change when they are updated. Someone might get lucky and not have a problem for a long time and then suddenly one will appear.

    One of the things that surprises me is that so many people have gotten lucky for so long and that it took this change bring them to the surface.

    I have even had this issue in themes where I needed to use an ACF field value before init on the “after_theme_setup” hook where theme options are controlled by acf fields on options pages.

    This goes for other plugins as well, not just ACF. When you are building a plugin that depends on another plugin the earliest that you should do anything that requires the other plugin is on the WP init hook.

    This topic and ones like it where something is not working in a plugin has come up many, many times here so I’ve seen many instances of problems caused by trying to do things too soon.

  • Is there a way we can check which fields are being ‘rejected’ when calling get_field in 5.11? That way it makes it easier to add these fields that are not registered through ACF.

  • I am having issues as well with the new version. I use ACF Extended and its function to create a archive page for post types. They use get_field to get data from the archive page like this:
    get_field(‘fieldname’,$posttype’_archive’)

    That doesnt work anymore. I don’t know how they modify the get_field call.

    5.10.2 works like a charm

  • @johannesalfanova-dk Are you having issues outputting those values on archive pages, or getting the data somewhere else in your code?

  • When I call a field on an archive page, I get an empty respons.

  • @johannesalfanova-dk Thanks! I’ll let the ACF Extended developer know and see if we can figure out what’s going on here 🙂

  • Hello @johannesalfanova-dk,

    ACF Extended developer here. I ran some tests on my side with ACF 5.11, and everything looks alright. See test screenshot: https://i.imgur.com/aMbIuJH.png.

    The code used is get_field('my_field', 'my-post-type_archive').

    Can you please share the code you’re using that doesn’t work on your side? Please note that it is important to use {post-type-name}_archive as Post ID. For example: entries_archive or events_archive.

    Also, can you try to retrieve the field like I did, using plain text code (and not with variables like $posttype), to check if it works?

    You can enable the Developer Mode to get more details about the Archive Page, its ID and the fields metadata like I did on my screenshot.

    Note: ACF Extended doesn’t touch the get_field() function. The Archive Page is just a glorified ACF Options Page, that is automatically placed under the related Post Type menu.

    Hope it helps!

    Regards.

  • Hey

    tried that – both with variables for posttype and in plain text. Neither returned any values.

    This is the code:

            $value = get_field($felt, $archive);

    where $felt is the field name and $archive is posttype_archive. In this case ‘produkt_archive’

  • Okay. Can you please enable the Developer Mode using the following code:

    add_action('acfe/init', 'my_acfe_modules');
function my_acfe_modules(){
    
    // Enable Developer Mode
    acfe_update_setting('dev', true);
    
}

    Then visit your Archive Page in the Admin UI. You should now see the ACF Options Meta overview which will display all fields and their values just like they are saved in the database (like in my previous screenshot).

    Your field should be there produkt_archive_felt. Can you please share a screenshot of it?

    Note: To make sure everything is alright, we should discuss and use code with plain text only, without variables (as I don’t really know what is behind those variables).

    So my guess is that you tested: echo get_field('felt', 'produkt_archive');.

    The Developer Mode will confirm if that field exists.

    Regards.

  • I cant rigth now, as installing the update breaks the live site. I need to setup a test site with the update.

    As I said the same code works in 5.10.2, so the get_field call is valid and there is data in that field.

    I will let you know when I have a test site ready.

    ACF field

    The field I am trying to get data from is named “udstiller_label_ental”
    The posttype is called “produkt”
    So I tried:
    get_field('udstiller_label_ental','produkt_archive');
    But got no data in version 5.11. In version 5.10.2 I get “udstiller” as a result.

  • Hello,

    Thanks for the details and info, it’s now a little more clear.

    One question, do you use have_archive(): the_archive() loop from ACF Extended on your Post Type Archive template? If so, do you have any posts of that post type displayed there?

    Just to check something, can you please try to echo get_field('udstiller_label_ental', 'produkt_archive') on a page outside of the Post Type Archive? For example on the Homepage?

    I’ll be waiting for you to setup that Test Install. We’ll get a better view of the data with the Developer Mode screenshot on your Archive Page.

    Regards.

  • @itchef

    Is there a way we can check which fields are being ‘rejected’ when calling get_field in 5.11? That way it makes it easier to add these fields that are not registered through ACF.

    Try your luck with the “query monitor” plugin and have a look at the “php errors” tab, this saved my life. I was using get_field(…,”option”) outside of a function in my theme, I would have never found this by myself, since we’re having hundreds of fields.

    See: Screenshot

  • Is there a way we can check which fields are being ‘rejected’ when calling get_field in 5.11? That way it makes it easier to add these fields that are not registered through ACF.

    5.11.1 just released adds a feature to tell you if fields you are getting fields before they are initialized. I don’t know if it tells you what fields are causing the errors.

  • If you’re using a seo plugin (e.g. yoast) and some custom filters to modify the meta titles/descriptions, make sure, that you are not using get_field() there or at least only on fields, that have really been created with acf. I didn’t get any notice from the acf plugin on one of my website, but then I realized all my meta data is broken, because the placeholder values are no longer working; switching to get_post_meta() fixed all issues in this case also

  • Obviously this update has created a LOT of unintended issues. The current fix of updating documentation and providing a notification that covers a small portion of the troublesome use-cases is not enough. We need a comprehensive fix or a rollback of this so-called security “enhancement”.

  • Also took me hours to fix several of our websites, these essential changes came extremely unexpected. There should have been a prominent notice in the backend for the latest 2-3 versions, that there are fields/functions in use, that could cause issues with the upcoming version.

    Apart from that: If you are facing serious issues that have impact on your site/rankings, I would recommend to download a previous version of this plugin on your account page and then implement all needed fixes in another dev environment without hurry and testing everything, before doing the final switch on the live site

  • I’m still not seeing the security issue here.

    If it was just a case of getting info from the database that wasn’t registered with acf then get_post_meta would have exactly the same problem. Or at least the issue could be fixed without removing old functionality.

    It seems safer now to not use the plugins functions at all.

  • Just to echo what numerous people have said above: this is clearly a breaking change, and I don’t understand how it’s been rolled out both as part of a minor release, and without any deprecation notices preceding the change.

    I appreciate the change makes sense from a security point of view, and that the previous contexts in which get_field worked were strictly speaking “incorrect”, but that doesn’t change the fact that this is a non-backwards compatible API change, which should have been included only as part of a major version release according to semantic versioning standards.

    ACF’s versioning has traditionally been robust and reliable, so it’s surprising that has not been the case on this occasion.

  • @robjs yes “traditionally” it’s been robust… but Elliott sold the plugin this summer and I’m not really sure the new team can be trusted.

    Apparently the somehow managed to ignore that people are using ACF to run mission critical settings : SEO, sitewide settings, plugin behavior settings, etc…

    This change is really an example of “developer making what he thinks make sense (whereas I totally agree with @robwent comment on the dubious security issue it really created) without considering everything it can breaks”.

    Personally if they screw up again, I’ll go somewhere else, despite having been a raving fan of Elliott’s plugin for years.

  • @floodlightdesign Hey, we updated the documentation at https://www.advancedcustomfields.com/resources/acf-field-functions/ to include a sample drop in function which will revert the functionality to the old unsafe output if you’re looking for a quick drop in fix.

Viewing 25 posts - 51 through 75 (of 88 total)
1 2 3 4

You must be logged in to reply to this topic.