Disabled Field Groups and syncing of JSON files

[hirasso]

Hi there,

I just updated to ACF PRO 5.9.3 on one of my sites. After updating, I noticed some strange behaviour with the syncing of JSON field groups: I get presented with a syncing option for all the field groups that are acf-disabled, even though I already had those in my databse before the ACF update.

When clicking sync for those, they are being imported as a duplicate of the already-installed field groups. Here's a screenshot after running the sync twice:

See how even the field group key is the same for the duplicates?

Some more background on my setup: I have one flexible content field 'Modules' that contains clones of my actual modules field groups, that I always name "Module: {{Module Name}}" and set to acf-disabled, so that I don't have to worry about them showing up anywhere except when cloned to my main "Modules" flexible content field.

You can see how in the screenshot there are two duplicates for each of the modules "Module: Iframe", "Module: Profile" and "Module: Accordeon". Clicking 'sync' again would create the next batch of duplicates...

[elliotcondon]

Hi @hirasso

Thanks for reaching out. What a strange issue. My first thought is to determine if this bug was introduced in the 5.9.3 version, or if this bug is due to an external factor.

Can you please setup a staging site and rollback the ACF PRO plugin to 5.9.2 (or the version you had installed previously)?
Please keep me posted with your findings.

[hirasso]

Hi @elliotcondon ,

thanks for getting back to me so quickly! 👍

I just rolled back my database to remove the duplicates and downgraded to ACF 5.8.2 (the previous version that was installed). That brought me to realize that I also had the problem there, I just didn't realize it before:

All the field groups with active set to false are available for syncing, even though they already are in my database.

Investing this further, I found the cause: I tried to build a class that automatically generates my "Modules" flexible content field by pulling in all ACF field groups with the "Module: "-prefix in the title. The bug with the syncing was caused by a call to acf_get_field_groups(false) in my theme before the WordPress init-hook. Even when using the acf/init hook, the problem persists.

So, for future reference: Wait for the init-hook before calling acf_get_field_groups() :)

[elliotcondon]

Hi @hirasso

Thanks for the update. How interesting 🤔... I'm not sure exactly why an early call to the ACF functions could cause the issue, but this is definitely something we will want to investigate.

Would it be possible to ask for some assistance in debugging this? If it's not too much to ask, can you please spin up a fresh WP site in "Local by Flywheel" and try to replicate the issue with the least amount of data / code possible?

​​If you can replicate the issue, please export the site (from flywheel app, right click the site and click "export") and attach to your next reply. ​I'll import this and get to work replicating / testing the issue :)

[hirasso]

Hi @elliotcondon ,

since I don't have any experience with "Local by Flywheel" and I was getting conflicts with my MAMP install, I tried to build a reduced test case for you that will hopefully help you to debug the issue. I created a test-theme with only the following code in its functions.php:

class Tester {
  /**
   * Fires immediately
   */
  public function __construct() {
    // calling acf_get_field_groups() before the WordPress 'init' hook will
    // fetch only 'active' field groups and cache those, so subsequent calls
    // won't retrieve 'acf-disabled' field groups, either:
    echo "before init:";
    var_dump( acf_get_field_groups() );
    add_action('init', [$this, 'init_hook']);
  }

  /**
   * Fires on 'init'
   *
   * @return void
   */
  public function init_hook() {
    echo "on init, before clearing acf cache:";
    var_dump( acf_get_field_groups() );

    // deleting the cache will allow ACF to fetch all field groups again:
    wp_cache_delete("acf_get_field_group_posts", 'acf');

    echo "on init, after clearing acf cache:";
    var_dump( acf_get_field_groups() );
    wp_die();
  }
}
// immediately instanciated class
new Tester();

To test this, you should create one field group with active set to true and one with active set to false.

So it seems that something is preventing ACF from fetching those acf-disabled field groups before init, and then it caches the results and will never give the full available results during a lifecycle. I recon It might have something to to with the post type not being registered yet before init? Anyways, good to know :)

[elliotcondon]

Hi @hirasso

Aah I see. Thanks for the clarification.

I can confirm that by calling acf_get_field_groups() before the "acf/init" action, ACF will incorrectly cache the found Field Groups from only the DB, and not include any registered later via PHP or JSON.

If performing any "ACF Logic" early (before the "init" action), please first call the acf_init(); function which will initialize everything ready for your logic.

[hirasso]

Hi @elliotcondon ,

thanks for the hint – but in this case, it seems to be something else: Both field groups are already in the database. Here is an export of them:

[
    {
        "key": "group_5faa620fceca4",
        "title": "An active field group",
        "fields": [
            {
                "key": "field_5faa62168b505",
                "label": "Testfield",
                "name": "testfield",
                "type": "text",
                "instructions": "",
                "required": 0,
                "conditional_logic": 0,
                "wrapper": {
                    "width": "",
                    "class": "",
                    "id": ""
                },
                "default_value": "",
                "placeholder": "",
                "prepend": "",
                "append": "",
                "maxlength": ""
            }
        ],
        "location": [
            [
                {
                    "param": "post_type",
                    "operator": "==",
                    "value": "post"
                }
            ]
        ],
        "menu_order": 0,
        "position": "normal",
        "style": "default",
        "label_placement": "top",
        "instruction_placement": "label",
        "hide_on_screen": "",
        "active": true,
        "description": ""
    },
    {
        "key": "group_5faa62231ce96",
        "title": "An inactive field group",
        "fields": [
            {
                "key": "field_5faa622320413",
                "label": "Testfield",
                "name": "testfield",
                "type": "text",
                "instructions": "",
                "required": 0,
                "conditional_logic": 0,
                "wrapper": {
                    "width": "",
                    "class": "",
                    "id": ""
                },
                "default_value": "",
                "placeholder": "",
                "prepend": "",
                "append": "",
                "maxlength": ""
            }
        ],
        "location": [
            [
                {
                    "param": "post_type",
                    "operator": "==",
                    "value": "post"
                }
            ]
        ],
        "menu_order": 0,
        "position": "normal",
        "style": "default",
        "label_placement": "top",
        "instruction_placement": "label",
        "hide_on_screen": "",
        "active": false,
        "description": ""
    }
]

Also, calling acf_init() won't fix the issue.

After further investigation, I found the cause (acf.php, lines 186-189):

// Add actions.
add_action( 'init', array($this, 'init'), 5 );
add_action( 'init', array($this, 'register_post_types'), 5 );
add_action( 'init', array($this, 'register_post_status'), 5 );

Calling acf_get_field_groups() earlier than on init with a priority >5, the post status acf-disabled is not yet registered with WordPress, so it won't fetch the field groups with this post status. This seems like standard WordPress behaviour, it would be just good to maybe add information about the correct time to call acf API functions, if you ever find the time to write documentation for those kind of functions :)

The only thing that confused me was that I was getting results at all before the init hook – I would have expected that WordPress wouldn't return any posts for a post type that wasn't registered already. Feels inconsistent to me, but obviously is a WordPress core issue.

[elliotcondon]

@hirasso You went above and beyond - thanks for the explanation!