acf_get_fields function access array indexes 'key' and 'ID' without checking their existence

[simplyrapf]

After updating from 5.7.10 to 5.8.0, I get the following notices:

Notice: Undefined index: key in /plugins/advanced-custom-fields-pro/includes/acf-field-functions.php on line 349

Notice: Undefined index: ID in /plugins/advanced-custom-fields-pro/includes/acf-field-functions.php on line 361

This is usually not a problem, but when trying to use with other plugins like https://www.wpgraphql.com/acf

It causes an issue where my graphql endpoint breaks because of this function.

ACF Pro version: 5.8.0
PHP version: 7.1.20
ACF Implementation: Flexible content component using cloned ACF field groups as layouts.

This issue has already been reported in the support forums:
https://support.advancedcustomfields.com/forums/topic/acf-field-functions-php349-undefined-index-key/

And the solution for it has been posted but no PR was ever created.

[simplyrapf]

I submitted a PR for this problem:
#267

[elliotcondon]

Hi @simplyrapf

Thanks for the PR. Before merging in a solution to this problem, I would first like to replicate it.
In the past, I was not able to get a hold of a testing site where this issue exists.

Are you able to share with me a dev site that demonstrates this PHP error?

[CreativeDive]

Hey @elliotcondon,

I've the same issue if I save local field groups in different folders like this example: https://wphave.de/acf-feldgruppen-automatisch-in-verschiedenen-verzeichnissen-speichern/

After change the code to:

if ( isset($parent['key'], $parent['ID']) ) {

	// Check local fields first.
	if( acf_have_local_fields($parent['key']) ) {
		$raw_fields = acf_get_local_fields( $parent['key'] );
		foreach( $raw_fields as $raw_field ) {
			$fields[] = acf_get_field( $raw_field['key'] );
		}

	// Then check database.
	} else {
		$raw_fields = acf_get_raw_fields( $parent['ID'] );
		foreach( $raw_fields as $raw_field ) {
			$fields[] = acf_get_field( $raw_field['ID'] );
		}
	}

}

... this solves the PHP notices. And by the way by adding if ( isset($parent['key'], $parent['ID']) ) { I can see a slight improvement in loading time, if we use a lot of field groups :-)

Will be this a part of the upcoming ACF 5.8.8 release?

[elliotcondon]

Hi @CreativeDive

Thanks for the update.

Is there any chance you are able to replicate this issue on a local or dev site?
I am very motivated to implement this fix, but have not yet been able to replicate the issue.
In theory, it should not be possible for ACF to attempt to load fields of a parent that does not exist.

[CreativeDive]

Hey @elliotcondon,

thanks for reply, maybe this is helping you:

I don't get this issue in every case. However, it seems that this issue is associated with "cloned fields" and "flexible content" when I include local field groups from different locations, e.g.

function acf_json_load( $paths ) {	
		
	unset( $paths[0] );

	$paths = array( $path_to . '/acf-json' ) );

	$paths[] = $path_to_2 . '/acf-deprecated-json' );

	return $paths;

}

add_filter('acf/settings/load_json', 'acf_json_load');

By adding if ( isset($parent['key'], $parent['ID']) ) { this solves the issue. Do you have any idea?

[CreativeDive]

@elliotcondon

I think this issue is associated with loading different types of field groups:

CASE 1:
--> I have synchronized field groups at "Custom Fields", which are loaded from here.
--> And I have additional local JSON field groups which are not synchronized and which are loaded as JSON file from an other location

HERE I GET THIS "Undefined index" ISSUE

CASE 2:
--> Field groups are loaded completely from synchronized field groups at "Custom Fields"

I DON'T GET THIS ISSUE

CASE 3:
--> Field groups are loaded completely from PHP exported file

I DON'T GET THIS ISSUE

[elliotcondon]

@CreativeDive

interesting. By the sounds of it, this is a conflict created by the Clone field. Thanks for the PHP error trace, this will be very helpful.

Is there any chance of getting a dev or staging site to test with?

[CreativeDive]

@elliotcondon what do you prefer?

The sql database file with a duplicator file of the Wordpress installation?

[elliotcondon]

My preferred method would be a 'Local by Flywheel' export.

If it's possible, can you please spin up a fresh WP site in "Local by Flywheel" and try to replicate the issue? Please keep the default theme active and edit the functions.php file with any extra logic needed.​

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

Otherwise, I'll be happy to setup the dev site using duplicator too :)

[simplyrapf]

@elliotcondon @CreativeDive unfortunately I cannot provide a dev site based of the project that is affected by this issue. I will try to replicate this on a fresh installation of wordpress in order to provide you a copy.

However, I should point out that this issue has been raised in your forums and it seems to affect many other users.

[hirasso]

@elliotcondon I also just ran into this issue. It happens for me if I delete a field group (let's call it "My module") that was referenced from another field as clone "All fields from My module field group". When I go to a post edit screen where the clone field is in use, I get these errors:

Notice: Undefined index: key in .../plugins/advanced-custom-fields-pro/includes/acf-field-functions.php on line 355

Notice: Undefined index: key in .../plugins/advanced-custom-fields-pro/includes/acf-field-functions.php on line 356

Here's my debug backtrace:

array(21) {
  [0]=>
  string(14) "acf_get_fields"
  [1]=>
  string(34) "acf_field_clone->get_cloned_fields"
  [2]=>
  string(27) "acf_field_clone->load_field"
  [3]=>
  string(22) "WP_Hook->apply_filters"
  [4]=>
  string(52) "apply_filters_ref_array('acf/load_field/type=clone')"
  [5]=>
  string(26) "_acf_apply_hook_variations"
  [6]=>
  string(22) "WP_Hook->apply_filters"
  [7]=>
  string(31) "apply_filters('acf/load_field')"
  [8]=>
  string(13) "acf_get_field"
  [9]=>
  string(14) "acf_get_fields"
  [10]=>
  string(38) "acf_field_flexible_content->load_field"
  [11]=>
  string(22) "WP_Hook->apply_filters"
  [12]=>
  string(63) "apply_filters_ref_array('acf/load_field/type=flexible_content')"
  [13]=>
  string(26) "_acf_apply_hook_variations"
  [14]=>
  string(22) "WP_Hook->apply_filters"
  [15]=>
  string(31) "apply_filters('acf/load_field')"
  [16]=>
  string(13) "acf_get_field"
  [17]=>
  string(14) "acf_get_fields"
  [18]=>
  string(30) "ACF_Form_Post->render_meta_box"
  [19]=>
  string(13) "do_meta_boxes"
  [20]=>
  string(42) "require('wp-admin/edit-form-advanced.php')"
}

[CreativeDive]

Unfortunately I have not yet managed to create a test environment. Sorry. Maybe you can do it @hirasso ? That would help @elliotcondon to solve that issue.

[CreativeDive]

@elliotcondon I run into this issue again on a new WordPress installation. This time the taxonomy admin page (category or tags) loads extremely slow and show a lot of fields with totally other locations:

Here more about this issue:

To wrap this condition with if ( isset($parent['key'], $parent['ID']) ) { ... } solves that issue.

My question, why you don't add this litte fix to the ACF core? It seems that the error appears with several users and this fix is helping very well.

I can't say why this is happen. I've a other installation and it runs very well on the taxonomy admin page.

[elliotcondon]

Hi @CreativeDive

Thanks for the bug update. This screenshot looks very different to the standard WP admin. Can you share a more complete screenshot that helps explain what all these tabs are?

[CreativeDive]

@elliotcondon The look of the WP admin is not important here. This comes from my admin theme.

I've figured out more about this issue.

In my case I have older deprecated field groups. This field groups are loaded from a other location. I load the default field groups from "acf-json" and the deprecated field groups from a additional folder "acf-deprecated-json".

Some of this deprecated field groups includes a clone field, which is embed a other deprecated field group.

It's possible that this deprecated field groups lose the connection to the included clone field?

Do you have any idea how we can solve this specific case?