Create Post form with taxonomy list

How To
1

Another Pro Forms question.

I have a taxonomy with a list of local amenities, shops, supermarkets, banks etc.

In a Create Post form, I want to list all of the Taxonomy entries as number input fields so the user can add the distances to each. These fields will need to be saved as rows in an repeater acf field.

Will this work? Will it need custom code action?

Later, the Edit post form will need to list all of the Taxonomy entries as input fields and populate those stored in the repeater. Again, I assume this would have to be custom code.

2

Hi Pete,

let me split it into the two parts, because one half works out of the box and one half needs a little custom help.

Saving distances into an ACF repeater — natively supported

You can build this with the Pro Forms Repeater field plus the Update Post Meta action:

  • Add a Pro Forms Repeater field to your form. Inside one repeater row, put a Number field (the distance) and, if you want, a Text/Select field for the amenity name/ID.
  • In the form’s actions, add Create Post (to create the post), followed by Update Post Meta.
  • In Update Post Meta, set Source = ACF, choose your ACF repeater as the meta field, and set the Repeater Action = “Add rows from repeater”, pointing it at your Repeater field. Each submitted row is written into the ACF repeater as a proper row (it uses ACF’s own add_row() under the hood), so no custom code is needed for the save itself.

Edit form / pre-filling the repeater — also natively supported

On the Edit form, the Pro Forms Repeater field has a Data Source option. Set it to ACF Repeater, give it the field name and the post ID, and it will pre-load the existing rows into the form. On submit, use Update Post Meta with Repeater Action = “Update rows from repeater” to write the edited values back. So the round-trip (read existing rows → edit → save) is covered without code.

The one part that needs custom code

The thing that isn’t automatic is generating one row/field per taxonomy term for you. The Repeater’s Data Source only reads from an existing repeater (ACF/Metabox/JetEngine/ACPT) — there’s no built-in “list every term of this taxonomy as a row” source. So the initial mapping of your amenities taxonomy → one distance field per term is where you’d need a snippet.

A clean approach that keeps everything else native: on bricksforge/pro_forms/post_created, run a small snippet that loops your taxonomy terms and seeds the ACF repeater with one empty row per term (storing the term name/ID in a hidden sub-field). From then on, your Edit form’s Repeater (Data Source = ACF Repeater) will show exactly one row per amenity automatically, ready for the user to fill in the distances — no per-term hard-coding in the builder.

So: the repeater ↔ ACF save and the edit-form pre-fill are both native; only the “auto-create a field for every term” step needs a short custom snippet.

3

Thanks Daniele,
What i really need is for all the amenities to be shown whether or not the user may have selected them.
When is a repeater row considered as having a value? If in the post create form i loop through all of the term entries as number fields and set the default value to 0.0, are they considered to have been selected, or does the user have to visit/change the 0.0 value?

I’d then need a code snippet to save all of the individual number fields into a repeater.

I’m still never quite sure if in a repeater form field if i select multiple items rather than selecting 1 item and clicking the +/- repeater buttons is tge same thing.

Is there a developer guide to creating form elements, like there is for Bricks elements development?

I think it would be useful to be able tp show repeater fields in the standard repeater format, or be able to list the repeater items in a block of individual elements.

Regards
Pete

4

Hi Pete,

Let me take them one by one.

“When is a repeater row considered as having a value? Does a default of 0.0 count?”

0.0 counts as a real value — the user does not have to visit or change it. Under the hood, Pro Forms only skips writing to the repeater when the whole submitted repeater dataset is empty (every sub-field of every row blank). It does not drop individual rows, and it does not treat 0.0 as empty (only a truly blank field, "", is empty).

One small edge to keep in mind: PHP considers the string "0" empty, but "0.0" is not empty. Since you’re already defaulting to 0.0, you’re on the safe side — those rows will be saved as submitted.

The important architecture point for “show all amenities whether selected or not”

The Pro Forms Repeater field is user-driven: it renders one row and the user adds/removes rows with the +/− buttons. It won’t automatically render one row per taxonomy term. So for your goal — every amenity always visible with its own distance input — the cleaner build is not the Repeater field, but:

  • Loop your taxonomy terms in the builder (query loop) and output one Number field per term, each with default 0.0.
  • Give each Number field a predictable Custom ID (Number field → General → Custom ID), e.g. amenity_{term_id}. That way the submitted input name is form-field-amenity_123 and you can map it back to the term.
  • On submit, a small snippet reads those fields and writes them into the ACF repeater with ACF’s own add_row().

Yes, you’ll need a snippet for the save — here’s the shape of it:

add_action('bricksforge/pro_forms/post_created', function ($post_id) {
    $terms = get_terms(['taxonomy' => 'amenities', 'hide_empty' => false]);

    foreach ($terms as $term) {
        $key      = 'form-field-amenity_' . $term->term_id; // matches your Custom ID
        $distance = isset($_POST[$key]) ? floatval($_POST[$key]) : 0.0;

        add_row('amenity_distances', [           // your ACF repeater name
            'amenity_id'   => $term->term_id,     // sub-fields
            'amenity_name' => $term->name,
            'distance'     => $distance,
        ], $post_id);
    }
});

Because you’re building the rows yourself here, you decide what counts — the snippet above saves every term unconditionally (even 0.0), which is exactly the “show/save them all” behaviour you’re after.

For the Edit form, this pairs nicely with what we discussed before: point the Repeater field’s Data Source at the ACF repeater to pre-load the stored rows, or (if you keep the one-field-per-term layout) read the saved values with ACF and set them as the field defaults, then write back with update_row() in the same style.

“Is selecting multiple items in a repeater the same as clicking the +/− buttons?”

No — those are two different things. The Pro Forms Repeater is a row template: each +/− click adds or removes one full row of the field group you built inside it. A multi-select field, by contrast, just stores several selected values inside that single field — it does not create repeater rows. So a multi-select ≠ multiple repeater rows.

“Is there a developer guide for creating form elements, like Bricks has for elements?”

Honest answer: there isn’t a public developer guide / registration API for building brand-new Pro Forms field types the way Bricks documents its element API. Pro Forms is extended through action/filter hooks rather than by registering custom field elements — the ones most relevant to you are bricksforge/pro_forms/custom_action (run your own PHP on submit with full access to the form via the passed $form object), plus lifecycle hooks like bricksforge/pro_forms/post_created (used above), bricksforge/pro_forms/post_updated, and bricksforge/pro_forms/validate. For custom output you’d typically use a query loop + existing fields (as above) or a Code element, rather than a new field type.

On the “one field per term without a snippet” idea

I really like where you’re going with this — needing a snippet just to seed one row/field per taxonomy term is a rough edge. I’ll happily take that to the team as a feature request: a Taxonomy-terms data source for the Repeater field — essentially “list every term of this taxonomy as a row” natively, so the initial mapping works without any custom code. No promise on timing, but it’s exactly the kind of gap worth closing, and I’ll log it.

Hope that clears it up — happy to look at your concrete form setup if you want a second pair of eyes.

Best,
Daniele