Create fields based on taxonomy terms, not available at the time of register fields?

[fabioneves]

Hey! Great framework, good job :)

I'm trying to create some dynamic fields, in this case I want to create a new field for each of product attribute terms from WooCommerce. The problem is that these terms are dynamic and the taxonomies are only available at a later stage.

Few questions:

• Is it possible to delay the register field routine?
• Why is it ran in the "init" hook? I just want to use the carbon fields for admin purposes, running it on every page load seems wrong, any reason for that?
• In my case to build the admin page, I want to just load the carbon fields for that specific page, is that possible? Running it on every frontpage and backend load seems like wasted resources and has performance implications.

Using both latest version of carbon fields (2.1) and wordpress, altho it's kinda irrelevant for this issue.

Thanks!

[atanas-dev]

Hi @fabioneves ,

Is it possible to delay the register field routine?

No, but there's a solution to "loading" values later (see below).

Why is it ran in the "init" hook?

Carbon Fields has a number of container types that utilize a number of WordPress hooks. Initializing on init is required in order to be able to register early enough for everything.

I just want to use the carbon fields for admin purposes, running it on every page load seems wrong, any reason for that?

Containers that do not fit the current page context (i.e. post meta containers on user edit screen) are not loaded entirely - only enough to check if the container should be available at all. Container/field registration is also very lightweight.

Running it on every frontpage and backend load seems like wasted resources and has performance implications.

Unless you have a reproduce case where you can show that there are indeed performance issues then it's only speculation.

I'm trying to create some dynamic fields, in this case I want to create a new field for each of product attribute terms from WooCommerce.

It really depends on what fields you wish to make. For example, if you wish to have a select field which has options depending on attributes or other posts, taxonomies etc. you can pass a callable to ->add_options( 'your_callable_here' ) instead of passing the options directly. This way Carbon Fields will lazyload the options at a later time, only when the relevant field is going to be rendered instead of on every page load. There are also a number of filters that allow you to hook in at a later time rather than on init when defining containers and fields:

• https://carbonfields.net/docs/fields-select/?crb_version=2-1-0 (see Performance Implications)
• https://carbonfields.net/docs/advanced-topics-hooks/?crb_version=2-1-0

[fabioneves]

Hello @atanas-angelov-dev,

Thanks for your time replying to this. I understand that the footprint is very small, but is it really necessary to run it on init? In this case I'm just using carbon fields for admin purposes of a custom plugin, even if the performance is light, it's wasted resources anyway.

I saw the select callback on other issues while I was searching for a solution, but in this case I want to create a number or text field for each product attribute term, so I can define a specific value for each one, as this terms are only available at a later stage, I'm kinda stuck.

I also saw the hooks, but it seems to apply to stuff that is already registered. As everything needs to be pre-registered it seems to limit a bit the options to use this on a dynamic way (in my use case: create fields based on terms)

Is there anyway I could achieve this? Any suggestion?

EDIT: perhaps a callable on the add_tab and add_fields for the future?

[fabioneves]

Example of what I'm trying to achieve (this was done with piklist), but I rather use carbonfields.

[fabioneves]

@atanas-angelov-dev guess there's no workaround for what I want to achieve? Thanks anyway! :) Nice project