Skip to content
EntryWick documentation

For whoever decides what a registrant is asked.

Registration forms — the builder

Events → Registration forms.

Who opens it: whoever decides what a registrant is asked.

What they came to do: build the questions, in pages, with the ones that only apply to some people hidden until they do.

True when they leave: the form asks what the organization needs and nothing it does not, and a registrant on a phone can finish it.

Decisions already made

  • A form is a document, not a table of columns. forms.schema holds pages and fields (docs/schemas/form.schema.json), so a question can be added without a migration and an event template can carry a whole form in a file.
  • A field either maps somewhere or is an answer. map: attendee.first_name writes the column; anything under attendee.answers.* is kept as the registrant's own answer and is exportable, printable and rule-readable. A field with no map is asked and forgotten, which is almost never what anybody means.
  • Versions, not edits. Saving writes the next version; a submission records the version it was made with, so "what did we ask in March?" has an answer. A live form's earlier versions keep the answers already given.
  • Conditional logic is a list of rules, evaluated on both sides. schema.logic shows, hides, requires and sets; the browser evaluates it so the form does not round-trip, and the server evaluates it again on submit because the browser is not to be trusted. form_conditional_logic is the plan's key for it.
  • Re-importing an event template gives its forms a new code, never a new version — a registration form points at a form row, and versioning over the first event's form would silently change what that event collects (EVENT_TEMPLATE_FORMAT §4.4).
  • A file a registrant uploads is scanned before it is kept (form-uploads.md).
  • Consent is a field type, carrying the document it consents to and a version, so a signature means something a year later (photo-release.md).

Ready-made forms (Phase 6 week 32)

Registration forms → Start from a ready-made form. Six starting points, each a complete form: Individual, Family or household, Couple, Group of adults, Conference delegate, and Crew and vendor accreditation.

  • A copy, not a link. Picking one makes the organization's own form, unlocked and at version 1, with a code of its own (couple, then couple-2). Changing it never touches the ready-made one, and an update to the ready-made one never reaches a copy already made.
  • Each says what it needs. The picker shows which attendee types the event should have — the family form, for instance, wants a type for the adult and a second type for children that needs the adult's as its companion, which is where the ratio rule lives. Nothing is checked or created: the form is a form, and the types are the event's.
  • No plan feature. A ready-made form carries no conditional logic, so it saves on every plan.
  • No invented groups or teams. None asks which group or team someone belongs to; add that question if the event has them.
  • The consent wording is deliberately plain and short. It records what was agreed and when, but it is not legal advice: replace it with the organization's own.
  • The files are templates/forms/*.json; tests/Feature/Forms/FormLibraryTest.php holds each one to the form schema.

Open questions

  • There is no preview of the form as a registrant sees it from this screen; the way to look is to open the registration form's public link, which is right but is two steps.
  • Nothing warns that a question is asked twice in different words across two forms of the same event.