Gravity Forms 3.0 adds repeater merge tag modifiers including count, text, field_ids, and value. They solve different output problems. A notification may need readable labels, a CRM webhook may need raw values, and a summary may need only selected child fields. Reusing one modifier everywhere can leak unwanted child fields, keep HTML in a plain-text channel, flatten rows ambiguously, or produce a count that does not match the filtered values. The test should use a repeater fixture with empty, repeated, special-character, and multi-field rows, then compare each destination.
Use this when upgrading repeater notifications, confirmations, PDFs, webhooks, exports, or custom templates to Gravity Forms 3.0 merge tag modifiers.
Quick answer
Create one canary entry with zero, one, and several repeater rows. Include labels, HTML-sensitive characters, blank optional fields, and multiple child IDs. Render the default tag plus count, text, field_ids, and value variants in every intended context. Define whether rows need labels, HTML, delimiters, field filtering, escaping, and stable machine keys. Keep human email output separate from machine payload output.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Count | Zero and three rows | 0 and 3 |
| Text | Markup-like values | Readable escaped text |
| Field IDs | Selected child IDs | Only intended values |
| Value | Machine payload | No labels or HTML |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Map every output context | List each repeater merge tag, destination, expected row order, included child fields, label policy, HTML policy, delimiter, encoding, and empty-row behavior. | Count, row order, selected fields, labels, and empty values match the written contract. |
| Create boundary-value repeater entries | Build fixtures for zero, one, and multiple rows with blank optional values, repeated values, punctuation, markup-like text, Unicode, and reordered child fields. | HTML and plain-text outputs are escaped and readable in their actual clients. |
| Compare each built-in modifier | Render the tag in HTML email, plain-text email, confirmation, PDF or document, export, webhook JSON, and any custom replacement filter. | Webhook and export consumers receive stable values without translated labels as keys. |
| Separate human and machine templates | Compare count with the actual number of accepted repeats and verify field_ids includes only the intended child IDs without changing order unexpectedly. | Template snapshots pass for zero, one, and several repeater rows. |
What to check first
- List each repeater merge tag, destination, expected row order, included child fields, label policy, HTML policy, delimiter, encoding, and empty-row behavior.
- Build fixtures for zero, one, and multiple rows with blank optional values, repeated values, punctuation, markup-like text, Unicode, and reordered child fields.
- Render the tag in HTML email, plain-text email, confirmation, PDF or document, export, webhook JSON, and any custom replacement filter.
- Compare count with the actual number of accepted repeats and verify field_ids includes only the intended child IDs without changing order unexpectedly.
- Escape output for its destination, store raw source data separately, and add snapshot tests for templates that affect customers or integrations.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because a cache purge, scheduled action, retry, or deployment can change the evidence between tests.
- Test the real browser and downstream record, not only an admin preview or isolated API call.
- Close the task only after the public workflow, server-side record, and relevant delivery or analytics system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
{Team Members:8}
{Team Members:8:count}
{Team Members:8:text}
{Team Members:8:field_ids=2|4}
{Team Members:8:value}
# Compare output in HTML, text, JSON, and export contexts.
Why this usually happens
- A template assumes the default formatted output is suitable for JSON or plain text.
- Blank child fields make visual rows and counted rows look different.
- A custom merge-tag filter changes output after the built-in modifier runs.
- Labels or translated text are used as machine keys and change across locales.
Decision rule
Use the narrowest modifier that matches the destination. Do not send formatted HTML to machine consumers or expose every child field when a selected field list is enough.
Production verification checklist
- Count, row order, selected fields, labels, and empty values match the written contract.
- HTML and plain-text outputs are escaped and readable in their actual clients.
- Webhook and export consumers receive stable values without translated labels as keys.
- Template snapshots pass for zero, one, and several repeater rows.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Map every output context
- Create boundary-value repeater entries
- Compare each built-in modifier
- Separate human and machine templates
- Add snapshots and downstream verification
Mistakes to avoid
- Changing production code, form fields, webhook endpoints, cache settings, or security limits before preserving the failing fixture and current configuration.
- Treating one clean dashboard status as proof even though the browser, PHP process, database, delivery provider, and downstream record have not been reconciled.
- Testing with a different form, role, locale, order state, entry shape, plugin version, or cache state than the workflow users actually reach.
- Leaving debug logs, temporary endpoints, broad permissions, copied secrets, or test notifications active after the verification window closes.
Questions teams ask during testing
Can I test this directly on production?
Read-only checks can be appropriate when access is controlled and output is redacted. Make a backup first, use a named canary record, test state-changing work on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact version, request path, form or order ID, role, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare the saved evidence rather than relying on memory.
What evidence should I keep?
Keep the UTC time, site and plugin versions, fixture ID, expected result, actual result, relevant logs, configuration snapshot, change made, rollback point, and final verification. Remove passwords, tokens, payment details, and personal data.
When should I bring in a specialist?
Escalate when checkout, payments, lead capture, security, customer email, accessibility, or several integrations are affected, or when the safest next step is unclear. A concise evidence packet reduces diagnosis time.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, logs, change, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test the Gravity Forms repeater output.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references