Why WordPress Forms Still Ask You to Specify Six Items When You Only Need One
You have filled out a form this week that asked you to specify items you did not have. A conference registration form with six empty attendee rows. A catering order form with ten dish slots when you needed three. A job application asking for four past positions when you had two. You scrolled past the empty rows, filled in the ones you needed, and moved on. Most people do. The form-builder industry counts on it.
For most of the history of WordPress form plugins, this kind of friction was unavoidable. The data structure for truly repeating sections was harder to design than the workaround, so the workaround won. Hardcoded rows became the default pattern. The plugin would let you add as many copies of a field group as the designer wanted, but the visitor had to commit to that number up front. Form designers either accepted the hostile result or scoped their forms down to the simplest cases.
Over the last few years, several form builders have shipped different variants of repeater controls: containers that let the visitor add or remove copies of a field group while filling out the form. Some limit that capability to simple sets — text fields, email fields, phone numbers — but do not extend it to controls with advanced logic, such as calculated fields or dependencies between fields. Others reserve the feature for their commercial versions. Calculated Fields Form chose a different path: it bundled the Repeater control in every distribution of the plugin, so any user can use it at no additional cost, and it allows each row to contain not only basic controls but also controls with more complex logic: calculated fields, file uploads, or dependencies between fields.
This is one of those features that, once you build a form with it, makes the previous approach hard to justify.
What changes for the visitor
Take a workshop registration form for a small conference. A visitor wants to register for several workshops, each with a different price, and bring a different number of people to each. Hardcoded rows would mean asking the visitor to commit to a fixed number of workshops up front, or scrolling past empty rows for the workshops they did not want.
With the Repeater, the form shows one row with two fields: a dropdown listing the available workshops (each option’s value being the per-attendee price), and a number field for the number of attendees. The visitor clicks a button labelled “Add another workshop” and an identical new row appears. They click “Remove” on any row they no longer want. The button labels are configurable in the form designer, which is the kind of detail that separates forms that look like the business’s domain from forms that look like a generic template.
The total cost updates live as the visitor adds and removes workshops. The form adapts to the visitor, not the other way around.
The first Repeater
Using a Repeater is straightforward: insert the control into the form and drag the fields you want to repeat onto it. If you try to drop a control that the Repeater does not support — another Repeater, for instance — the plugin flags it and blocks the operation. The control’s settings are simple: you can set a maximum number of rows, useful when the form corresponds to an event with limited capacity, or leave it uncapped so the visitor can add as many rows as they need. You can also customize the labels of the add and remove buttons, so the form keeps the voice of the business that uses it.
Once the visitor fills in the Repeater’s rows, that data has to go somewhere. If you want it summed, compared, or displayed as a total, the plugin exposes it to formulas through a direct syntax. There is no summing row by row by hand: the plugin already knows which row is which and which field each row contains.
Get CodePeople’s stories in your inbox
Join Medium for free to get updates from this writer.
Take the workshop form again. Each row has a dropdown with the workshop price and a number with the attendee count. If you want to pull the price from the first row the visitor added, the plugin exposes it like this:
fieldname1['rows'][0][3]That reads as: inside the Repeater fieldname1, in row zero, field fieldname3. Rows are counted from zero: the first row the visitor added is zero, the second is one, and so on.
If what you want is the total number of attendees across all workshops, there is no need to sum them one by one. The plugin does it on its own with this other form:
fieldname1['total'][3]That returns the sum of fieldname3 across every row the visitor added.
For the workshop form, the total cost calculation lives in a calculated field outside the Repeater. Inside the Repeater, each row has its own subtotal — the price multiplied by the number of attendees for that row. The outer total sums those subtotals across every row. The result is a total that is correct by construction.
Once the form is submitted, the Repeater’s data also reaches the notification email. The code usually used to include a field in the email includes, in this case, every row of the Repeater already formatted. If you need to control the layout of each row in the body of the email, there is another, more specific way of writing it, flexible enough for the usual cases.
What the Repeater still cannot do
Nested containers are not allowed. A Repeater cannot contain a Div, Fieldset, Popup, or another Repeater. The plugin enforces this in the form builder. If a row needs sub-grouping, the grouping has to happen outside the Repeater, which often means restructuring the form.
What this means for form design in general
The Repeater is a small feature in the broader landscape of WordPress form plugins, and most plugins still ship the hardcoded-rows pattern as their default. That Calculated Fields Form is the plugin that shipped a working Repeater implementation in the free version is consistent with its broader positioning as the calculation-focused option in the space.
For form designers, the practical implication is straightforward. If a form’s structure depends on the visitor’s answers and the count of answers varies — catering orders, equipment rentals, event RSVPs, job applications with multiple past positions, group registrations — the Repeater is the right answer. If the row count is fixed, or the field groups differ from row to row, individual sections separated by page breaks are still cleaner.
The broader point is what the feature implies about forms in general. The visitor’s needs should drive the form’s structure, not the other way around. The hardcoded-rows pattern was always a workaround dressed up as a feature.
