Weird issue with ACF options page

[countfak]

Quick summary

Hi I noticed a strange issue going on with the ACF plugin, specifically when trying to access fields inside an options page. It basically returns nothing.

Steps to reproduce

Use the get_fields function to get all the fields inside an options page, you will see that fields are not retrieved correctly.

get_fields('options');

I was able to reproduce this by creating a new site, and also by importing an existing one.

What you expected to happen

The function should return an array with all the fields from the desired ACF options page. Here's the documentation: https://www.advancedcustomfields.com/resources/get_fields/

What actually happened

The function returns nothing.

Impact

One

Available workarounds?

No but the app is still usable

Platform

Mac Silicon

Logs or notes

No response

[wojtekn]

@countfak thanks for reporting the issue. Would you mind checking if there are any errors logged in the app's log?

tail -f ~/Library/Logs/Studio/current.log   

[countfak]

@wojtekn hi thanks for your reply. No errors inside the log, not even in the wordpress debug log.

[Robertght]

I'm unable to get a license to test this further, however, if you'd like to have this tested later, I believe we could keep it as a backlog issue.

I'm going to mark this as Triaged for now.

[countfak]

Hadn't figure out why the get_fields function is not working.

This is my workaround for now:

foreach (acf_get_fields('FIELD_GROUP_KEY_OR_ID') as $field) {
  $options[$field['name']] = get_field($field['name'], 'options');
}

You basically get all the fields assigned to the options page from the field group (replace "FIELD_GROUP_KEY_OR_ID" with your group key or id). Then you iterate over them and you run a single get_field for each one of them from your options page.

[wojtekn]

@countfak thanks for sharing the workaround.

I've checked this with SCF and var_dump( get_fields('options') ); shows false. It shows the same for explicit post IDs. This function doesn't look as used anywhere in the plugin's code and includes the comment:

The function is not very elegant and wastes a lot of PHP memory / SQL queries if you are not using all the values.

As it seems to be a plugin issue, and you already found a workaround, I will close it. Feel free to reopen if you find steps that work on another dev environment but fail in Studio.

[countfak]

Hi @wojtekn, thanks for looking into it.

Just to be clear, I've been using the get_fields function for years in other dev environments and it always worked fine, even if I know it's not best practice. It's just very handy for options pages. It only seems to fail with Studio. I thought maybe it has something to do with sqlite, but who knows. I wouldn't really know how to debug this.

[wojtekn]

Just to be clear, I've been using the get_fields function for years in other dev environments and it always worked fine, even if I know it's not best practice. It's just very handy for options pages.

Thanks for sharing the context.

It only seems to fail with Studio. I thought maybe it has something to do with sqlite, but who knows. I wouldn't really know how to debug this.

As Studio doesn't support Xdebug yet, I would approach it as follows:

1. Enable debug logging in wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

2. Add debug log calls in get_fields() and functions called inside e.g.:

error_log( var_export( $var, true ) );

3. Open the Terminal and tail the log:

tail -f wp-content/debug.log

4. Keep iterating with 2 and 3 to see how it behaves

I tried debugging that in the Studio site with SCF, but I couldn't manage to have any fields returned there.

I'm happy to check it more to see why it works on other dev environments but not in Studio, but I would need some snippet or steps that would let me reproduce the issue in Studio. E.g. instruction on how to configure SCF to have get_fields() returning correct output in other dev env, and incorrect in Studio.