Support

Account

Register Login

Forum Replies Created

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

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

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

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

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

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

  • I had a similar issue where ID’s were being returned even though the field was set to return image arrays.

    The problem was that I was importing content from another site and inserting an array of ID’s into the postmeta table with the key set to the field name as I had see it stored for other fields.
    (I’m guessing this is similar to the last post which mentions an API).

    Once imported the galleries showed normally in the admin area so I started working on the frontend and coded for what got returned, which was ID’s.
    I found that when I made a change to the post, the field then returned an array of images so my code stopped working.

    You need 2 meta fields for the gallery to return an array of images.
    The first one matching the field name which contains an array of image id’s and another with the same key starting with an underscore which references the ACF field ID.

    So in my case I have 1 field:
    sth_additional_images => {array of image ID’s}
    and a second:
    _sth_additional_images => field_5eb0a90d770ad

    So I adjusted the import to insert the second field at the same time, ran it again and then the gallery fields worked as expected.

  • Ah, I didn’t think about using the normal post meta geta.

    I’m fine with the removing slashes as everything is now working for me as it previously was.

    It was more a note that the behaviour has changed, so the documentation might need to be updated here (advanced section) if it is the intended behaviour: https://www.advancedcustomfields.com/resources/date-picker/

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