Guide 10 · Developer docs

Building forms with the Forms module: how a form is put together and placed on a page, validating and branching, presenting it, where submissions are stored, and what happens after one arrives, from jobs and records to CRMs and payments.

L1–L2

Unit 04 of 07 3 pages

Presenting a form

Updated 23/10/2026 01:43

The markup the platform prints for a form and how far you can style or override it, the client-side helpers production sites add, and the captcha element that keeps spam out.

Start with the markup itself: what the platform prints for every field, the classes available to style it, and how far you can override one input's markup before you are maintaining your own form. Client-side helpers builds on that markup: four behaviours production sites add (an international phone field, timezone capture, prefilling and campaign capture), each writing into fields the platform already stores.

Captcha comes last because it depends on both: where the element sits in the markup, and the script conflicts to avoid once helpers and a captcha share the page.

In this unit

Read in order

01 Rendering and styling The markup the platform prints for every field and the classes to style; replacing one input type's markup without forking the form, and what you then take over; and styling a form to a design without fighting the platform. 02 Client-side helpers The four helpers production sites ship with their forms: an international phone field, timezone capture, prefilling from a link or from the signed-in member, and campaign capture. What each contributes, and where its code lives. 03 Captcha What the Captcha element does, the form setting that keeps failed submissions out of your data, where the captcha belongs, the script conflicts to avoid, and how to diagnose a captcha problem.

Objects ReferenceGenerated from the platform, so it is always current

API ReferenceEvery REST endpoint, in cURL, PHP, Python and JavaScript

Presenting a form

In this unit