Support

Account

Home Forums General Issues Image returns ID no matter what Return Value is set

Solving

Image returns ID no matter what Return Value is set

  • I’ve experienced this on several installations across different ACF versions.

    When getting an image field, in some cases (havn’t found out why) it neglects the Return Value and just returns the Image ID.

    This StackOverflow issue leads me to believe that it’s a bug:

    http://stackoverflow.com/questions/28236133/acf-img-returns-id-not-url-when-in-archive-php

  • If an image field is always returning the image ID rather than another value as set in the field setting then this is a symptom of a missing or incorrect field_key in the database, or of something that is interfering with ACF formatting the value as you want. The same thing can happen with any field type that is more than a simple text value.

    The first step should be to disable other plugins and switch themes to figure out figure out where the problem might be.

    If you are inserting the images in some way other than the post edit or other edit page then check that the field keys are being inserted correctly into the database as well.

    The fix listed on the link you sent will work if you can’t fix the cause of the issue.

  • I have this same issue, even after deactivating my themes.

    I added it using a Custom Post Type add form. I don’t know if that makes a difference or not.

    When I try to get any image data, whether it is url, array or id, it always returns ID. No matter what.

    The other fields work fine!

  • Another cause of this issue is that there is a pre_get_posts filter that is interfering with the queries that ACF does to get the image information. You’d have to search your code to find this.

  • in case that might be helpful to anyone.
    I was having the same issue – the image would return value “1” even though I had set to return the URL.
    I had the value saved to a variable like this:
    $image_overview = get_field(‘overview_img’);

    Well, so using the variable I was getting the “1” value, but using directly the get_field function returned the URL as it should.

    Can’t explain why this happens though…

    • mikesrt

    • April 11, 2019 at 1:48 am

    NO pre_get_posts stuff or other plugins here, but when I found this happening, I retraced my steps:-

    Turns out it was a field that in -initially- saved as a text field. (I had realised the mistake and immediately switched it over be an image field).

    It was only later when the image field just spitting out ID’s that I made the connection that it was a field where the field type had been switched over.

    To fix I just assumed this was a bug, and ditched that field name, created a new image field from scratch with a slightly different name. Note, this was an image field contained in flexible content field, I don’t know if that makes any difference, because i’m pretty sure I’m made the field type mistake before and this didn’t happen.

    • mrauch

    • May 9, 2019 at 5:28 am

    Thanks, mikesrt. I was having the same issue, and recreating the field cured it.

  • I’ve had this issue randomly at multiple times throughout multiple sites (just happened again — why I’m here), and it doesn’t seem to have anything to do with conflicting plugins or queries. I have always been able to resolve it by switching the output option to “ID”, publishing, then switching it back to “Array” and publishing again. In my case, these were fresh fields, and not saved as another field type prior to being an image field.

  • I have this problem a lot for some reason and what I just did to fix it was export my field group, then edit the JSON and change the field keys slightly. For example if the image field’s key is “field_6034ed0dca8ea” then I would change a few of the characters (hex chars only). Then I deleted the group and imported the edited one, and the value started returning correctly.

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

The topic ‘Image returns ID no matter what Return Value is set’ is closed to new replies.

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.