Content: Contact.jsx form field has space in name attribute #207

New Issue

Open

opened 2026-05-29 16:45:58 -05:00 by null · 1 comment

null commented

2026-05-29 16:45:58 -05:00

Owner

Severity: Minor

File: src/pages/Contact.jsx line 473

Issue: Form field name="Last Name" contains a space — unconventional and may cause issues with form processors or CRM integrations.

Fix direction: Use underscore: name="last_name".

**Severity:** Minor **File:** `src/pages/Contact.jsx` line 473 **Issue:** Form field `name="Last Name"` contains a space — unconventional and may cause issues with form processors or CRM integrations. **Fix direction:** Use underscore: `name="last_name"`.

null added the

bug

content

labels 2026-05-29 16:45:58 -05:00

null added this to the Batch 12 — Enterprise content rewrite milestone 2026-08-18 01:24:56 -05:00

null commented

2026-08-18 02:32:34 -05:00

Author

Owner

Checked while working Batch 10. The premise needs correcting before anyone acts on it, and the line reference is wrong.

The stated risk does not exist. The issue says the space in name="Last Name" "may cause issues with form processors or CRM integrations". This form does not post to a CRM. src/pages/Contact.jsx posts JSON to our own /api/leads (see the mapping at lines 97-104: formState['Last Name'] becomes name, formState['Zip Code'] becomes zip). The Zoho WebToLead payload is built entirely server-side in server/index.js:567,570, with its own literals 'Last Name' and 'Zip Code' — which is what Zoho actually requires, spaces included.

So the names in Contact.jsx are internal React state keys. They reach Zoho through nothing.

The line number is wrong. The issue cites line 473. The attributes are at lines 315 (name="Last Name") and 364 (name="Zip Code").

Where it would actually bite. A careless rename of only the name= attribute — the literal fix direction here, name="last_name" — would desynchronise it from the formState keys, the errors keys and the validation at lines 44-47, and silently break required-field validation on the contact form. Anyone doing this must change all of: the useState initialiser, the errors initialiser, resetForm, the validators, the handleChange path, and the payload mapping.

Recommendation: close as won't-fix. The names mirror Zoho's own field naming deliberately, which makes the server-side mapping legible, and there is no functional gain from renaming ~10 call sites. Leaving it open as a P2 invites exactly the partial rename described above.

Not closing it unilaterally — the original reporter may have had a reason not stated here.

Checked while working Batch 10. The premise needs correcting before anyone acts on it, and the line reference is wrong. **The stated risk does not exist.** The issue says the space in `name="Last Name"` "may cause issues with form processors or CRM integrations". This form does not post to a CRM. `src/pages/Contact.jsx` posts JSON to **our own** `/api/leads` (see the mapping at lines 97-104: `formState['Last Name']` becomes `name`, `formState['Zip Code']` becomes `zip`). The Zoho WebToLead payload is built entirely server-side in `server/index.js:567,570`, with its own literals `'Last Name'` and `'Zip Code'` — which is what Zoho actually requires, spaces included. So the names in Contact.jsx are internal React state keys. They reach Zoho through nothing. **The line number is wrong.** The issue cites line 473. The attributes are at lines 315 (`name="Last Name"`) and 364 (`name="Zip Code"`). **Where it would actually bite.** A careless rename of only the `name=` attribute — the literal fix direction here, `name="last_name"` — would desynchronise it from the `formState` keys, the `errors` keys and the validation at lines 44-47, and silently break required-field validation on the contact form. Anyone doing this must change all of: the `useState` initialiser, the `errors` initialiser, `resetForm`, the validators, the `handleChange` path, and the payload mapping. **Recommendation: close as won't-fix.** The names mirror Zoho's own field naming deliberately, which makes the server-side mapping legible, and there is no functional gain from renaming ~10 call sites. Leaving it open as a P2 invites exactly the partial rename described above. Not closing it unilaterally — the original reporter may have had a reason not stated here.