Support

Account

Register Login

Home › Forums › Gutenberg › Getting ACF block field keys via API?

Solved

Getting ACF block field keys via API?

  • In a Python script outside of the WordPress environment, I’m attempting to construct a WordPress post dynamically via the REST API using both WP and ACF Pro endpoints as necessary. In WordPress, I’m using ACF for the specification of custom block attributes for the first time, and running into the issue of needing to have the field keys to define blocks within the post content. I don’t want to hardcode the keys from my installation, and would much rather programmatically retrieve them somehow even if that means creating custom API endpoints. But I’m not sure where to look in the WP database for the field key definitions for custom blocks.

    I’m also all ears if there’s an easier means of dynamically constructing WordPress post content by iteratively building up content from blocks via the WP REST API. TBH, the purpose of the Editor Blocks endpoint is still a little confusing to me…

    Thank you!

  • Noting that the WP block-types endpoint would seem to be a good place for this data to live, but no detail is included by default in the attributes field. There’s a data item but it just specifies:

    "data": {"type": "object", "default": []},

  • I can’t give you any specific advice.

    Getting the field keys is not going to be an easy task.

    ACF field groups are posts of the type “acf-field-group” the “post_name” value is the group key. “post_content” holds the settings of the field group.

    ACF fields are posts of the type “acf-field”. These are child posts of either the group post or another field post for sub fields. The “post_name” is the field key. “post_content” holds most of the field settings. Some settings are in the _postmeta for the field post.

    Anyway, that’s how ACF stores information.

    Getting that information.

    There is an internal, undocumented function in ACF: acf_get_field_groups() and you will find it in /includes/acf-field-group-functions.php. This function takes one argument that is an array of “filters”. These filters will get the field groups according to the location rules. For example a filter value of array('post_id' => $post_id) would get all of the field groups that would appear when editing a specific post ID. I do not know all of the possible settings for this but you should be able to get field groups with location rules for a specific “block” and you’re going to have to dig through the ACF code to determine what to use for the filters to do this.

    Once you do the above then there is another undocumented function acf_get_fields(). This in in the file /includes/acf-field-functions.php. This takes one argument $parent. This can be the field group key. This will get a nested array of fields that will look like the array for the field group that you’d get if you exported the field group to PHP.

    The above is the process that ACF goes through when showing the field groups in the WP admin.

    To get the field key of a field you would then have to loop over the fields, and sub fields if you have them (recursive function) to get the field information. Here you would still need something to search for to find the field in question, for example the field name, in order to get the field key. In the end something would still need to be hard coded, in this case the field name and or parent field name if looking for a sub field. In the case of sub fields you would also need to branch your recursive function depending on why type of parent field you are looking at.

  • Thank you, @hube2, this is super helpful and I really appreciate you taking the time to walk me through the internal data structures. I had gleaned a few of these points from your other posts in the forum, but this really pulls it all together.

    One last question: are group/field keys stable (e.g., all references to a particular block type attribute/field are identical, regardless of post or block instance w/in a post) or are they dynamic per post/block?

    I hope this is useful information for others in the future, and thank you for all you do!

  • All keys are unique and stable once they are created. They should never change. The only thing that will remove a field key is deleting a field.

    Field key => field name references for existing data can be broken by moving a field into or out of a field that can have sub fields, this includes group, repeater, flex and clone fields.

    Field keys do not change based on post or anything else, they are not dynamic.

    The only time the same field might have a different key is when using a clone field. Field keys for cloned fields are determined by the clone field settings. These field keys could be the same or they could be a concatenation of the parent field/child field keys. But even here the field key would be stable for that particular parent/child instance.

    ALL functions is ACF for saving and getting fields are based on the field key, field names are provided for our benefit to make coding easier for 99% of users. ACF looks up the field key for a field name by getting the field key reference meta value from the database. This is not the same for blocks. I know that the ACF uses a similar mechanism for blocks but I do not know where or how the field key reference is located in this case. Blocks are actually outside of my experience.

  • I am very glad to hear the field keys are stable! I’ll eventually do some experiments to set up a custom API endpoint to retrieve field metadata based on field group and/or name, and will relay what I find if the ACF keys are accessible in a different manner for blocks. I hope that’s more of a surface level distinction on the location rules for the field group. I wonder if anyone has made the acf-field-group and acf-field CPTs accessible via the REST API? ty for your help!

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.