I am using the resources found here, to build my own groups and fields:
https://www.advancedcustomfields.com/resources/register-fields-via-php/#relational
I registered the field using these settings:
array(
'key' => 'my_unique_key',
'label' => 'Select Page',
'type' => 'post_object',
'post_type' => array('page'),
'return_format' => 'id',
),
The field shows up just fine, but I am getting a “Loading failed” message after clicking on the drop-down menu, and no pages are loaded.
I created this field using the admin later, and then went to the export tool to compare my field settings, but I can’t find what I am missing.
I am loading the field group and field using the acf/init hook.
Loading failure is usually do to either a JavaScript or PHP error during the AJAX request. Look for JS and PHP errors. To see any PHP errors during the request you’ll need to turn on WP_DEBUG_LOG https://codex.wordpress.org/Debugging_in_WordPress
I figured out my issue. I was printing to the browser console using a php function that echo a js console.log. That was causing the issue.
Thanks.
One question while on this subject. I know that each group field needs a unique key, and the same goes for each field. However, is the group and/or field key associated to the actual value stored for a post? Or just the field name/slug?
I am looking at the postmeta table, and I can’t seem to find a relation between the field key and field value stored for a post.
I ask because I am wondering if I need to always use the same unique key for a group, if the group is created on the fly (registering with php)
Not sure where to start and I’m not sure about all the answers. Fields are stored as a posts in a custom post type. Field groups are also posts stored in another custom post type. These posts have a parent post ID. This parent post ID can either be another field post or a field group post.
To be honest, I don’t know what would happen if you alter the field group key in a field group registered through PHP. It’s not something that I would do since I don’t see any reason to change it.
As far as the field key stored in the postmeta table. The key tells ACF what field key is associated with a value so that it knows how to treat that value when you use get_field() and other ACF function. This really isn’t very important for some fields, like a simple text field. If ACF cannot find the field key in the database then it will treat the field as a text field and return whatever values is stored for the field. Like I said, not very important when it comes to a text field.
However, it is very important for other types of field, for example an image field. For and image field ACF stores the attachment post ID. Without the field key in the database ACF will not know it’s an image field and will not be know that it’s supposed to return an image url or an image array and will just return the number as a text value.
Each field key is linked to the field it is for by the meta_key. If you have a field named this_is_a_field then there will be another enter in the database with the meta_key of _this_is_a_field. This is how ACF knows what field key goes with each value in the DB.
Thanks for the write up @hube2. Helps me understand a bit more how acf works.
