Open hejamartin opened 2 years ago
I can corroborate this. I have an Image field set to display as Array but only the ID is being returned.
+1 had REST API issues pop up on a production site, very annoying.
@hejamartin We've seen a couple of tickets regarding this kinda of issue, but haven't been able to reproduce it reliably or understand why it's happening yet - it certainly isn't a universal issue.
The only changes we made to the API code in 5.12 is regarding WordPress internal REST API calls which are "faked" by the internal classes, these now correctly return ACF fields in the formats defined.
Could you share some information about your setup? Are you accessing the URLs remotely? Are you passing any GET parameters which change the rest_api_format
setting? (Full details of this setting here: https://www.advancedcustomfields.com/resources/wp-rest-api-integration/ - we would expect an image to return the ID, unless you've set rest_api_format
to 'standard' from 'light' which is default)
Could you also share any details of plugins you're using, especially if you were using an REST API plugin that provided access to ACF fields before it was built into ACF itself; so we can make sure there is no conflicts there.
Adding
add_filter('acf/settings/rest_api_format', function () {
return 'standard';
});
and ensuring the field's Enable Rest Api option was selected fixed it for me. I wasn't aware the default is set to light
and assumed the value returned is based on the return format value specified in the ACF UI
I'm also using https://wordpress.org/plugins/acf-to-rest-api/ ACF to Rest API mainly for me to be able to query for options fields directly through the rest api.
If you could add that feature to query for options fields directly in the ACF REST API integration that would be great.
Glad to hear that fixed things up for you @AdrianLuk.
We return things like the ID for image fields by default/in the light
API format as we believe the output format should match the input format for POST
requests as well as the format displayed in the schema when using OPTIONS
requests. But of course, some folks will need things to match up with what they expect to be returned via things like get_field()
which is why we made the standard
mode available as well.
This has always been the case since we launched the REST API integration in ACF 5.11, but it sounds like there might have been a conflict with the "ACF to Rest API" plugin that didn't become apparent until the ACF 5.12 release. We'll look into that on our side, but in the meantime we'd recommend just using the official API integration in ACF if possible.
If that isn't possible on existing projects due to differences in the two APIs, it's also worth noting that the ACF REST API implementation can be completely disabled using the acf/settings/rest_api_enabled
filter as shown here:
https://www.advancedcustomfields.com/resources/wp-rest-api-integration/#developer-notes
That would let the "ACF to Rest API" plugin take over and restore things to the way they were.
I had some hours of debugging unexpected errors from 5.11.4 to 5.12. Made a ticket on the acf-site, instead of here - but since I found this place now - it s better suited here.
The three big gotchas for me was this, when upgrading the plugin in our composer-file.
Acf Field Groups disabled the "WP Rest API" setting - even though they earlier was set to "true" - for each field group.
Data typing, json/acf field types Before v5.12, the value of a ACF Type "Number" with the value of 12345 - was represented in the JSON output as a string, "12345", and not 12345. This makes some strict data type checking and external code to have issues. v5.12 changed this.
Even if I do like this change - it will break many implementations.